Workspace認証でゲスト用のAzure AD IDとB2B IDを使用するSAML
この記事を読む前に、「B2B SAML」がご利用環境での認証のユースケースに適しているかどうかを理解しておく必要があります。この特別なケースのSAMLソリューションの実装を決定する前に、ユースケースの説明とFAQをよくお読みください。先に進む前に、B2B SAMLの使用が適切なシナリオと、どのIDタイプを使用する必要があるかを十分に理解しておいてください。SAMLの大半のユースケースでは、他のSAMLの記事に記載されている、認証用に4つのcip_*属性をすべて送信することで対応できます。
注：
「B2B SAML」を使用すると、SAMLアサーションによって提供される値ではなく、Workspaceのエンドユーザーがログオンするたびにユーザーのメール、SID、OIDを検索する必要があるため、Citrix Cloud Connectorにかかる負荷が増加します。B2B SAMLが必須ではない場合は、Citrix Cloud Connectorのパフォーマンスの観点から、SAMLアサーションの4つのcip_*属性をすべて送信することをお勧めします。
前提条件
- SAMLアサーション内の認証でcip_upnのみを送信する、B2B SAMLで使用するために特別に構成されたSAMLアプリケーション。
- SAMLプロバイダー内のフロントエンドユーザー。
- リソースの場所に、ADシャドウアカウントが作成されたADフォレストとドメインに参加済みのCitrix Cloud Connectorのペアが含まれる。
- 暗黙的なUPNを使用するか、ADシャドウアカウントが作成されるバックエンドADフォレストに追加される代替のUPNサフィックスを追加してください。
- UPNが一致するバックエンドADシャドウアカウント。
- ADシャドウアカウントユーザーにマップされたDaaSまたはCVADリソース。
- 同じリソースの場所にリンクされている1つまたは複数のFASサーバー。
よくある質問
B2B SAMLを使用すべき理由は何ですか?
大規模な組織では、契約社員や派遣社員をIDプラットフォームに招待することがよくあります。目標は、契約社員のメールアドレスや組織外のメールアドレスなど、ユーザーの既存のIDを使用して、契約社員にCitrix Workspaceへの一時的なアクセスを許可することです。B2B SAMLでは、DaaSリソースが公開されているADドメイン内には存在しないネイティブまたはゲストのフロントエンドIDを使用できます。
B2B SAMLとは何ですか?
通常、Citrix Workspaceにサインインする場合、4つのSAML属性cip_*とそれに対応するADユーザー属性がエンドユーザーの認証に使用されます。これらの4つのSAML属性はSAMLアサーションに存在し、ADユーザー属性を使用して入力されることが想定されます。B2B SAMLは、認証が成功するためにcip_upn SAML属性のみが必要であるという事実を指します。
| AD属性 | SAMLアサーションのデフォルトの属性名 |
|---|---|
| userPrincipalName | cip_upn |
| cip_email | |
| objectSID | cip_sid |
| objectGUID | cip_oid |
認証に必要な他の3つのADユーザー属性objectSID、objectGUID、およびmailは、ADシャドウアカウントが存在するADドメインに参加しているCitrix Cloud Connectorを使用して取得されます。WorkspaceまたはCitrix CloudのSAMLサインインフロー中に、これらをSAMLアサーションに含める必要がなくなりました。
| AD属性 | SAMLアサーションのデフォルトの属性名 |
|---|---|
| userPrincipalName | cip_upn |
重要：
ただし、
B2B SAMLを含むすべてのSAMLフローで、依然としてdisplayNameは送信する必要があります。Workspace UIでWorkspaceユーザーのフルネームを正しく表示するには、displayNameが必要です。
ネイティブSAMLユーザー IDとは何ですか?
ネイティブSAMLユーザーとは、Entra IDやOktaなど、SAMLプロバイダーディレクトリ内にのみ存在するユーザーIDです。これらのIDには、オンプレミスのユーザー属性は含まれていません。Entra ID ConnectなどのAD同期ツールで作成されないためです。DaaSリソースを列挙して起動するには、一致するバックエンドADシャドウアカウントが必要です。ネイティブSAMLユーザーはActive Directory内の対応するアカウントにマップされている必要があります。
別のEntra IDテナントからインポートされたB2Bユーザーとは何ですか?
B2Bユーザーは、Entra IDテナント1の内部にメンバーとして存在し、ゲストユーザーとしてEntra IDテナント2などの他のEntra IDテナントに招待されるEntra IDユーザーです。B2B SAMLアプリはEntra IDテナント2の内部で構成され、SAML IDプロバイダーとしてCitrix Cloudに接続されています。 B2BユーザーがDaaSリソースを列挙して起動するには、一致するバックエンドADシャドウアカウントが必要です。B2Bユーザーは、Active Directory内の対応するシャドウアカウントにマップされている必要があります。
B2Bユーザーの詳細と、他のEntra IDテナントのメンバーユーザーをゲストユーザーとしてEntra IDテナントに招待する方法については、Microsoftのドキュメントを参照してください。
概要：従業員向けの外部ゲストとのB2B Microsoft Entra B2Bコラボレーションユーザーのプロパティ
ADベースのSAMLユーザーIDとは何ですか?
ADベースのSAMLユーザーは、Entra IDやOktaなどのSAMLプロバイダーディレクトリ内に存在するユーザーIDであり、オンプレミスのADフォレスト内にも存在します。Entra ID ConnectなどのAD同期ツールで作成されるため、これらのIDにはオンプレミスのユーザー属性が含まれます。オンプレミスのSIDとOIDが含まれ、ADドメイン参加済みVDAを使用して公開されたDaaSリソースを列挙して起動できるため、これらのユーザーにはバックエンドADシャドウアカウントは必要ありません。
フロントエンドIDとは何ですか?
フロントエンドIDは、SAMLプロバイダーとWorkspaceの両方にサインインするために使用されるIDです。 フロントエンドIDのユーザー属性は、SAMLプロバイダー内での作成方法によって異なります。
- ネイティブSAMLユーザーID
- ADベースのSAMLユーザーID
SAMLプロバイダーには、これら2つのIDタイプが混在している場合があります。たとえば、IDプラットフォームに契約社員と正社員の両方がいる場合、B2B SAMLはどちらのタイプのフロントエンドIDでも機能しますが、ネイティブSAMLユーザーIDタイプのアカウントがある場合にのみ必須です。
バックエンドADシャドウアカウントとは何ですか?
バックエンドADシャドウアカウントはDaaSが使用するADアカウントであり、SAMLプロバイダー内の対応するフロントエンドIDにマップされます。
バックエンドADシャドウアカウントが必要なのはなぜですか?
ADドメイン参加済みVDAを使用して公開されたDaaSまたはCVADリソースを列挙するには、VDAが参加しているActive Directoryフォレスト内のADアカウントが必要です。DaaSデリバリーグループ内のリソースを、シャドウアカウントユーザーと、VDAが参加しているADドメイン内のシャドウアカウントを含むADグループにマップします。
重要：
ADドメイン属性を持たないネイティブSAMLユーザーのみが、一致するADシャドウアカウントを必要とします。フロントエンドIDをActive Directoryからインポートする場合、
B2B SAMLを使用する必要はなく、バックエンドADシャドウアカウントを作成する必要もありません。
フロントエンドIDを対応するバックエンドADシャドウアカウントにリンクする方法を教えてください。
フロントエンドIDとバックエンドIDをリンクする方法には、一致するUPNを使用する方法があります。Workspaceへのサインインが必要な同じエンドユーザーであること、およびDaaSリソースを列挙して起動する必要があることをWorkspaceが認識できるように、リンクされた2つのIDには同じUPNが必要です。
B2B SAMLにはCitrix FASが必要ですか?
はい。任意のフェデレーション認証方法を使用してWorkspaceにサインインする場合、起動時にVDAへのSSONにFASが必要です。
「SIDの不一致問題」とは何ですか? また、どのような場合に発生しますか?
「SIDの不一致問題」は、SAMLアサーションにフロントエンドユーザーのSIDが含まれており、それがADシャドウアカウントユーザーのSIDと一致しない場合に発生します。これは、SAMLプロバイダーにサインインしているアカウントにオンプレミスSIDがあり、それがシャドウアカウントユーザーのSIDとは異なる場合に発生する可能性があります。 これは、フロントエンドIDがEntra ID ConnectなどのAD同期ツールによってプロビジョニングされ、それがシャドウアカウントが作成されたADフォレストではないところからのプロビジョニングであった場合にのみ発生します。
B2B SAMLは、「SIDの不一致問題」の発生を防ぎます。 シャドウアカウントユーザーの正しいSIDは、常にバックエンドADドメインに参加しているCitrix Cloud Connectorを使用して取得されます。 シャドウアカウントユーザーの検索は、フロントエンドユーザーのUPNを使用して実行され、対応するバックエンドシャドウアカウントユーザーと照合されます。
SIDの不一致問題の例：
フロントエンドユーザーはEntra ID Connectによって作成され、ADフォレスト1から同期されました。
S-1-5-21-000000000-0000000000-0000000001-0001
バックエンドシャドウアカウントユーザーはADフォレスト2内で作成され、DaaSリソースにマップされました
S-1-5-21-000000000-0000000000-0000000002-0002
SAMLアサーションには4つのcip_*属性がすべて含まれ、cip_sidには値S-1-5-21-000000000-0000000000-0000000001-0001が含まれます。これはシャドウアカウントのSIDと一致しないため、エラーが発生します。
外部ゲストアカウント用にEntra ID内のB2B SAMLアプリケーションを構成する
- Azure Portalにサインインします。
- ポータルメニューから ［Entra ID］ を選択します。
- 左側のペインの［管理］で、［エンタープライズアプリケーション］を選択します。
- ［Create your own application］ を選択します。
-
SAMLアプリケーションの適切な名前を入力します。例：
Citrix Cloud SAML SSO Production B2B SAML UPN Only。
- 左側のナビゲーション ペインで ［Single sign-on］ を選択し、作業ペインで ［SAML］ をクリックします。
-
［Basic SAML Configuration］ セクションで、［Edit］ を選択し、次の設定を構成します：
-
［ Identifier（Entity ID）］セクションで、［Add identifier］を選択し、Citrix Cloudテナントが配置されているリージョンに対応する値を入力します：
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
https://saml.cloud.com」と入力します。 - 日本リージョンの場合は「
https://saml.citrixcloud.jp」と入力します。 - Citrix Cloud Governmentリージョンの場合は、「
https://saml.cloud.us」と入力します。
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
-
［Reply URL (Assertion Consumer Service URL)］セクションで、［Add reply URL］を選択し、Citrix Cloudテナントが存在するリージョンに対応する値を入力します：
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
https://saml.cloud.com/saml/acs」と入力します。 - 日本リージョンの場合は「
https://saml.citrixcloud.jp/saml/acs」と入力します。 - Citrix Cloud Governmentリージョンの場合は、「
https://saml.cloud.us/saml/acs」と入力します。
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
- ［Sign on URL］ セクションに、Workspace URLを入力します。
-
［ログアウトURL（オプション）］セクションで、Citrix Cloudテナントが存在するリージョンに対応する値を入力します：
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
https://saml.cloud.com/saml/logout/callback」と入力します。 - 日本リージョンの場合は「
https://saml.citrixcloud.jp/saml/logout/callback」と入力します。 - Citrix Cloud Governmentリージョンの場合は、「
https://saml.cloud.us/saml/logout/callback」と入力します。
- 欧州、米国、およびアジア太平洋南部の各リージョンの場合は、「
-
コマンドバーで、［Save］ をクリックします。［Basic SAML Configuration］ セクションが以下のように表示されます：
-
［ Identifier（Entity ID）］セクションで、［Add identifier］を選択し、Citrix Cloudテナントが配置されているリージョンに対応する値を入力します：
-
［Attributes & Claims］ セクションで ［Edit］ を選択し、以下の要求を構成します。これらの要求は、SAML応答内のSAMLアサーションに表示されます。SAMLアプリの作成後、次の属性を構成します。
- Unique User Identifier（Name ID）要求については、Name IDの形式を未指定に設定し、そのソース属性を
user.localuserprincipalnameとして設定します。 -
cip_upn要求では、デフォルト値の
user.localuserprincipalnameのままにします。 -
displayNameでは、デフォルト値の
user.displaynameのままにします。 -
［Additional claims］セクションで、名前空間
http://schemas.xmlsoap.org/ws/2005/05/identity/claimsを持つ要求が残っていれば、［省略記号（…）］をクリックし、［削除］をクリックします。これらの要求は上記のuser属性と重複するため、含める必要はありません。完了すると、下図のような［Attributes & Claims］セクションが表示されます：
- この サードパーティのオンラインツールを使用して、Citrix Cloud SAML署名証明書のコピーを取得します。
- URLフィールドに
https://saml.cloud.com/saml/metadataを入力し、［Load］ をクリックします。
- Unique User Identifier（Name ID）要求については、Name IDの形式を未指定に設定し、そのソース属性を
-
ページの下までスクロールして、［ダウンロード］をクリックします。
- Azure Active Directory SAMLアプリケーションの署名設定を構成します。
- 手順10で取得した実稼働SAML署名証明書をAzure Active Directory SAMLアプリケーション内にアップロードします
- ［検証証明書が必要］ を有効にします。
Citrix Cloud B2BのSAML接続を構成する
デフォルトでは、Citrix Cloudではcip_upn、cip_email、cip_sid、cip_oidがSAMLアサーションに含まれていることが想定されているため、これらの属性が送信されない場合はSAMLサインインに失敗します。これを防ぐには、新しいSAML接続を作成するときに、これらの属性のチェックを解除してください。
- デフォルト設定を使用して新しいSAML接続を作成します。
- 下の ［SAML Attribute Mappings Configuration］ セクションに移動し、新しいSAML設定を保存する前に変更を加えます。
- cip_email、cip_sid、cip_oidの各フィールドからSAML属性名を削除します。
- cip_upnはフィールドから削除しないでください。
- それぞれのフィールドから他の属性を削除しないでください。displayNameは引き続きWorkspace UIに必要であり、変更しないでください。
ADシャドウアカウントのリソースの場所とコネクタの構成
バックエンドシャドウアカウントのADフォレスト内にリソースの場所とコネクタのペアが必要です。Citrix Cloudで、シャドウアカウントのユーザーIDと、cip_email、cip_sid、cip_oidなどの属性を検索するために、このADフォレスト内にコネクタが必要です（SAMLアサーション内でcip_upnのみが直接指定されている場合）。
-
バックエンドシャドウアカウントのADフォレストに参加済みのCitrix Cloud Connectorを含む、新しいリソースの場所を作成します。
- 使用するバックエンドADシャドウアカウントが存在するADフォレストと一致する、リソースの場所の名前を指定します。
- 新しく作成したリソースの場所内でCitrix Cloud Connectorのペアを構成します。
例
ccconnector1.shadowaccountforest.com
ccconnector2.shadowaccountforest.com
バックエンドADフォレスト内でのFASの構成
契約社員のフロントエンドユーザーには必ずFASが必要です。DaaSの起動中、契約社員ユーザーはADシャドウアカウントのパスワードを知らない可能性が高いため、 Windows資格情報を手動で入力して起動を完了することはできません。
- シャドウアカウントが作成されたバックエンドADフォレスト内に、1つまたは複数のFASサーバーを構成します。
- シャドウアカウントが作成されたバックエンドADフォレストに参加しているCitrix Cloud Connectorのペアが含まれる同じリソースの場所に、FASサーバーをリンクします。
ADドメイン内での代替UPNサフィックスの構成
重要：
UPNはユーザーのメールアドレスとは異なります。多くの場合、利便性のために同じ値を使用しますが、UPNとメールアドレスは異なる値を持つことが多く、異なるActive Directory属性および異なるEntra IDユーザー属性内で定義されます。このソリューションは、メールアドレスの一致ではなく、フロントエンドとバックエンドのID間のUPNの一致を利用します。
DNSでパブリックにルーティングできるドメインの暗黙的なUPNサフィックスを使用することも、OktaまたはAzure ADテナントに招待する外部フロントエンドユーザーごとに一致する代替UPNサフィックスを追加することもできます。ADがyourdomain.localを暗黙的なUPNとして使用する場合は、yourdomain.comのような代替UPNサフィックスを選択する必要があります。Entra IDでは、カスタムドメイン名内にyourdomain.localを追加することはできません。
たとえば、外部ユーザーcontractoruser@hotmail.co.ukを招待し、これをバックエンドADシャドウアカウントcontractoruser@yourforest.comに関連付ける場合は、yourforest.comをADフォレスト内で代替UPNサフィックスとして追加します。
Active Directoryドメインと信頼関係のUIを使用してActive Directoryに代替UPNサフィックスを追加する
- バックエンドADフォレスト内のドメインコントローラーにサインインします。
-
［ファイル名を指して実行］ を開いてから
domain.mscを入力して、［OK］ をクリックします。 - ［Active Directoryドメインと信頼関係］ウィンドウで、［Active Directoryドメインと信頼関係］ を右クリックし、［プロパティ］ を選択します。
-
［UPNサフィックス］ タブの［代わりのUPNサフィックス］ボックスに、代替UPNサフィックスを追加し、［追加］ を選択します。
- ［OK］ をクリックします。
PowerShellを使用してバックエンドADフォレストのUPNサフィックスを管理する
必要なシャドウアカウントUPNを作成するには、バックエンドADフォレストに多数の新しいUPNサフィックスの追加が必要な場合があります。バックエンドADフォレストに追加する必要がある代替UPNサフィックスの数は、SAMLプロバイダーテナントに招待する外部ユーザーの数によって異なります。
以下は、多数の新しい代替UPNサフィックスを作成する必要がある場合に、これを実現するためのPowerShellの例です。
# Get the list of existing ALT UPN suffixes within your AD Forest
(Get-ADForest).UPNSuffixes
# Add or remove ALT UPN Suffixes
$NewUPNSuffixes = @("yourforest.com","externalusers.com")
# Set action to "add" or "remove" depending on the operation you wish to perform.
$Action = "add"
foreach($NewUPNSuffix in $NewUPNSuffixes)
{
Get-ADForest | Set-ADForest -UPNSuffixes @{ $Action=$NewUPNSuffix }
}
<!--NeedCopy-->
バックエンドADフォレスト内のADシャドウアカウントを構成する
- 新しいADシャドウアカウントユーザーを作成します。
-
新しいADユーザーには、ADフォレストの暗黙的なUPN（
yourforest.localなど）がデフォルトで選択されます。上記で作成した適切な代替UPNサフィックスを選択します。たとえば、シャドウアカウントユーザーのUPNサフィックスとしてyourforest.comを選択します。
シャドウアカウントユーザーのUPNは、PowerShellを使用して更新することもできます。
Set-ADUser "contractoruser" -UserPrincipalName "contractoruser@yourforest.com" <!--NeedCopy--> - シャドウアカウントユーザーのUPNは、外部フロントエンドIDユーザーのUPNと完全に一致する必要があります。
- フロントエンドユーザーのWorkspaceへのサインインをテストします。
- サインインが成功したら、必要なすべてのリソースがWorkspaceに列挙されていることを確認します。ADシャドウアカウントにマップされたリソースが表示されます。
ゲストEntra IDユーザーUPNをADシャドウアカウントUPNと一致するように構成する
外部ゲストユーザーがEntra IDテナントに招待されると、そのユーザーが外部ユーザーであることを示す自動生成UPNが作成されます。外部Entra IDユーザーには自動的に「@Entra IDtenant.onmicrosoft.com」UPNサフィックスが割り当てられます。これはB2B SAMLでの使用には不適切であり、ADシャドウアカウントと一致しません。そのため、Entra ID内のインポートされたDNSドメインと、ADフォレスト内で作成した代替UPNサフィックスとが一致するように更新する必要があります。
-
ADフォレストに追加した代替UPNサフィックスと一致するカスタムドメインを、Entra IDにインポートします。
-
contractoruser@hotmail.co.ukなどのゲストユーザーを招待し、招待されたゲストユーザーがEntra IDテナントへのMicrosoftの招待状を受け入れることを確認します。Microsoftによって生成された外部ゲストユーザーのUPN形式の例。
contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com
重要：
Citrix CloudとWorkspaceは、SAML認証に「#」文字を含むUPNを使用できません。
-
Entra IDユーザーを管理できるようにするには、必要なAzure PowerShell Graphモジュールをインストールしてください。
Install-Module -Name "Microsoft.Graph" -Force Get-InstalledModule -Name "Microsoft.Graph" <!--NeedCopy--> -
グローバル管理者アカウントと
Directory.AccessAsUser.Allスコープを使用してEntra IDテナントにサインインします。重要：
権限の低いアカウントを使用したり、
Directory.AccessAsUser.Allスコープを指定しなかったりすると、手順4を完了してゲストユーザーのUPNを更新することはできません。Connect-MgGraph -Scopes Directory.AccessAsUser.All <!--NeedCopy--> -
Entra IDユーザーを、ADシャドウアカウントに構成したUPNと一致するUPNで更新します。
$GuestUserId = (Get-MgUser -UserId "contractoruser_hotmail.co.uk#EXT#@yourentraidtenant.onmicrosoft.com").Id Update-MgUser -UserId $GuestUserId -UserPrincipalName "contractoruser@your.com" <!--NeedCopy--> -
Entra IDテナント内の外部ゲストユーザーの一覧をすべて取得できます（オプション）。
Get-MgUser -filter "userType eq 'Guest'" | Select Id,DisplayName,UserPrincipalName,Mail <!--NeedCopy--> -
UPNの更新が必要なゲストユーザーIDを取得し、UPNサフィックスを更新します。
$GuestUserId = (Get-MgUser -UserId "contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com").Id Update-MgUser -UserId $GuestUserId -UserPrincipalName "contractoruser@yourforest.com" <!--NeedCopy--> -
新しく更新されたUPNを使用してゲストユーザーのIDが見つかることを確認します。
Get-MgUser -UserId "contractoruser@yourforest.com" <!--NeedCopy-->
B2B SAMLソリューションのテスト
文書化されたすべての手順をAD、Citrix Cloud、およびSAMLプロバイダーで完了したら、サインインのテストをして、Workspace内のゲストユーザーに正しいリソース一覧が表示されることを確認する必要があります。
あらゆるSAMLデバッグ作業には、ブラウザー拡張機能SAML-tracerを使用することをお勧めします。この拡張機能は、よく知られているWebブラウザーのほとんどで利用できます。この拡張機能は、Base64でエンコードされた要求と応答をSAML XMLにデコードすることで、人間が判読できるようにします。
SAML-tracerを使用してキャプチャされた認証にcip_upnだけを使用するB2B SAMLアサーションの例。
-
正しいDaaSリソースを、ADベースの、およびシャドウアカウントのユーザー、またはそれらを含むグループにマッピングします。
-
SAML-tracerブラウザー拡張機能を起動し、ログオンとログオフのフロー全体をキャプチャします。
-
テストするフロントエンドユーザータイプの表で指定されている属性を使用して、Workspaceにログインします。
ゲストEntra IDユーザーのログオン： ゲストユーザーとしてEntra IDテナントに招待した契約社員ユーザーの場合は、メールアドレス
contractoruser@hotmail.co.ukを使用します。Entra IDのプロンプトが表示されたら、ゲストユーザーのメールアドレスを入力します。
または
ADベースのEntra IDユーザー/ネイティブEntra IDユーザーのログオン： これらのEntra IDユーザーには、
adbackeduser@yourforest.comまたはnativeuser@yourforest.comの形式のUPNが割り当てられます。Entra IDのプロンプトが表示されたら、ユーザーのUPNを入力します。
-
アサーションに認証用のcip_upn属性のみが含まれていること、およびWorkspace UIで必要なdisplayName属性も含まれていることを確認します。
-
ユーザーが必要なDaaSリソースをUIに表示できることを確認します。
B2B SAMLソリューションのトラブルシューティング
SAMLアサーション内で間違ったUPNが送信されている
原因：これは、Entra IDテナント1からEntra IDテナント2にインポートされたB2Bアカウントでのみ発生する可能性があります。他のEntra IDテナントからインポートされたB2Bユーザーを使用すると、間違ったUPNがSAMLアサーション内で送信される可能性があります。user.userprincipalnameが使用され、エンドユーザーが別のEntra IDテナントからインポートされたB2Bユーザーでログインすると、誤ったcip_upn値がSAMLアサーションで送信されます。SAMLアサーションで使用されるcip_upnの値は、B2Bユーザーをメンバーとして含むソースEntra IDテナントからの値です。user.localuserprincipalnameを使用すると、cip_upnの値がEntra IDテナントから取得され、B2Bユーザーがゲストとして招待されることが確認できます。
cip_*属性が見つからないというエラー
原因1：SAML属性がSAMLアサーションに存在しないのに、Citrix Cloudがそれを受け取るように構成されています。［SAML属性］セクション内のCitrix Cloud SAML接続から不要なcip_*属性を削除できていません。SAMLを切断して再接続し、不要なcip_*属性への参照を削除してください。
原因2：このエラーは、Citrix Cloud ConnectorがバックエンドADフォレストで検索できる、対応するADシャドウアカウントがない場合にも発生する可能性があります。フロントエンドIDは正しく設定されているかもしれませんが、一致するUPNを使用したバックエンドADシャドウアカウントIDが存在しないか、見つからない可能性があります。
ログオンは成功するが、ユーザーがWorkspaceにログインした後にDaaSリソースが表示されない
原因：これは、フロントエンドからバックエンドへのIDのUPNマッピングが正しくないことが原因と考えられます。
フロントエンドIDとバックエンドIDの2つのUPNが完全に一致し、Workspaceにログインしている同じエンドユーザーを表していることを確認してください。DaaSデリバリーグループに、正しいADシャドウアカウントユーザーまたはそれらを含むADグループへのマッピングが含まれていることを確認します。
DaaSリソースの起動中に、ADドメインに参加しているVDAへのFAS SSONが失敗する
DaaSリソースを起動しようとすると、WorkspaceエンドユーザーはGINA内にWindows資格情報を入力するように求められます。また、イベントID 103は、FASサーバーのWindowsイベントログに表示されます。
[S103] サーバー [CC: FASserver]はUPN [frontenduser@yourforest.com] SID S-1-5-21-000000000-0000000000-0000000001-0001を要求しましたが、検索でSID S-1-5-21-000000000-0000000000-0000000001-0002が返されました。[correlation: cc#967472c8-4342-489b-9589-044a24ca57d1]
原因：B2B SAML展開が「SIDの不一致問題」の影響を受けています。バックエンドシャドウアカウントのADフォレストとは異なるADフォレストのSIDを含むフロントエンドIDがあります。
SAMLアサーションでcip_sidを送信しないでください。
接続された複数のADフォレストに同じUPNサフィックスが存在する場合、ADベースのユーザーのログオンに失敗する
Citrix Cloudには、異なるADフォレストに参加している複数のリソースの場所とコネクタがあります。シャドウアカウントのADフォレストとは別のADフォレストからEntra IDにインポートされたADベースのユーザーを使用すると、 ログオンが失敗します。
ADフォレスト1はEntra IDと同期され、frontenduser@yourforest.comなどのUPNを持つフロントエンドユーザーを作成します。
AD Forest 2には、frontenduser@yourforest.comなどのUPNを持つバックエンドシャドウアカウント が含まれています。
原因：B2B SAML展開が「UPNがあいまいな問題」の影響を受けています。Citrix Cloudは、ユーザーのバックエンドIDを検索するためにどのコネクタを使用するかを判断できません。
SAMLアサーションでcip_sidを送信しないでください。
ユーザーのUPNは、Citrix Cloudに接続された複数のADフォレストに存在します。