リファレンスアーキテクチャ：Citrix Workspace とnFactorとの統合およびCSP用の複数のId
はじめに
このドキュメントの目的は、Citrix Workspaceおよび複数のIDプロバイダー（IdP）を使用してCitrix Virtual Apps and Desktops サービス（CVADS）を実装するCitrixService Provider （CSP）をガイドすることです。Citrix Workspace での複数のIdPのサポートは、Citrix ADC nFactor認証の使用によって実現されます。
このドキュメントは、CSP向けのCitrix Virtual Apps and Desktopsサービスを展開する方法に関する段階的なガイダンスを提供することを目的としたものではありません。ここでは、CSP の CVADS 環境の設計と展開に関する詳細な考慮事項を提供する CSP の仮想アプリケーションとデスクトップのリファレンスアーキテクチャを理解していることを前提としています。
一方、Citrix ADC、シングルサインオン（SSO）、およびCitrixフェデレーション認証サービスを理解していることを前提としています。これらのテクノロジーの詳細については、docs.citrix.comを参照してください。
このドキュメントでは、Citrix ADC nFactor認証を快適に展開するために理解する必要のある最も一般的な要素を確認することから始めます。次に、このソリューションを構成するコンポーネントの認証フローを確認します。
最後に,複数のIdPでCitrix ADC nFactor認証を展開するために必要な手順と、それをCitrix Workspace と統合する方法について説明します。
概要
Citrix Virtual Apps and Desktopsサービス
Citrix Virtual Apps and Desktopsサービスは、あらゆるデバイスまたはネットワークから一元管理されたデスクトップおよびアプリケーションへの安全なアクセスを提供します。フェデレーション認証サービス（FAS）とCitrix Cloud の統合により、CSPは外部SAML IdPをサポートしながら、仮想アプリケーションとデスクトップワークロードにSSOを提供できます。
CVADSは、従来のハイパーバイザーや、Microsoft Azure、GCP、AWSなどのパブリッククラウドプラットフォームなど、複数のリソースロケーションでホストされるワークロードをサポートします。これらのリソースの場所でホストされるワークロードは、WindowsまたはLinuxベースで、マルチユーザー展開とシングルユーザー展開の両方をサポートします。
ユーザーは、Windows、Mac、Linuxベースのクライアント、iOSおよびAndroidフォンなどを介して仮想リソースにアクセスできます。Citrix Gateway サービスは、通常、外部接続の処理を担当します。世界中の複数の拠点で高可用性を提供します。内部接続では、新しい直接ワークロード接続機能を使用できます。
CSPは、CVADSを利用したホスト型DaaSソリューションを設計するためのガイダンスとして、CSP向けのVirtual Apps and Desktops のリファレンスアーキテクチャに従うことができます。
Citrix ADC nFactor 認証
Citrix ADC nFactorは、エンドユーザーにスケーラブルで柔軟な認証エクスペリエンスを提供するためのアクションとポリシーを提供します。このユースケースは、CSPが独自のSAML IDPを持ち込むことを許可することで、複数の顧客にデスクトップとアプリケーションを配信することに関連しています。
nFactor 認証は堅牢なポリシーエンジンを使用し、CSP が複雑な認証ワークフローを設計できるようにします。nFactor は、ユーザーの認証フローを決定するメカニズムとしてポリシー式を使用します。この機能は、ユーザーや接続属性などのさまざまな詳細に基づいています。
このアーキテクチャでは、OAUTH IDPポリシーは、Citrix ADCがCitrix Workspace の認証を処理できるように構成されています。また、SAML (および潜在的に LDAP) ポリシーは、複数の IdP に接続するように構成されています。
Citrix Workspace エクスペリエンス
ワークスペースエクスペリエンスは、StoreFrontのクラウドベースの進化形です。Workspace Experienceを通じて、CSPは仮想アプリケーションとデスクトップ、SaaSおよびオンプレミスWebアプリケーションへのSSO、マイクロアプリの統合とアクション、コンテンツコラボレーション、エンドポイント管理機能、および分析を提供できます。この高度な機能により、CSPは、従業員エクスペリエンスと生産性の向上に重点を置いた統合エクスペリエンスを一元的に提供できます。
現在、Citrix Workspace は複数のIdPとの統合をサポートしていません。ただし、多くのCSPは、Citrix Workspaceが提供する高度な機能を維持しながら、複数のIDPサポートを提供する必要があります。
OAUTH 認証
Citrix ADCは、オープンID接続（OIDC）プロトコルを使用して、OAUTH アイデンティティプロバイダー（IDP）として構成できます。OAUTH は通常、認証プロトコルではなく、認証フレームワークと呼ばれます。OIDC は、一般的な OAUTH 2.0 フローにユーザー認証部分を追加します。このアーキテクチャでは、Citrix Workspace はCitrix ADC（OAUTH IDP）を信頼するOAUTHService Provider （SP）として機能します。
この構成では、Citrix Workspace では、認証プロセスを成功させるために、Active Directory シャドウアカウントが一連の「要求」を渡す必要があります。Citrix Cloudでは、利用者がサインインする際、ユーザーコンテキストを決定するためにこれらのプロパティが必要とされます。これらのプロパティが入力されていない場合、利用者はワークスペースにサインインできません。クレームの一覧は、このドキュメントの後のセクションで確認します。
SAML認証
このアーキテクチャでは、Citrix ADCがService Provider （SP）になり、各顧客の認証ソリューションがIDプロバイダー（IDP）として機能します。SP または IDP は SAML 認証プロセスを開始できます。このアーキテクチャでは、SP が開始する SAML SSO を使用します。
SAML通信フローは、SPとIDP間の直接通信を意味するものではありません。Webブラウザはすべての通信を処理し、SPとIDP間でファイアウォールポートを開く必要はありません。Web ブラウザだけが SP と IDP の両方と通信できる必要があります。
概念および用語
Citrix ADC nFactorは、特定の展開に必要なさまざまな要素の構成を可能にする一連のエンティティを使用します。次の概念は、Citrix nFactorが使用するポリシーフローを理解するための基礎となります。
- 認証サーバー (アクション):認証サーバー (アクション) は、オンプレミスのActive Directory、Azure AD、Okta、ADFSなど、特定のIDPの特定の構成を定義します。これには、Citrix ADCアプライアンスがIDPと通信し、ユーザーを認証するために必要な詳細が含まれています。
- 認証ポリシー:認証ポリシーにより、ユーザーはアプライアンスに対して認証されます。ポリシーは、適用される式を使用します。式は、ADC が UPN に基づいてユーザーを適切な IDP にリダイレクトするために使用されます。認証ポリシーは、認証サーバー (アクション) にリンクする必要があります。
- これらのシナリオで最も一般的に使用される式はAAA.USER.NAME.SET_TEXT_MODE (IGNORECASE) .AFTER_STR (「@」) .EQ (「domain.com」)です。この式は、「@」記号の後のユーザーの UPN サフィックスを評価し、ポリシーと一致する場合は、構成された SAML サーバー (アクション) を認証に適用します。
- ログインスキーマ:ログインスキーマは、XML で記述されたログオンフォームの論理表現です。言い換えれば、ユーザーインターフェイスを表します。これは、ユーザーに表示するものを定義し、ユーザーからデータを抽出する方法を指定するエンティティです。認証要素ごとに異なるスキーマ (またはスキーマなし) を使用できます。Citrix ADCは、一般的なユースケース向けにいくつかの既成のスキーマテンプレートを提供し、他のユースケースに合わせてカスタマイズできます。
- ポリシーラベル:ポリシーラベルは、特定の要素の認証ポリシーを指定します。各ポリシーラベルは 1 つの認証要素に対応します。これらは基本的に、単一のエンティティとしてリンクできるポリシーの集まりです。ポリシーラベル内のポリシーの結果は、論理「OR」条件に従います。最初のポリシーで指定された認証が成功すると、それに続く他のポリシーはスキップされます。ポリシーラベルは、ログインスキーマを通じてビューを定義します。
- 「認証なし」ポリシー:これは認証の結果として常に「成功」を返す特別なポリシーです。その主な目的は、ユーザー認証フローを通じて論理的な意思決定を行う際の柔軟性を高めることです。
- 次の要素:認証フローが成功した場合に、特定のステップの後に何が行われるかを決定します。追加のポリシーにすることも、認証フローを停止する必要があることを定義することもできます。
- AAA vServer:認証仮想サーバは、関連する認証ポリシーを処理し、環境へのアクセスを提供します。このアーキテクチャでは、AAA 仮想サーバがより一般的な Gateway 仮想サーバに取って代わり、完全にアドレス指定可能な VServer です。ゲートウェイ仮想サーバーは、HDXトラフィックにCitrix ADCを使用する場合にのみ必要です。この場合、AAA仮想サーバーはアドレス指定不可として構成されます。Gateway vServerの統合は、このドキュメントの範囲を超えています。
- 認証プロファイル（オプション）：認証プロファイルでは、AAA 仮想サーバ、つまりそのすべてのポリシーを Gateway 仮想サーバにリンクできます。このプロファイルは、Citrix ADCアプライアンスを介してHDXトラフィックを処理する場合にのみ必要です。
アーキテクチャ
CSPは絶えず成長しており、CVADSベースのDaaSオファリングに新しい顧客を追加しています。この成長により、エンドユーザーが独自のIDソリューションを持ち込み、Citrix Workspace と統合して、CVADSベースのワークロードを使用できるようにする必要が生じています。
Citrix Workspaceは、SSOからSaaSおよびオンプレミスのWebアプリケーション、マイクロアプリの統合とアクション、コンテンツコラボレーションなど、より多くのサービスをCSPが統合できるようにする高度な機能も提供します。また、Azure AD、Okta、SAML 2.0などの複数のIdPとの統合も提供します。ただし、単一のCitrix Workspace からの複数のIdPは現在サポートされていません。
Citrix Gateway サービスは、Citrix Workspace から仮想アプリケーションおよびデスクトップリソースを起動するときにHDXプロキシ機能を処理します。Citrix ADCは複数のIDPサポートを提供する必要があるため、この機能は不要に思えるかもしれません。ただし、HDXプロキシをオフロードすると、CSP側のネットワーク帯域幅と可用性の要件が大幅に簡素化されます。
このリファレンスアーキテクチャは、複数のIdP、特にSAMLベースをCitrix Workspace およびCVADSと統合するための設計上の決定と考慮事項に焦点を当てています。この統合は、ユーザー認証をCitrix ADCに委任するようにCitrix Workspaceを構成することによって実現され、Citrix ADCはユーザーをそれぞれのIdPに転送します。
考慮事項と要件
この記事の執筆時点では、複数のIdPをCSPが管理するCVADS展開に統合することを決定する前に、次の詳細を考慮する必要があります。
- AAA nFactor の機能には、Citrix ADC アドバンストライセンスまたはプレミアムライセンスが必要です。
- Citrix ADC 12.1バージョン54.13以降、または13.0バージョン41.20以降が必要です。
- CVADSマルチテナンシー機能は、FASとリバースフェデレーションの制限により、この展開と互換性がありません。
- SAML IdP が異なれば、設定手順も異なります。これらの手順については、このドキュメントでは取り上げていません。
- Active Directory は、特定の顧客ごとに代替 UPN サフィックスとシャドウアカウントを使用して構成する必要があります。
- 次の AD プロパティは、要求として使用する AD シャドウアカウントで構成する必要があります。
- メールアドレス
- 表示名
- 共通名
- SAMアカウント名
- UPN
- OID
- SID
- FASを構成する前に、Active Directory 証明書サービスを構成して使用できるようにする必要があります。
- Citrix FASはCitrix Workspace と統合されていますが、クラウドサービスではありません。FASはリソースの場所に展開されます。
- IP、証明書、ネットワークの詳細など、ADC の初期設定手順については、このドキュメントでは説明しません。
- 異なる UPN サフィックスにまたがる重複したユーザー名は使用できません。UPN サフィックスが異なっていても、Windows 2000 より前のログイン名はすべてのサフィックスで同じです。
ユーザーエクスペリエンス
次の図は、ユーザーエクスペリエンスの観点から見た認証フローを示しています。エンドユーザーにとって、このエクスペリエンスは、複数のIdPがない従来の実装とかなり似ています。ただし、より一般的な SAM アカウント名ではなく、サインイン時に UPN を使用する必要があることをエンドユーザーに教えることが重要です。
- さまざまな顧客のエンドユーザーが、任意のデバイス/ネットワークからCitrix Workspace に移動します。
- Citrix Workspace は、ユーザーをCitrix ADC AAA仮想サーバーに自動的にリダイレクトします。
- Citrix ADC AAA vServerは、ユーザー名のプロンプトをユーザーに提示します。ユーザーは UPN を入力する必要があります。
- ユーザー認証要求は、ユーザーの UPN サフィックスに基づいて適切な SAML IDP に転送されます。
- ユーザーがIDP経由で認証されると、Citrix Workspace にリダイレクトされます。
- ユーザーが仮想アプリまたは仮想デスクトップを起動しようとすると、CVADサービスが仲介プロセスを処理します。
- Citrix Gateway サービスは、仮想リソースへのHDXプロキシを確立します。
- Active Directory シャドウアカウントは、ユーザーに SSO を提供するスマートカード証明書を要求するために使用されます。
- FASルールが適用され、SSOを介してユーザーのサインイン要求が満たされます。
認証フロー
次の図は、このアーキテクチャにおけるさまざまなプロトコルの認証フローを示しています。Citrix Workspace はOAUTH SPとして機能し、Citrix ADCはOAUTH IDPとSAML SPの両方として機能し、顧客IDPはSAML IDPです。
- エンドユーザーは、WebブラウザーまたはCitrix Workspaceアプリを介してCitrix Workspace（SP）にアクセスします。
- Citrix Workspace（OAUTH SP）に到達すると、ユーザーはCitrix ADC AAA仮想サーバー（OAUTH IDP）にリダイレクトされます。
- ユーザは AAA vServer（SAML SP）ログインプロンプトで UPN を入力し、認証サービス（SAML IDP）にリダイレクトされます。
- SAML IDP はユーザを認証し、SAML アサーション (XHTML 形式) を生成します。
- SAMLアサーションはCitrix Workspace アプリに送り返されます。
- Citrix Workspace アプリは、SAMLアサーションをCitrix ADC AAA仮想サーバーにリダイレクトします。
- Citrix ADC AAA vServerは、セキュリティコンテキストをユーザーエージェントに送り返します。
- Citrix Workspace アプリは、Citrix ADC AAA仮想サーバーからリソースを要求します。
- Citrix ADC AAA vServerがユーザーを認証し、クレームがCitrix Workspace に送信されます。
- リソースにはCitrix Workspace アプリからアクセスできます。
| 注： |
|---|
| SAML フローでは、Web ブラウザー、または Workspace アプリは、HTTP リクエストヘッダーの一部である「ユーザーエージェント」と呼ばれます。 |
ポリシーフロー
次の図は、このアーキテクチャの nFactor ポリシーフローを表しています。nFactor ポリシーフローを理解することは、設計された認証アーキテクチャを成功させるために不可欠です。この図では、LDAP ポリシーが使用されています。LDAPポリシーの使用はオプションですが、管理者にアクセス権を付与するのが一般的な方法です。
- ユーザーは、WebブラウザーまたはCitrix Workspace アプリを介してCitrix Workspace にアクセスします。認証要求は Citrix AAA 仮想サーバに転送されます。Citrix ADCで「TRUE」という表現で構成されたOAUTH IDPポリシーがあります。これは、このポリシーがすべての要求に適用されることを意味します。
- 認証要求が「NO_AUTHN」ポリシーにヒットし、「Username Only」ログインスキーマが表示されます。NO_AUTHN ポリシーはプレースホルダーとして機能します。NO_AUTHN ポリシーは、認証の結果として常に「成功」を返します。
- ユーザーが UPN 形式でユーザー名を入力すると、UPN サフィックスによって評価される認証ポリシーが決まります。このアーキテクチャでは、domain1.com は LDAP サーバーに転送され、domain2.com は Azure AD テナントにリダイレクトされ、domain3.com は別の Azure AD テナントにリダイレクトされます。この機能はすべて、各ポリシーで使用される式に基づいています。また、これらの認証ポリシーは「スキーマなし」ログインスキーマにバインドされていることにも注意してください。この詳細は、ユーザーのウェブブラウザに何も表示されないことを意味します。
- ユーザーが domain1.com でユーザー名を入力すると、LDAP ポリシー (従来の LDAP ポリシー) にリダイレクトされます。このポリシーは「TRUE」と評価されます。これは、評価するすべてのユーザーに影響することを意味します。この場合のログインスキーマは「パスワードのみ」で、ユーザーはこのステップでADパスワードのみを入力することを意味します。ユーザー名は前の要素でキャプチャされます。
- 一方、ユーザーが domain2.com または domain3.com のいずれかでユーザー名を入力すると、ログインのためにそれぞれの Azure AD テナントにリダイレクトされます。この場合、Azureはすべての認証を処理しますが、これはCitrix ADC nFactorエンジンの領域外です。ユーザーが認証されると、Citrix ADC AAA vServerにリダイレクトされます。
- 認証要求がCitrix Gateway にリダイレクトされると、LDAPポリシーに関連付けられている別の認証要素を通過します。ただし、このポリシーは認証を実行しません。このポリシーの目的は、ユーザーを認証するために必要な要求をCitrix Workspace に抽出することです。すべての SAML ポリシーは、この単一の LDAP ポリシーにリダイレクトされます。ユーザーにはログインスキーマは表示されず、この時点では情報を入力する必要もありません。このプロセスは自動的に行われます。
- ユーザーの要求はCitrix ADCに保存され、Citrix Workspace に渡されます。これらの要求は、Citrix Workspace がCitrix ADCからの認証を受け入れるために必要です。
- ユーザーはCitrix Workspace にリダイレクトされ、リソースにアクセスできるようになります。
| 注： |
|---|
| LDAPの「認証なし」ポリシーは、ユーザーが別の要素によって認証された後にのみ使用されます。認証の結果として常に「成功」と評価されます。 |
スケーリングに関する考慮事項
新規顧客のオンボーディングに合わせてこのソリューションをアジャイルに拡張できることは、CSP にとって重要です。このアーキテクチャにより、新規顧客のオンボーディング時に無停止の手順に従うことができます。新規顧客をこのソリューションに導入する主な手順は次のとおりです。
- エンドカスタマー IDP を構成する:これは CSP の責任に該当する場合と該当しない場合があります。ほとんどの SAML IdP は、これらのタイプのソリューションを設定するための広範なドキュメントを提供しています。
- カスタマー UPN サフィックスを追加:これは Active Directory ドメインと信頼関係の MMC コンソールを介して行われます。UPN サフィックスは一意である必要があります。また、UPNは共有AD環境の顧客ごとに異なりますが、すべてのシャドウアカウントには同じNetBIOSサフィックス名があります。
- シャドウアカウントの追加:シャドウアカウントを手動で作成することは大変な作業になる可能性があり、このプロセスを自動化するにはスクリプト作成が推奨されます。エンドユーザーは、これらのアカウントのパスワードを知っている必要はありません。
- SAML アクションとポリシーを設定する:このソリューションにオンボーディングされる新規顧客ごとに、新しい SAML アクションとポリシーを構成する必要があります。アクションにはすべての SAML IDP 詳細が含まれ、ポリシーにはポリシーの評価に使用される式が含まれます。
- SAMLポリシーのバインド:新しいSAML認証ポリシーを、さまざまな顧客のすべての認証ポリシーをグループ化するSAMLポリシーラベルに追加する必要があります。これらのポリシーはすべて相互に排他的であるため、ポリシーラベルに新しいポリシーを追加しても、現在の顧客に混乱が生じることはありません。
| 注： |
|---|
| 異なる UPN サフィックスにまたがる重複したユーザー名は使用できません。UPN サフィックスが異なっていても、Windows 2000 より前のログイン名は重複ユーザーに対して同じになります。 |
実装
このドキュメントでは、Citrix WorkspaceをCitrix ADC AAA仮想サーバーおよび複数のSAML IdPと統合するために必要な手順について説明します。Cloud Connectorの構成、マシンカタログ/デリバリーグループの作成、およびFASの実装は、このドキュメントの範囲外です。
前述のコンポーネントを適切に構成するには、標準的なインストール方法に従います。これらをこのアーキテクチャと統合するためにカスタム設定手順は必要ありません。設定手順については、このドキュメントの「その他の設定リソース」セクションを参照してください。
認証ポリシー
LDAP 認証アクション (オプション)
1-Citrix ADCアプライアンスにログインし、[ **セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > [アクション] > [LDAP]**に移動して［追加］をクリックします。
2-[認証LDAPサーバーの作成] ページで、次の情報を入力します。
- 名前:LDAP 認証サーバエンティティ名
- サーバー名/サーバーIP: サーバー名をお勧めします
- セキュリティタイプ:セキュリティ要件に基づくプレーンテキストまたは SSL。(SSL 推奨)
- ポート:セキュリティタイプに基づいて389または636。
- サーバータイプ:AD
- 認証:チェック済み
- ベース DN: ユーザー検索の AD ベースの DN
- 管理者バインド DN: AD サービスアカウント UPN
- 管理者パスワード:AD サービスアカウントのパスワード
- 管理者パスワードの確認:AD サービスアカウントのパスワード
- サーバーログオン名属性:userPrincipalName
- グループ属性:memberOf
- サブ属性名:cn
- SSO 名属性:cn
- 電子メール:メール
3-「OK」をクリックします。
| 注： |
|---|
| このステップはオプションですが,サポートの目的で強くお勧めします。環境管理者が AD 認証情報を使用して環境に対してログインできるようにするには、このアクションを作成します。 |
LDAP ユーザー属性アクション
1-[LDAP アクション] ページで [追加] をクリックし、2 つ目の LDAP アクションを作成します。前の情報と同じ情報を使用しますが、今回は [認証]ボックスのチェックを外します。
2-「OK」をクリックします。
| 注： |
|---|
| このステップはオプションではありません。このアクションは、SAML IDP を介して認証された後に、AD のシャドウアカウントからユーザーのクレームを抽出するために使用されます。これらの要求は、Citrix Workspace へのリダイレクトを正常に行うために必要です。 |
SAML アクション
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > [アクション] > **[SAML**に移動します。
2-[認証SAMLサーバーの作成] ページで、次の情報を入力します。
- 名前:SAML 認証サーバーエンティティ名
- リダイレクト URL: IDP から提供されたリダイレクト URL
- シングルログアウト URL: IDP から提供されたログアウト URL
- SAML バインディング:POST/リダイレクト/アーティファクト
- ログアウトバインド:POST/REDIRE
- IDP 証明書名:[追加] をクリックして、SAML IDP からダウンロードした証明書をインポートします。
- 署名証明書名:Citrix ADC AAA 仮想サーバー SSL 証明書
- 問題名:AAA 仮想サーバ URL と同じ
- 署名されていないアサーションを拒否:オン
- 署名アルゴリズム:RSA-SHA256
- ダイジェスト方法:SHA256
3-「OK」をクリックします。
| 注： |
|---|
| これらの手順を繰り返して、使用する SAML IDP ごとに個別の SAML アクションを作成します。 |
| このページで入力する必要のあるフィールドは、SAML IDP によって異なります。追加情報については、特定の SAML IDP ドキュメントを参照してください。 |
ログインスキーマ
ログインスキーマプロファイル
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ログインスキーマ] > **[プロファイル**] に移動し
2-[認証ログインスキーマの作成] ページで、次の情報を入力します。
- 名前:ログインスキーマプロファイルエンティティ名
- 認証スキーマ:noschema
3-[作成] をクリックします。
| 注： |
|---|
| これらの手順を繰り返して、OnlyUsername.xmlファイルとOnlyPassword.xmlファイルを使用して残りの 2 つのスキーマプロファイルを作成します。 |
ログインスキーマポリシー
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ログインスキーマ] > **[ポリシー**] に移動し
2-[認証ログインスキーマポリシーの作成] ページで、次の情報を入力します。
- Name: ログインスキーマポリシーエンティティ名
- プロファイル:以前に作成した NoSchema プロファイル
- ルール:TRUE
3-[作成] をクリックします。
| 注： |
|---|
| これらの手順を繰り返して、残りの 2つのスキーマポリシーを「Username Only」および「Password Only」スキーマプロファイルにリンクして作成します。 |
認証ポリシー
ベースラインの「認証なし」ポリシー
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] >[ポリシーに移動します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーエンティティ名
- 認証タイプ:NO_AUTHN
- 式:HTTP.REQ.URL.CONTAINS (「/nf/auth/doAuthentication.DO」)
3-「OK」をクリックします。
LDAP「認証なし」ポリシー (オプション)
1-[認証ポリシー] ページで [追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーエンティティ名
- 認証タイプ:NO_AUTHN
- 式:AAA.USER.LOGIN_NAME.SET_TEXT_MODE (大文字小文字を無視) .AFTER_STR (「@」) .EQ (「domain1.com」)
3-「OK」をクリックします。
| 注： |
|---|
| このステップはオプションですが,サポートの目的で強くお勧めします。このポリシーを作成して,環境管理者が AD 認証情報を使用して環境に対してログインできるようにします。 |
| 式の「domain1.com」を内部 AD ドメイン UPN サフィックスの名前に置き換えます。 |
| NO_AUTHN認証タイプは、別の LDAP ポリシーで処理される次の認証要素 (AD パスワード) にユーザーをリダイレクトするプレースホルダーとして使用されます。 |
LDAP 認証ポリシー (オプション)
1-[認証ポリシー] ページで [追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーエンティティ名
- 認証タイプ:LDAP
- アクション:以前に作成した LDAP 認証アクション
- 式: TRUE
3-「OK」をクリックします。
| 注： |
|---|
| このステップはオプションですが,サポートの目的で強くお勧めします。このポリシーを作成して,環境管理者が AD 認証情報を使用して環境に対してログインできるようにします。 |
| このポリシーのTRUE式は、この認証要素にリダイレクトされるすべてのユーザーに対してこのポリシーが評価されることを意味します。 |
| このポリシーは、以前に作成したPassword Onlyログインスキーマに関連付けられています。 |
LDAP ユーザー属性ポリシー
1-[認証ポリシー] ページで [追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーエンティティ名
- 認証タイプ:LDAP
- アクション:以前に作成した LDAP ユーザー属性アクション
- 式: TRUE
3-「OK」をクリックします。
| 注： |
|---|
| このステップはオプションではありません。このポリシーは、SAML IDP を介して認証された後、AD のシャドウアカウントからユーザーのクレームを抽出するために使用されます。これらの要求は、Citrix Workspace へのリダイレクトを正常に行うために必要です。 |
| このポリシーのTRUE式は、この認証要素にリダイレクトされるすべてのユーザーに対してこのポリシーが評価されることを意味します。 |
| このポリシーはNO_SCHEMA ログインスキーマに関連付けられています。 |
SAML 認証ポリシー
1-[認証ポリシー] ページで [追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーエンティティ名
- 認証タイプ:SAML
- アクション:以前に作成した SAML 認証アクション
- 式:AAA.USER.LOGIN_NAME.SET_TEXT_MODE (大文字小文字を無視) .AFTER_STR (「@」) .EQ (「domain2.com」)
3-「OK」をクリックします。
| 注： |
|---|
| 式の「domain2.com」を顧客のドメイン名に置き換えます。 |
| 以前に作成した SAML 認証アクションごとに SAML 認証ポリシーを作成し、式内の適切なドメイン名と 1:1 で一致させます。 |
認証ポリシーラベル
LDAP 認証ポリシーラベル
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > **[ポリシーラベル**]に移動します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーラベルエンティティ名
- ログインスキーマ:「パスワードのみ」ログインスキーマプロファイル
- フィーチャタイプ:AAATM_REQ
- 続ける] をクリックします
3-認証ポリシーを次の詳細でバインドします。
- ポリシー 1
- ポリシーの選択:LDAP 認証ポリシー
- 優先度:100
- Goto Expression: END
- 次のファクターを選択:N/A
4-[完了] をクリックします。
LDAP ユーザー属性ポリシーラベル
1-[認証ポリシーラベル] ページで、[追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーラベルエンティティ名
- ログインスキーマ:「NO_SCHEMA」ログインスキーマプロファイル
- フィーチャタイプ:AAATM_REQ
- 続ける] をクリックします
3-認証ポリシーを次の詳細でバインドします。
- ポリシー 1
- ポリシーの選択:LDAP ユーザー属性ポリシー
- 優先度:100
- Goto Expression: END
- 次のファクターを選択:N/A
4-[完了] をクリックします。
メインポリシーラベル
1-[認証ポリシーラベル] ページで、[追加] をクリックして別のポリシーを作成します。
2-[認証ポリシーの作成] ページで、次の情報を入力します。
- 名前:認証ポリシーラベルエンティティ名
- ログインスキーマ:「NO_SCHEMA」ログインスキーマプロファイル
- フィーチャタイプ:AAATM_REQ
- 続ける] をクリックします
3-認証ポリシーを次の詳細でバインドします。
- ポリシー 1
- ポリシーを選択:LDAP「認証なし」ポリシー
- 優先度:100
- Goto Expression: NEXT
- 次の要素を選択:LDAP 認証ポリシーラベル
- ポリシー 2
- [ポリシー]を選択します。(SAML認証ポリシー]
- 優先度:110
- Goto Expression: NEXT
- 次の要素を選択:LDAP ユーザー属性ポリシーラベル
4-[完了] をクリックします。
| 注： |
|---|
| 新規顧客/ IdPをオンボーディングするときは、それぞれのSAML認証ポリシーをこのポリシーラベルに追加する必要があります。 |
AAA vServer
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [仮想サーバ] に移動し、[
2-[認証仮想サーバー] ページで、次の情報を入力します。
- 名前:認証仮想サーバーエンティティ名
- IPアドレスタイプ:IPアドレス
- IPアドレス:VServerが割り当てたIPアドレス
- ポート：443
- OKをクリックします。
3-[証明書] ペインで、[サーバー証明書なし] をクリックし、SSL 証明書を VServer にバインドします。次に、[続行] をクリックします。
4-[高度な認証ポリシー] ペインで、[認証ポリシーなし] をクリックし、次の情報を入力します。
- ポリシーの選択:ベースライン「認証なし」ポリシー
- 優先度:100
- Goto Expression: NEXT
- 次の要素を選択:メインポリシーラベル
5-[続行] をクリックします。
6-[詳細設定] ペインで、[ログインスキーマ] をクリックします。
7-[ログインスキーマ] ペインで、[ログインスキーマなし] をクリックし、次の情報を入力します。
- ポリシーを選択:「ユーザー名のみ」スキーマポリシー
- 優先度:100
- Goto Expression: END
8-[バインド] をクリックします。
9-[AAA vServer] ページに戻り、[完了] をクリックします。
| 注： |
|---|
| この時点で、AAA 仮想サーバ URL はパブリックに到達可能で、LDAP と SAML の両方の認証が機能します。 |
グローバル証明書バインディング
1-SSH経由でCitrixADCに接続し、管理者の資格情報で認証します。
2-次のコマンドを実行します。bind vpn グローバル-certKeyName certname。
3-実行構成を保存します。
| 注： |
|---|
| このコマンドは、認証プロセスの一環としてCitrix Workspace に送信されるトークンに署名するためにADCによって使用されます。 |
| -certKeyName フラグは、AAA 仮想サーバで使用されているのと同じ SSL 証明書を参照します。 |
Citrix Workspace 統合
Citrix Gateway IDP
1-Webブラウザーで、Citrix Cloudに移動し、Citrix資格情報を使用してログインします。
2-認証が完了したら、[IDおよびアクセス管理] > [認証] > [Citrix Gateway] に移動し、[接続] をクリックします。
3-設定ポップアップ画面で、パブリックにアクセス可能な AAA 仮想サーバ FQDN を入力し、[検出（Detect）] をクリックします。検出されたら、[続行] をクリックします。
4-[接続の作成] 画面で、[クライアント ID]、[シークレット]、[リダイレクト URL]をコピーします。
| 注： |
|---|
| このページを閉じないでください。設定を完了するには戻ってくる必要があります。 |
OAUTH IDP プロファイル
1-Citrix ADCに戻り、[ **セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > [OAUTH IDP] > [プロファイル] に移動し**
2-[認証 OAUTH IDP プロファイルの作成] ページで、次の情報を入力します。
- 名前:OAUTH IDP 認証プロファイルエンティティ名
- クライアントID: Citrix Cloud から値を貼り付ける
- クライアントシークレット:Citrix Cloud から値を貼り付ける
- リダイレクトURL: Citrix Cloud から値を貼り付ける
- 発行者名:ADC AAA vServer ベース URL
- 対象者:クライアントIDと同じ
- パスワードを送信:チェック済み
3-[作成] をクリックします。
OAUTH IDP ポリシー
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > [OAUTH IDP] > **[ポリシー**に移動して［追加］をクリックします。
2-[認証 OAUTH IDP ポリシーの作成] ページで、次の情報を入力します。
- 名前:OAUTH IDP 認証ポリシーエンティティ名
- アクション:OAUTH IDP 認証プロファイル
- 式: TRUE
3-[作成] をクリックします。
OAUTH IDP ポリシーバインディング
1-[セキュリティ] > [AAA — アプリケーショントラフィック] > [仮想サーバ] に移動し、以前に作成したAAA vServerをクリックします。
2-[高度な認証ポリシー] ペインで、[OAuth IDP ポリシーなし] をクリックし、OAUTH IDP ポリシーをバインドします。
3-[AAA vServer] ページに戻り、[完了] をクリックします。
ワークスペース認証
1-Citrix Cloud に戻り、［構成］ページで［テストして終了］をクリックします。
2-[ワークスペース構成] > [認証] に移動し、[Citrix Gateway]
3-設定ポップアップ画面で、[サブスクライバーエクスペリエンスへの影響を理解しています] の横にあるチェックボックスをオンにして、[保存] をクリックします。
| 注： |
|---|
| この時点で、Citrix Workspace URL（customer.cloud.com）に移動すると、ユーザーはADC AAA vServerにリダイレクトされます。ユーザーがそれぞれのIDPでログインすると、Citrix Workspace にリダイレクトされます。 |
| 仮想アプリケーションおよびデスクトップリソースへのシングルサインオンは、Citrix Workspace FASと統合することで実現できます。 |