高度なSAMLシナリオとSAMLアサーション内でのcip_forestおよびcip_domainの正しい使用
本記事では、複数の接続されたActive Directoryフォレストとドメインを含む、Citrix CloudまたはWorkspaceの高度なSAML構成について説明します。本記事は、複雑なAD展開を持つ大企業向けであり、アーキテクトレベルのCitrix Cloud、IdP、およびAD管理者によって実装されるべきです。この高度なSAML構成の最も一般的な使用法は、異なるADインフラストラクチャ、複数のフォレスト、および異なるUPNを持つADバックエンドユーザーの異なる集団を持つ多くの小規模組織から大企業が形成されるM&Aシナリオです。条件付き認証も、M&Aシナリオでしばしば必要とされます。
-
オプションのcip_forestおよびcip_domainクレームは、SAML認証中にADバックエンドユーザーアカウントを検索するためにどのCitrix Cloud Connectorが使用されるかについて、Citrix Cloud管理者に詳細な制御を提供します。SAMLを使用したCitrix Cloudは、Okta IdPやEntra ID IdPなどの他のCitrix CloudフェデレーションOIDC認証方法では不可能な、多くの高度なアカウントマッピングユースケースをサポートしています。
-
前提条件
- AD IDを使用してエンドユーザーを認証する、デフォルトのCitrix Cloud SAMLフローを使用します。
- ADフォレストまたはドメインインフラストラクチャ、およびWorkspaceエンドユーザーのIDの場所について詳細に理解していること。
- 正しいADフォレストとドメインに参加し、正しいADドメインレベルで参加しているCitrix Cloud Connector。
- Citrix Cloudテナント内にすでに構成されている既存のリソースの場所とCitrix Cloud Connectorに関する知識。
- Citrix Cloudに接続されている複数のADフォレスト間に、Active Directory信頼関係がないこと。
- フロントエンドユーザー (Entra ID、Okta、Duo) とバックエンドユーザー (AD) のIDが何を意味するかを理解していること。
- フロントエンドとバックエンドのユーザーIDは、一致するUPNを介してリンクされている必要があります。一致するUPNを持たないフロントエンドとバックエンドのユーザーIDのペアをリンクすることはサポートされていません。
- 各UPNサフィックスがActive Directory内のどこに存在するか、および特定のUPNサフィックスがあいまいであり、複数の接続されたADフォレストに存在するかどうかを理解していること。
- DaaS VDAはADドメインに参加している必要があります。
- DaaSアプリケーションとデスクトップはAD IDに公開されている必要があります。
- DaaSでデリバリーグループのリソースをADグループにマッピングする場合、ユニバーサルADグループは必須です。
-
DaaSデリバリーグループは「リソースの使用を制限する」に設定され、正しいユニバーサルADグループに割り当てられている必要があります。DaaSデリバリーグループ内で「認証されたすべてのユーザーにリソースの使用を許可する」を使用することはサポートされていません。
-
正しいADフォレストに参加し、正しいADレベルでドメインに参加しているFASサーバー。FASサーバーは、DaaS起動時にADドメインに参加しているVDAへのSSONに必要です。
- 複数のSAMLアプリがあり、接続されたADフォレストごとに1つのSAMLアプリが必要な場合は、条件付き認証の実装も必要になる場合があります。各SAMLアプリは、M&Aシナリオにおいてcip_forestとcip_domainに異なる値のセットを必要とする場合があります。
よくある質問
SAMLアサーションでcip_sidを送信する場合、cip_forestおよびcip_domainオプションクレームも送信する必要がありますか
いいえ。SAMLアプリケーションがcip_sidクレームを送信するように構成されており、それがSAMLアサーションに含まれている場合、Citrix Cloudは、ADバックエンドユーザーがどのフォレストとドメインにいるかを常に正しく識別できます。cip_forestとcip_domainは必要ありません。
重要:
- SAMLアサーションでcip_sidを送信できないSAMLシナリオでは、代わりにcip_forestとcip_domainの使用が必要になる場合があります。
- DaaSデリバリーグループ内にマッピングされたバックエンドADユーザーのSIDと一致しない、誤ったSIDを含むフロントエンドユーザー。
- ADインポートツールを介してIdP内で作成されなかった、ネイティブのOkta、Entra ID、またはDuoユーザーなど、埋め込みSIDをまったく持たないフロントエンドユーザー。
AD暗黙的UPNサフィックスとは
暗黙的UPNはActive Directoryによって自動的に作成され、ユーザーのsAMAccountNameとフォレストのDNS名に基づいています。暗黙的UPNは、sAMAccountNameとドメインのDNS名から派生するため、ADフォレスト内で常に一意です。これらはADフォレスト内で一意です。例: @rootforestdomain.local
AD明示的 (ALT) UPNサフィックスとは
明示的UPNサフィックスは、Active Directoryドメインと信頼関係でAD管理者によって追加されるカスタムドメイン名です。例: @rootforestdomain.local
重要:
Windows AD PowerShellを使用すると、指定したUPNサフィックスがADフォレスト内に存在しない場合でも、任意のUPNサフィックスを持つADユーザーを作成できます。使用したい代替UPNサフィックスは、Citrix Cloud Connectorがこのリストに依存してバックエンドアカウントユーザーを検索するため、ADフォレスト内に存在する必要があります。上記のスクリーンショットに示されているように、代替UPNサフィックスがADフォレストで構成されていない場合、Citrix CloudはフロントエンドIDを適切なバックエンドADアカウントに一致させることができません。
UPNのあいまいさとは何か、そしてそれがCitrix CloudとDaaSにとってなぜ問題となるのか
UPNのあいまいさとは、Citrix Cloudに接続された2つ以上のADフォレストにduplicateuser@domain.comが存在する場合に発生する可能性がある状況です。duplicateuser@domain.comの2つのバージョンが存在する場合、UPNサフィックス@domain.comだけでは、正しいADバックエンドユーザーを特定することはできません。これにより、DaaSリソースがまったく列挙されなかったり、ADドメインに参加しているVDAを使用して公開された誤ったDaaSリソースがワークスペース内に表示されたりする可能性があります。
ユニバーサルADグループが要件である理由
ユニバーサルADグループはグローバルカタログ (GC) に保存されるため、フォレスト内のすべてのドメインコントローラーから参照可能です。これにより、同じフォレスト内の任意のドメインにあるリソースへのアクセス許可の割り当てに使用できます。
重要:
ADユニバーサルグループの使用は、cip_forestとcip_domainを含む高度な構成だけでなく、すべてのSAML構成の要件です。グローバルなどの他のADグループタイプを使用すると、Workspaceでのリソース列挙が失敗する可能性があります。
-
ADグループスコープに関するこのMicrosoft記事を読むことをお勧めします。
-
DaaSデリバリーグループ内で「認証されたすべてのユーザーにリソースの使用を許可する」を使用することが推奨されない理由
認証されたすべてのユーザーにリソースの使用を許可するを構成すると、ADドメインに参加しているVDAを使用して公開されたリソースが、同じドメインとフォレスト内にないADユーザーIDのWorkspace内に表示されます。フォレスト1のWorkspace ADエンドユーザーIDを使用して、フォレスト2でドメインに参加しているVDAからリソースを起動することは成功しません。
SAMLアサーションでcip_forestのみ、またはcip_domainのみを送信できますか
いいえ。バックエンドユーザー検索のために特定のADフォレストとドメインコンテキストを指定したい場合、SAMLアサーションで両方のオプションクレームを提供する必要があります。
cip_forestの値を指定する場合、どのUPNサフィックスを使用すべきですか
AD フォレストの暗黙の UPN サフィックスを使用する必要があります。cip_forest クレーム内で、AD フォレストに追加された ALT UPN サフィックスの値を指定しないでください。これは、Citrix Cloud に接続されている複数の AD フォレストに同じ ALT UPN サフィックスが追加されている AD トポロジが存在するためです。DC=duplicate,DC=com のような同じ DN を持つ2つの異なる AD フォレストが Citrix Cloud に接続されていない限り、暗黙の UPN サフィックスと DN が Citrix Cloud にとって曖昧になることはありません（これは考えにくいシナリオです）。
cip_forest と cip_domain の値の同一性または相違性
シナリオ 1: Citrix Cloud Connector がフォレストルートレベルでドメイン参加しており、バックエンド AD アカウントユーザーが接続された AD フォレスト内のルートドメインに存在する場合。
cip_domain と cip_forest は同じ値である必要があります。
cip_forest = "forestrootdomain.com"
cip_domain = "forestrootdomain.com"
シナリオ 2: Citrix Cloud Connector が AD フォレスト階層の子ドメインにドメイン参加しており、バックエンド AD ユーザーが AD フォレスト内の “childdomain.forestrootdomain.com” に存在する場合。
cip_domain と cip_forest は異なる値である必要があります。
cip_forest = "forestrootdomain.com"
cip_domain = "childdomain.forestrootdomain.com"
SAML アサーション内で cip_forest と cip_domain の値をハードコードできますか
はい、ただし DaaS リソースにマッピングされているバックエンド AD ユーザーの全母集団が同じ AD フォレストに存在する場合に限ります。cip_forest と cip_domain の値をハードコードするには、すべてのフロントエンドユーザーが、対応するバックエンド AD アカウントを同じ AD フォレストおよびドメイン内に持つ必要があります。
SAML アサーション内で cip_forest と cip_domain の値を動的に指定できますか
はい、SAML プロバイダーがクレーム変換ルールを介してこれを許可している場合です。異なる UPN サフィックスを持つフロントエンドユーザーの異なる母集団がある場合、グループメンバーシップなどの切り替え条件を使用して cip_forest と cip_domain の値を動的に指定することが可能です。これは Entra ID SAML アプリケーション内で可能であり、クレーム変換ルールをサポートする他の SAML IdP でも可能である場合があります。
AD ドメイン参加済み VDA への SSON 起動を成功させるには、FAS サーバーをどこに配置すべきですか
FAS サーバーは、バックエンド AD アカウントが存在する各バックエンド AD フォレスト内でドメイン参加させ、構成する必要があります。FAS サーバーを AD フォレストルートドメインレベルでドメイン参加させることをお勧めします。
SAML アサーションで cip_forest と cip_domain が必要な AD トポロジー
シナリオ 1: SAML エンドユーザーの UPN が曖昧で、Citrix Cloud に接続された複数の AD フォレストに存在する場合
-
Citrix Cloud テナントには、2 つ以上のリソースロケーションと、Citrix Cloud に接続された複数の AD フォレストまたはドメインがあります。
- ResourceLocation1 には、ルートフォレストレベルで AD forestrootdomain1.com にドメイン参加している Citrix Cloud Connector が含まれています。
- ResourceLocation2 には、ルートフォレストレベルで AD forestrootdomain2.com にドメイン参加している Citrix Cloud Connector が含まれています。
- forestrootdomain1.com と forestrootdomain2.com は両方とも同じ UPN @domain.com サフィックスを持っています。
- forestrootdomain1.com と forestrootdomain2.com の両方に、同じ UPN
duplicateuser@domain.comを持ちながら、SID および OID 値が異なる重複ユーザーが存在する可能性があります。
問題: username@duplicatesuffix.com を使用して正しいバックエンド AD アカウントをルックアップしようとしても、UPN の曖昧さにより、常に正しい AD バックエンドユーザーが返されるとは限りません。Citrix Cloud は、どの AD フォレストと Citrix Cloud Connector を使用すべきかを判断できないため、Workspace に誤った DaaS リソースが表示されたり、DaaS リソースがまったく返されない場合があります。
解決策: 接続された AD フォレストごとに 1 つずつ、2 つの異なる SAML アプリケーションを構成し、SAML アサーションに正しい AD フォレストに対応する cip_domain および cip_forest の値を含めます。これにより、Citrix Cloud は追加のフォレストとドメインのコンテキストを取得し、username@duplicatesuffix.com が複数の接続されたフォレストに存在する場合でも、正しいバックエンド AD ユーザーが「ルックアップ」されるようにします。
SAML アプリ 1 forestrootdomain1.com:
SAML アプリ 2 forestrootdomain2.com:
正しい AD バックエンドグループを使用して、2 つの DaaS デリバリーグループを正しくマッピングします。
シナリオ 2: 子ドメインレベルでドメイン参加している Cloud Connector と子ドメインレベルの Workspace ユーザー
Citrix Cloud テナントには、推奨される “forestrootdomain.com” レベルではなく、”childdomain.forestrootdomain.com” レベルでドメイン参加している 2 つの Citrix Cloud Connector を含むリソースロケーションがあります。Workspace ユーザーは childdomain.forestrootdomain.com 子ドメイン内に存在します。ユーザーは username@forestrootdomain.com のようなルートドメイン UPN サフィックスを使用するように構成されています。
問題: Citrix Cloud は “forestrootdomain.com” を使用して AD アカウントのルックアップを実行しますが、これは接続された AD ドメインと一致しません。
解決策: SAML アサーションで子ドメインのコンテキストを指定し、AD アカウントユーザーが正しい AD 子ドメインおよびフォレストコンテキストから「ルックアップ」されるようにします。
cip_forest =forestrootdomain.com``
cip_domain =childdomain.forestrootdomain.com``
