ワークスペース認証におけるゲストおよびB2B ID向けEntra IDを使用したSAML
-
この記事の手順に従う前に、B2B SAMLが認証ユースケースに適しているかどうかを理解することが不可欠です。この特定の特殊なSAMLソリューションの実装を決定する前に、ユースケースの説明とFAQをよくお読みください。続行する前に、B2B SAMLが適切なシナリオと、使用する必要があるIDの種類を完全に理解していることを確認してください。
-
前提条件
- B2B SAMLでの使用向けに特別に構成され、SAMLアサーション内で認証のためにcip_upnのみを送信するSAMLアプリケーション。
- SAMLプロバイダー内のフロントエンドユーザー。
- ADシャドウアカウントが作成されるADフォレストおよびドメインに結合されたCitrix Cloud™コネクタのペアを含むリソースの場所。
- 暗黙的なUPNを使用するか、ADシャドウアカウントが作成されるバックエンドADフォレストに代替UPNサフィックスを追加する。
- UPNが一致するバックエンドADシャドウアカウント。 - ADシャドウアカウントユーザーにマッピングされたDaaSまたはCVADリソース。 - 同じリソースの場所にリンクされた1つ以上のFASサーバー。
FAQ
B2B SAMLを使用する理由
大規模な組織が契約社員や一時従業員をIDプラットフォームに招待することは非常によくあります。その目的は、契約社員のメールアドレスや組織外のメールアドレスなど、ユーザーの既存のIDを使用して、Citrix Workspace™への一時的なアクセスを契約社員に付与することです。B2B SAMLを使用すると、DaaSリソースが公開されているADドメイン内に存在しないネイティブまたはゲストのフロントエンドIDを使用できます。
B2B SAMLとは
| AD属性 | SAMLアサーション内のデフォルト属性名 |
|---|---|
| userPrincipalName | cip_upn |
| cip_email | |
| objectSID | cip_sid |
| objectGUID | cip_oid |
認証に必要な他の3つのADユーザー属性であるobjectSID、objectGUID、およびmailは、ADシャドウアカウントが存在するADドメインに結合されたCitrix Cloudコネクタを使用して取得されます。これらは、WorkspaceまたはCitrix CloudのSAMLサインインフロー中にSAMLアサーションに含める必要がなくなりました。
| AD属性 | SAMLアサーション内のデフォルト属性名 |
|---|---|
| userPrincipalName | cip_upn |
重要:
B2B SAMLを含むすべてのSAMLフローでdisplayNameを送信する必要があることに変わりはありません。displayNameは、Workspace UIがWorkspaceユーザーのフルネームを正しく表示するために必要です。
ネイティブ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 IdPとして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プロバイダーディレクトリ内、およびオンプレミスのADフォレスト内に存在するユーザーIDです。これらのIDは、Entra ID ConnectなどのAD同期ツールを介して作成されるため、オンプレミスのユーザー属性を含みます。これらのユーザーには、オンプレミスの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を使用することです。リンクされた2つのIDは、WorkspaceがそれらがWorkspaceにサインインし、DaaSリソースを列挙および起動する必要がある同じエンドユーザーを表していると判断できるように、同一のUPNを持つ必要があります。
重要
- > 単一のフロントエンドIDは、1つのADフォレスト/ドメイン内の単一のバックエンドIDにのみマッピングできます。DaaSリソースの列挙は、適切なCitrix Cloudコネクタによって実行されるADシャドウアカウントルックアップから取得された1つのSID値のみを使用して行われます。同じUPNサフィックスを持つ複数のADシャドウアカウントに一致する単一のフロントエンドユーザーを使用して、一対多の関係を作成することはできません。バックエンドADシャドウアカウントは、単一のADフォレスト/ドメイン内にのみ存在する必要があります。 - > - > フロントエンドIDとバックエンドID間の明確なUPN一致を使用したサポート フロントエンドユーザー `(user@yourforest.com)` > ADフォレスト1のバックエンドユーザー `(UPN user@yourforest.com)`1つのフロントエンドを1つのバックエンドIDに一致させようとするとUPNの曖昧さがあるため、サポートされていません。 フロントエンドユーザー
(user@yourforest1.com)> ADフォレスト1のバックエンドユーザー(UPN user@yourforest1.com)> ADフォレスト2のバックエンドユーザー(UPN user@yourforest1.com)
B2B SAMLにおけるCitrix FASの必要性
はい。Workspaceにサインインするためにフェデレーション認証方法を使用する場合、起動時にVDAへのSSONのためにFASが必要です。
「SIDミスマッチ問題」とは何か、発生条件
「SIDミスマッチ問題」は、SAMLアサーションにフロントエンドユーザーのSIDが含まれており、それがADシャドウアカウントユーザーのSIDと一致しない場合に発生します。これは、SAMLプロバイダーにサインインするアカウントがオンプレミスのSIDを持っており、それがシャドウアカウントユーザーのSIDと同じではない場合に発生する可能性があります。これは、フロントエンドIDがEntra ID ConnectのようなAD同期ツールによってプロビジョニングされ、シャドウアカウントが作成されたADフォレストとは異なるADフォレストからである場合にのみ発生します。
B2B SAMLは「SIDミスマッチ問題」の発生を防ぎます。正しいSIDは、バックエンドADドメインに参加しているCitrix Cloudコネクタを介して、シャドウアカウントユーザーに対して常にフェッチされます。シャドウアカウントユーザーのルックアップは、フロントエンドユーザーの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ポータルにサインイン
- ポータルメニューから、Entra IDを選択
- 左ペインの管理の下で、エンタープライズアプリケーションを選択
- 独自のアプリケーションを作成を選択
-
SAMLアプリケーションに、
Citrix Cloud SAML SSO Production B2B SAML UPN Onlyのような適切な名前を入力
- 左側のナビゲーションペインからシングルサインオンを選択し、作業ペインからSAMLをクリック
-
基本的なSAML構成セクションで、編集をクリックし、次の設定を構成
-
識別子 (エンティティID) セクションで、識別子の追加を選択し、Citrix Cloudテナントが所在するリージョンに関連付けられた値を入力
- ヨーロッパ、米国、およびアジア太平洋南部リージョンの場合は、
https://saml.cloud.comと入力 - 日本リージョンの場合は、
https://saml.citrixcloud.jpと入力 - Citrix Cloud Governmentリージョンの場合は、
https://saml.cloud.usと入力
- ヨーロッパ、米国、およびアジア太平洋南部リージョンの場合は、
-
応答URL (Assertion Consumer Service URL) セクションで、応答URLの追加を選択し、Citrix Cloudテナントが所在するリージョンに関連付けられた値を入力
- ヨーロッパ、米国、およびアジア太平洋南部リージョンの場合は、
https://saml.cloud.com/saml/acsと入力 - 日本リージョンの場合は、
https://saml.citrixcloud.jp/saml/acsと入力 - Citrix Cloud Governmentリージョンの場合は、
https://saml.cloud.us/saml/acsと入力
- ヨーロッパ、米国、およびアジア太平洋南部リージョンの場合は、
- サインオン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と入力
- ヨーロッパ、米国、およびアジア太平洋南部リージョンの場合は、
-
コマンドバーから保存をクリック。基本的なSAML構成セクションは次のようになります。

-
識別子 (エンティティID) セクションで、識別子の追加を選択し、Citrix Cloudテナントが所在するリージョンに関連付けられた値を入力
-
属性とクレームセクションで、編集をクリックして次のクレームを構成。SAMLアプリ作成後、次の属性を構成
- 一意のユーザー識別子 (名前ID) クレームの場合、名前識別子形式を未指定に設定し、そのソース属性を
user.localuserprincipalnameに設定 -
cip_upnクレームの場合、
user.localuserprincipalnameのデフォルト値をそのままにする -
displayNameの場合、
user.displaynameのデフォルト値をそのままにする -
givenNameクレームの場合、デフォルト値を
user.givennameに更新 -
familyNameクレームの場合、デフォルト値を
user.surnameに更新 -
追加のクレームセクションで、
http://schemas.xmlsoap.org/ws/2005/05/identity/claims名前空間を持つ残りのクレームについては、省略記号 (…) ボタンをクリックし、削除をクリック。これらは上記のユーザー属性の重複であるため、これらのクレームを含める必要はありません。完了すると、属性とクレームセクションは以下に示すように表示されます。

- このサードパーティオンラインツールを使用して、Citrix Cloud SAML署名証明書のコピーを取得
- URLフィールドに
https://saml.cloud.com/saml/metadataと入力し、読み込みをクリック

- 一意のユーザー識別子 (名前ID) クレームの場合、名前識別子形式を未指定に設定し、そのソース属性を
-
ページの下部までスクロールし、ダウンロードをクリック


- Entra ID SAMLアプリケーションの署名設定を構成
- ステップ10で取得した本番SAML署名証明書をEntra ID SAMLアプリケーション内にアップロード 1. 検証証明書を要求を有効にする


Citrix Cloud B2B SAML接続の構成
デフォルトでは、Citrix Cloud は SAML アサーションに cip_upn、cip_email、cip_sid、cip_oid が存在することを期待し、これらの属性が送信されない場合、SAML サインインは失敗します。これを防ぐには、新しい SAML 接続を作成する際に、これらの属性のチェックを削除してください。
- デフォルト設定を使用して新しい SAML 接続を作成します
- 下部にある SAML 属性マッピング構成 セクションに移動し、新しい SAML 構成を保存する前に変更を加えます
-
cip_email、cip_sid、cip_oidの各フィールドから SAML 属性名を削除します -
cip_upnはそのフィールドから削除しないでください - 他の属性をそれぞれのフィールドから削除しないでください。
displayNameは Workspace UI で引き続き必要であり、変更しないでください

ADシャドウアカウントのリソースロケーションとコネクタの構成
バックエンドシャドウアカウントADフォレスト内には、リソースロケーションとコネクタのペアが必要です。Citrix Cloudは、SAMLアサーション内でcip_upnのみが直接提供される場合に、シャドウアカウントのユーザーIDとcip_email、cip_sid、cip_oidなどの属性を検索するために、このADフォレスト内のコネクタを必要とします。
-
バックエンドシャドウアカウントADフォレストに結合されたCitrix Cloudコネクタを含む新しいリソースロケーションを作成します。

- 使用するバックエンドADシャドウアカウントを含むADフォレストと一致するように、リソースロケーションに名前を付けます。
- 新しく作成したリソースロケーション内に、Citrix Cloudコネクタのペアを構成します。
例:
ccconnector1.shadowaccountforest.com
ccconnector2.shadowaccountforest.com
バックエンドADフォレストでのFASの構成
契約者フロントエンドユーザーは、FASを確実に必要とします。DaaSの起動中、契約者ユーザーはWindows資格情報を手動で入力して起動を完了することができません。これは、ADシャドウアカウントのパスワードを知らない可能性が高いためです。
- シャドウアカウントが作成されたバックエンドADフォレスト内に、1つ以上のFASサーバーを構成します。
- FASサーバーを、シャドウアカウントが作成されたバックエンドADフォレストに結合されたCitrix Cloudコネクタのペアを含む同じリソースロケーションにリンクします。

ADドメイン内での代替UPNサフィックスの構成
重要:
UPNはユーザーのメールアドレスと同じではありません。多くの場合、使いやすさのために同じ値が使用されますが、UPNとメールは異なる値を持つことが多く、異なるActive Directory属性内および異なるEntra IDユーザー属性内で定義されます。このソリューションは、フロントエンドとバックエンドのID間のUPNの一致に依存し、メールの一致には依存しません。
ドメインの暗黙的なUPNサフィックスがDNSで公開ルーティング可能である場合、それを使用するか、OktaまたはEntra IDテナントに招待したいすべての外部フロントエンドユーザーに対して、一致する代替UPNサフィックスを追加できます。ADが暗黙的なUPNとしてyourdomain.localを使用している場合、yourdomain.comのような代替UPNサフィックスを選択する必要があります。Entra IDでは、カスタムドメイン名内にyourdomain.localを追加することはできません。
たとえば、外部ユーザーcontractoruser@hotmail.co.ukを招待し、これをバックエンドADシャドウアカウントcontractoruser@yourforest.comに関連付けたい場合、ADフォレスト内にyourforest.comをALT 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ユーザーの場合、
yourforest.localなどのADフォレストの暗黙的なUPNがデフォルトで選択されます。以前に作成した適切な代替UPNサフィックスを選択します。たとえば、シャドウアカウントユーザーのUPNサフィックスとしてyourforest.comを選択します。
シャドウアカウントユーザーのUPNは、PowerShellを介して更新することもできます。
Set-ADUser "contractoruser" -UserPrincipalName "contractoruser@yourforest.com" <!--NeedCopy-->重要
Windows AD PowerShellでは、指定したUPNサフィックスがADフォレスト内に存在しない場合でも、そのUPNサフィックスを持つシャドウアカウントユーザーを作成できます。使用する代替UPNサフィックスはADフォレスト内に存在する必要があります。これは、Citrix Cloudコネクタがバックエンドシャドウアカウントユーザーを検索するためにこのリストに依存するためです。上記のスクリーンショットのように代替UPNサフィックスがADフォレストに表示されない場合、Citrix CloudはフロントエンドIDを適切なバックエンドADシャドウアカウントに一致させることができません。
- シャドウアカウントユーザーのUPNは、外部フロントエンドIDユーザーのUPNと完全に一致する必要があります。
- フロントエンドユーザーのWorkspaceへのサインインをテストします。
- サインインが成功した後、Workspaceにすべての予期されるリソースが列挙されていることを確認します。ADシャドウアカウントにマッピングされたリソースが表示されるはずです。
ADシャドウアカウントUPNに一致するゲストEntra IDユーザー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のようなゲストユーザーを招待し、招待されたゲストユーザーが Microsoft からの Entra ID テナントへの招待を承諾していることを確認します。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--> -
AD シャドウアカウント用に構成した UPN と一致する UPN で Entra ID ユーザーを更新します。
$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 内でゲストユーザーに正しいリソースリストが表示されることを確認する必要があります。
Citrix は、すべての SAML デバッグに SAML トレーサーブラウザー拡張機能の使用を推奨しています。この拡張機能は、ほとんどの一般的な Web ブラウザーで利用できます。この拡張機能は、Base64 エンコードされたリクエストとレスポンスを SAML XML にデコードし、人間が読める形式で表示します。

SAML トレーサーを使用してキャプチャされた、認証に cip_upn のみを使用する B2B SAML アサーションの例。


-
適切な DaaS リソースを、AD バックアップユーザーおよびシャドウアカウントユーザー、またはそれらを含むグループにマップします。
-
SAML トレーサーブラウザー拡張機能を起動し、ログオンおよびログオフのフロー全体をキャプチャします。
-
テストするフロントエンドユーザータイプについて、表に指定されている属性を使用して 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 属性も含まれていることを確認します。
-
ユーザーがUIで必要なDaaSリソースを表示できることを確認します。
B2B SAMLソリューションのトラブルシューティング
SAMLアサーション内で誤ったUPNが送信される問題
原因: これは、Entra IDテナント1からEntra IDテナント2にインポートされたB2Bアカウントでのみ発生します。他のEntra IDテナントからインポートされたB2Bユーザーを使用すると、SAMLアサーション内で誤ったUPNが送信される可能性があります。user.userprincipalnameが使用され、エンドユーザーが別のEntra IDテナントからインポートされたB2Bユーザーでログインした場合、cip_upnの誤った値がSAMLアサーションで送信されます。SAMLアサーションで使用されるcip_upnの値は、B2Bユーザーをメンバーとして含むソースEntra IDテナントからのものになります。user.localuserprincipalnameを使用すると、cip_upnの値は、B2Bユーザーがゲストとして招待されたEntra IDテナントから取得されます。
cip_*属性の欠落エラー

原因1: SAMLアサーションにSAML属性が存在しないにもかかわらず、Citrix Cloudがそれを受信するように構成されています。SAML属性セクション内のCitrix Cloud SAML接続から不要なcip_*属性を削除していません。SAMLを切断して再接続し、不要なcip_*属性への参照を削除してください。
原因2: このエラーは、Citrix CloudコネクターがバックエンドADフォレストで検索する対応するADシャドウアカウントがない場合にも発生する可能性があります。フロントエンドIDは正しく構成されているかもしれませんが、一致するUPNを持つバックエンドADシャドウアカウントIDが存在しないか、見つからない可能性があります。
ログオンは成功するが、ユーザーがWorkspaceにログオンした後DaaSリソースが表示されない問題
原因: これは、フロントエンドとバックエンドのID UPNマッピングが正しくないことが原因である可能性が最も高いです。
フロントエンドとバックエンドのIDの2つのUPNが完全に一致し、Workspaceにログオンしている同じエンドユーザーを表していることを確認してください。DaaSデリバリーグループに、正しいADシャドウアカウントユーザーまたはそれらを含むADグループへのマッピングが含まれていることを確認してください。
DaaSリソースの起動中にADドメイン参加済みVDAへのFAS SSONが失敗する問題
DaaSリソースを起動しようとすると、WorkspaceのエンドユーザーはGINA内でWindows資格情報を入力するよう求められます。また、FASサーバーのWindowsイベントログにイベントID 103が表示されます。
[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 でした。[相関ID: 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フォレスト2には、frontenduser@yourforest.comのようなUPNを持つバックエンドシャドウアカウントが含まれています。
原因: お客様のB2B SAML展開は「UPNの曖昧さの問題」に悩まされています。Citrix Cloudは、ユーザーのバックエンドIDを検索するためにどのコネクターを使用すべきかを判断できません。
SAMLアサーションで cip_sid を送信しないでください。 ユーザーのUPNが、Citrix Cloudに接続されている複数のADフォレストに存在します。
Citrix Cloud SAML接続の構成
すべてのCitrixログオンフローは、Workspace URLまたはCitrix Cloud GO URLのいずれかを使用してサービスプロバイダーによって開始される必要があります。
Entra IDポータルからEntra ID SAMLアプリケーションのSAMLエンドポイントを取得し、Citrix Cloudに入力します。

Citrix Cloud SAML接続で使用するEntra ID SAMLエンドポイントの例
Identity and Access Management > Authentication > Add an identity provider > SAML 内のSAML接続には、デフォルトの推奨値を使用してください。
重要:
Entra IDのSSOおよびログアウトSAMLエンドポイントは同じURLです。
| Citrix Cloudのこのフィールド | この値を入力 |
|---|---|
| Entity ID | https://sts.windows.net/<yourEntraIDTenantID> |
| Sign Authentication Request | Yes |
| SSO Service URL | https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2 |
| SSO Binding Mechanism | HTTP Post |
| SAML Response | Sign Either Response Or Assertion |
| Authentication Context | Unspecified, Exact |
| Logout URL | https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2 |
| Sign Logout Request | Yes |
| SLO Binding Mechanism | HTTP Post |