ネイティブおよびゲストSAMLユーザーに簡易SAMLの使用を構成
この記事を読む前に、「簡易SAML」がご利用環境での認証のユースケースに適しているかどうかを理解しておく必要があります。この特別なケースのSAMLソリューションの実装を決定する前に、ユースケースの説明とFAQをよくお読みください。 先に進む前に、簡易SAMLの使用が適切なシナリオと、どのIDタイプを使用する必要があるかを十分に理解しておいてください。SAMLの大半のユースケースでは、他のSAMLの記事に記載されている、認証用に4つのcip_*属性をすべて送信することで対応できます。
注：
「簡易SAML」を使用すると、SAMLアサーションによって提供される値ではなく、Workspaceのエンドユーザーがログオンするたびにユーザーのメール、SID、OIDを検索する必要があるため、Citrix Cloud Connectorにかかる負荷が増加します。簡易SAMLが必須ではない場合は、Citrix Cloud Connectorのパフォーマンスの観点から、SAMLアサーションの4つのcip_*属性をすべて送信することをお勧めします。
前提条件
- SAMLアサーション内の認証でcip_upnのみを送信する、簡易SAMLで使用するために特別に構成されたSAMLアプリケーション。
- SAMLプロバイダー内のフロントエンドユーザー。
- リソースの場所に、ADシャドウアカウントが作成されたADフォレストとドメインに参加済みのCitrix Cloud Connectorのペアが含まれる。
- ADシャドウアカウントが作成されるバックエンドADフォレストに追加された、代替UPNサフィックス。
- UPNが一致するバックエンドADシャドウアカウント。
- ADシャドウアカウントユーザーにマップされたDaaSまたはCVADリソース。
- 同じリソースの場所にリンクされている1つまたは複数のFASサーバー。
よくある質問
簡易SAMLを使うべきなのはなぜですか?
大規模な組織では、契約社員や派遣社員をIDプラットフォームに招待することがよくあります。目的は、こうした契約社員のメールアドレスや組織外のメールアドレスなど、ユーザーの既存のIDを使用して、契約社員にCitrix Workspaceへの一時的なアクセスを許可することです。簡易SAMLでは、DaaSリソースが公開されているADドメイン内には存在しないネイティブまたはゲストのフロントエンドIDを使用できます。
簡易SAMLとは何ですか?
通常、Citrix Workspaceにサインインする場合、4つのSAML属性cip_*とそれに対応するADユーザー属性がエンドユーザーの認証に使用されます。これらの4つのSAML属性はSAMLアサーションに存在し、ADユーザー属性を使用して入力されます。簡易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 |
重要：
ただし、簡易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内の対応するアカウントにマップされている必要があります。
ADベースのSAMLユーザーIDとは何ですか?
ADベースのSAMLユーザーは、Entra IDやOktaなどのSAMLプロバイダーディレクトリ内に存在するユーザーIDであり、オンプレミスのADフォレスト内にも存在します。Entra ID ConnectなどのAD同期ツールで作成されるため、これらのIDにはオンプレミスのユーザー属性が含まれます。オンプレミスのSIDとOIDが含まれ、DaaSリソースを列挙して起動できるため、これらのユーザーにはバックエンドADシャドウアカウントは必要ありません。
フロントエンドIDとは何ですか?
フロントエンドIDは、SAMLプロバイダーとWorkspaceの両方にサインインするために使用されるIDです。 フロントエンドIDのユーザー属性は、SAMLプロバイダー内での作成方法によって異なります。
- ネイティブSAMLユーザーID
- ADベースのSAMLユーザーID
SAMLプロバイダーには、これら2つのIDタイプが混在している場合があります。たとえば、IDプラットフォームに契約社員と正社員の両方がいる場合、簡易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からインポートする場合、簡易SAMLを使用する必要はなく、バックエンドADシャドウアカウントを作成する必要もありません。
フロントエンドIDを対応するバックエンドADシャドウアカウントにリンクする方法を教えてください
フロントエンドIDとバックエンドIDをリンクする方法には、一致するUPNを使用する方法があります。Workspaceへのサインインが必要な同じエンドユーザーであること、およびDaaSリソースを列挙して起動する必要があることをWorkspaceが認識できるように、リンクされた2つのIDには同じUPNが必要です。
簡易SAMLにはCitrix FASが必要ですか?
はい。任意のフェデレーション認証方法を使用してWorkspaceにサインインする場合、起動時にVDAへのSSONにFASが必要です。
「SIDの不一致問題」とは何ですか? また、どのような場合に発生しますか?
「SIDの不一致問題」は、SAMLアサーションにフロントエンドユーザーのSIDが含まれており、それがADシャドウアカウントユーザーのSIDと一致しない場合に発生します。これは、SAMLプロバイダーにサインインしているアカウントにオンプレミスSIDがあり、それがシャドウアカウントユーザーのSIDとは異なる場合に発生する可能性があります。 これは、フロントエンドIDがEntra ID ConnectなどのAD同期ツールによってプロビジョニングされ、それがシャドウアカウントが作成されたADフォレストではないところからのプロビジョニングであった場合にのみ発生します。
簡易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を使用して簡易SAMLを構成する
- Azure Portalにサインインします。
- ポータルメニューから ［Entra ID］ を選択します。
- 左側のペインの［管理］で、［エンタープライズアプリケーション］を選択します。
- ［Create your own application］ を選択します。
-
SAMLアプリケーションの適切な名前を入力します。例：
Citrix Cloud SAML SSO Production Simplified SAML。
- 左側のナビゲーション ペインで ［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)］ 要求については、
user.userprincipalnameのデフォルト値のままにします。 -
cip_upn要求では、デフォルト値の
user.userprincipalnameのままにします。 -
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)］ 要求については、
-
ページの下までスクロールして、［ダウンロード］をクリックします。
- Azure Active Directory SAMLアプリケーションの署名設定を構成します。
- 手順10で取得した実稼働SAML署名証明書をAzure Active Directory SAMLアプリケーション内にアップロードします
- ［検証証明書が必要］ を有効にします。
Citrix Cloudの簡易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属性で定義されています。
ユーザープリンシパル名（UPN）サフィックスは、ADのサインオン名の一部です。新しいアカウントを作成すると、デフォルトで「yourforest.com」などのADフォレストの暗黙的なUPNサフィックスが使用されます。OktaまたはAzure ADテナントに招待するすべての外部フロントエンドユーザーに、対応する代替UPNサフィックスを追加する必要があります。
たとえば、外部ユーザー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サフィックスが割り当てられます。これは簡易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を更新することはできません。$EntraTenantID = "<yourEntraTenantID>" Connect-MgGraph -Tenant $EntraTenantID -Scopes "Directory.AccessAsUser.All" <!--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-->
簡易SAMLソリューションのテスト
文書化されたすべての手順をAD、Citrix Cloud、およびSAMLプロバイダーで完了したら、サインインのテストをして、Workspace内のゲストユーザーに正しいリソース一覧が表示されることを確認する必要があります。
あらゆるSAMLデバッグ作業には、ブラウザー拡張機能SAML-tracerを使用することをお勧めします。この拡張機能は、よく知られているWebブラウザーのほとんどで利用できます。この拡張機能は、Base64でエンコードされた要求と応答をSAML XMLにデコードすることで、人間が判読できるようにします。
SAML-tracerを使用してキャプチャされた認証にcip_upnだけを使用する簡易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に表示できることを確認します。
簡易SAMLソリューションのトラブルシューティング
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]
原因：簡易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を持つバックエンドシャドウアカウント が含まれています。
原因：簡易SAML展開が「UPNがあいまいな問題」の影響を受けています。Citrix Cloudは、ユーザーのバックエンドIDを検索するためにどのコネクタを使用するかを判断できません。
SAMLアサーションでcip_sidを送信しないでください。
ユーザーのUPNは、Citrix Cloudに接続された複数のADフォレストに存在します。