関連する適応認証構成
FQDNを編集する
ワークスペース構成で認証方法として アダプティブ認証 が選択されている場合は、FQDN を編集できません。 FQDN を編集するには、別の認証方法に切り替える必要があります。 ただし、必要に応じて証明書を編集できます。
重要:
- FQDN を変更する前に、新しい FQDN が IdP 仮想サーバーのパブリック IP アドレスにマップされていることを確認してください。
- OAuth ポリシーを使用して Citrix Gateway に接続している既存のユーザーは、認証方法を Adaptive Authenticationに移行する必要があります。 詳細については、「 認証方法を Adaptive Authentication に移行する」を参照してください。
FQDN を編集するには、次の手順を実行します。
-
適応認証から別の認証方法に切り替えます。
-
加入者エクスペリエンスへの影響を理解しています、 を選択し、 確認をクリックします。
確認をクリックすると、エンドユーザーへのワークスペース ログインが影響を受け、Adaptive Authentication が再度有効になるまで、認証に Adaptive Authentication は使用されません。 したがって、メンテナンス期間中に FQDN を変更することをお勧めします。
-
証明書のアップロード 画面で、FQDN を変更します。
-
変更を保存をクリックします。
重要:
FQDN を編集する場合は、証明書も再度アップロードする必要があります。
-
Adaptive Authentication ホームページで 有効 (手順 3) をクリックして、Adaptive Authentication 方式を再度有効にします。
-
[ 更新] をクリックします。
カスタムワークスペース URL またはバニティ URL
カスタム ワークスペース URL を使用すると、選択したドメインを使用して Citrix Workspace ストアにアクセスできます。 ユーザーは、デフォルトのワークスペース URL またはカスタム ワークスペース URL、あるいはその両方を使用してワークスペースにアクセスできます。
カスタム ワークスペース URL またはバニティ URL を構成するには、次の手順を実行する必要があります。
- カスタム ドメインを構成します。 詳細については、「 カスタム ドメインの構成」を参照してください。
-
現在のプロファイルまたはデフォルトのプロファイル (AAuthAutoConfig_oauthIdpProf) と同じクライアント ID、シークレット、およびオーディエンスを持ち、リダイレクト URL が異なる新しい OAuthIDP プロファイルを構成します。 詳細については、「 OAuth ポリシーとプロファイルの構成」を参照してください。
例:
現在のプロフィール:
-
add authentication OAuthIDPProfile AAuthAutoConfig_oauthIdpProf -clientID xxxx -clientSecret yyyy -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2023_07_09_20_09_30 -redirectURL "https://accounts-internal.cloud.com/core/login-cip" -audience zzzz -sendPassword ON
add authentication OAuthIdPPolicy AAuthAutoConfig_oauthIdpPol -rule true -action AAuthAutoConfig_oauthIdpProf
bind authentication vserver auth_vs -policy AAuthAutoConfig_oauthIdpPol -priority 100 -gotoPriorityExpression NEXT
新しいプロフィール:
add authentication OAuthIDPProfile AAuthAutoConfig_oauthIdpProf_Custom1 -clientID xxxx -clientSecret yyyy -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2023_07_09_20_09_30 -redirectURL "https://custom_domain/core/login-cip" -audience zzzz -sendPassword ON
add authentication OAuthIdPPolicy AAuthAutoConfig_oauthIdpPol_Custom1 -rule true -action AAuthAutoConfig_oauthIdpProf_Custom1
bind authentication vserver auth_vs -policy AAuthAutoConfig_oauthIdpPol_Custom1 -priority 101 -gotoPriorityExpression NEXT
重要:
- OAuth ポリシーとプロファイルは、プロビジョニング フェーズ中に Adaptive Authentication サービスによって作成されます。 その結果、Citrix Cloud 管理者は暗号化されていないクライアントシークレットにアクセスできなくなります。 暗号化されたシークレットは ns.conf ファイルから取得できます。 OAuth プロファイルを作成するには、暗号化されたシークレットを使用し、CLI コマンドのみを使用してプロファイルを作成する必要があります。
- NetScaler ユーザー インターフェイスを使用して OAuth プロファイルを作成することはできません。
Adaptive Authenticationインスタンスのアップグレードをスケジュールする
現在のサイトまたは展開では、アップグレードのメンテナンス ウィンドウを選択できます。
重要:
Adaptive Authentication インスタンスをランダムな RTM ビルドにアップグレードしないでください。 すべてのアップグレードは Citrix Cloud によって管理されます。
-
Adaptive Authentication UI の Adaptive Authentication インスタンスのプロビジョニング セクションで、省略記号ボタンをクリックします。
- アップグレードのスケジュールをクリックします。
- アップグレードの日時を選択します。
Adaptive Authenticationインスタンスのプロビジョニングを解除する
お客様は、以下の場合および Citrix サポートからの提案に従って、Adaptive Authentication インスタンスのプロビジョニングを解除できます。
- このシナリオは発生しない可能性がありますが、Adaptive Authentication インスタンスにはアクセスできません (特にスケジュールされたアップグレード後)。
- 顧客が VNet ピアリング モードからコネクタ モードに切り替える必要がある場合、またはその逆の場合。
- 顧客が VNet ピアリング モードのプロビジョニング時に間違ったサブネットを選択した場合 (サブネットがデータ センターまたは Azure VNet 内の他のサブネットと競合します)。
注意:
プロビジョニング解除すると、インスタンスの構成バックアップも削除されます。 したがって、Adaptive Authentication インスタンスをプロビジョニング解除する前に、バックアップ ファイルをダウンロードして保存する必要があります。
Adaptive Authentication インスタンスをプロビジョニング解除するには、次の手順を実行します。
-
Adaptive Authentication UI の Adaptive Authentication インスタンスのプロビジョニング セクションで、省略記号ボタンをクリックします。
-
プロビジョニング解除をクリックします。
注意:
プロビジョニングを解除する前に、 Citrix Gateway をワークスペース構成から切断する必要があります。
- Adaptive Authentication インスタンスをプロビジョニング解除するには、顧客 ID を入力します。
ゲートウェイへの安全なアクセスを有効にする
- Adaptive Authentication UI の Adaptive Authentication インスタンスのプロビジョニング セクションで、省略記号ボタンをクリックします。
-
セキュア管理アクセスをクリックします。
- キーの有効期限はで、新しい SSH キーの有効期限を選択します。
-
キーの生成とダウンロードをクリックします。 SSH 秘密キーはページを閉じると表示されないため、後で使用するためにコピーまたはダウンロードしてください。 このキーは、ユーザー名
authadmin
を使用して Adaptive Authentication インスタンスにログインするために使用できます。以前のキー ペアの有効期限が切れた場合は、[ キーの生成とダウンロード ] をクリックして新しいキー ペアを作成できます。 ただし、アクティブにできるキー ペアは 1 つだけです。
- [完了] をクリックします。
重要:
Windows 上で PuTTY を使用して Adaptive Authentication インスタンスに接続する場合は、ダウンロードした秘密キーを PEM に変換する必要があります。 詳しくは、https://www.puttygen.com/convert-pem-to-ppkを参照してください。
MAC のターミナルまたは Windows (バージョン 10) の PowerShell/コマンド プロンプト経由で Adaptive Authentication インスタンスに接続するには、次のコマンドを使用することをお勧めします。
ssh -i <path-to-private-key> authadmin@<ip address of ADC>
AD ユーザーが Adaptive Authentication GUI にアクセスできるようにするには、そのユーザーを新しい管理者として LDAP グループに追加する必要があります。 詳しくは、https://support.citrix.com/article/CTX123782を参照してください。 その他のすべての構成では、CLI コマンドではなく Adaptive Authentication GUI を使用することをお勧めします。
Azure VNet ピアリングを使用してオンプレミスの認証サーバーへの接続を設定する
接続タイプとして Azure VNet ピアリングを選択した場合のみ、この構成を設定する必要があります。
注意:
Okta、Azure AD、Ping などのサードパーティの IDP を使用している場合、この手順は必要ありません。
-
Connect Adaptive Authentication UI で、 Provisionをクリックし、次に Azure VNet Peeringをクリックします。
Citrix マネージド サービス プリンシパル フィールドには、Citrix が顧客向けに作成した Azure サービス プリンシパルのアプリケーション ID が含まれます。 このサービス プリンシパルは、Citrix がサブスクリプションおよびテナント内の VNet に VNet ピアリングを追加できるようにするために必要です。
このサービス プリンシパルが顧客テナントにログインできるようにするには、顧客サイトの管理者 (テナントのグローバル管理者) が次の PowerShell コマンドを実行して、SPN をテナントに追加する必要があります。 CloudShellも使用可能です。
Connect-AzureAD
New-AzureADServicePrincipal -AppId $App_ID
ここで、$App_ID
は、Citrix によって共有される SPN アプリケーション ID です。
注意:
- 前述のコマンドは、ロールの割り当てに使用する必要のあるサービス プリンシパル名を出力します。
- このサービス プリンシパルが Azure VNet ピアリングを追加できるようにするには、顧客サイトの管理者 (グローバル管理者に限定されません) が、Citrix 管理 VNet にリンクする必要がある VNet に「ネットワーク共同作成者」ロールを追加する必要があります。
- SPN は、Azure 内の Citrix 仮想ネットワークを関連付けるために使用される一意の識別子です。 SPN を VNet に関連付けると、Citrix 仮想ネットワークは Azure の VNet を介して顧客のオンプレミス ネットワークに接続できるようになります。
-
VNet ピアリングを作成します。
- 前の手順を実行したテナント ID を入力し、[ 取得] をクリックします。
これにより、SPN のネットワーク コントリビューター ロールが追加される候補 VNet が、顧客管理の VNet リソース ID に入力されます。 VNet が表示されない場合は、前の手順が正しく実行されていることを確認するか、手順を繰り返します。
注意:
テナント ID を見つける方法の詳細については、 https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenantを参照してください。
- オンプレミス ネットワークを Azure に接続するには、 Azure VPN Gateway の使用 を選択します。
- 顧客管理 VNet リソース IDで、ピアリング用に識別された VNet を選択し、 追加をクリックします。 VNet は、最初は 進行中のステータスでテーブルに追加されます。 ピアリングが正常に完了すると、ステータスが 完了に変わります。
- [完了] をクリックします。
- 設定を続行します。「 ステップ 1: 適応型認証のプロビジョニング」を参照してください。
重要:
- Citrix 管理 VNet とオンプレミス ネットワークの間でトラフィックを流すには、オンプレミスでファイアウォールとルーティング ルールを変更して、トラフィックを Citrix 管理 VNet に誘導する必要があります。
- 一度に追加できる VNet ピアは 1 つだけです。 現在、複数の VNet ピアリングは許可されていません。 必要に応じて、VNet ピアリングを削除したり、作成したりできます。
設定のバックアップと復元
アプリケーション配信管理サービスは、Adaptive Authentication インスタンスのバックアップ管理を実行します。 詳細については、「 NetScaler インスタンスのバックアップと復元」を参照してください。
- 「 アプリケーション配信管理 」タイルで、「 管理」をクリックします。
- インフラストラクチャ > インスタンス に移動して、バックアップにアクセスします。
注意:
オンボードされたサービスが表示されない場合は、Application Delivery Management サービスをオンボードします。 詳細については、「 はじめに」を参照してください。
LDAP および LDAPS 負荷分散構成のサンプル
Citrix Adaptive Authentication インスタンスは、負荷分散仮想サーバーを使用して LDAP/LDAPS サポートを提供します。
注意:
- LDAP/LDAPS の負荷分散を使用していない場合は、Adaptive Authentication トンネルが破損する可能性があるため、LDAP サーバー用のサービスまたはサーバーを作成しないでください。
- LDAP の負荷分散を使用している場合は、サービス グループを作成し、それをスタンドアロン サービスではなく負荷分散サービスにバインドします。
- 認証に負荷分散仮想サーバーを使用する場合は、LDAP アクションに実際の LDAP サーバー IP アドレスではなく、負荷分散仮想サーバーの IP アドレスを追加するようにしてください。
- デフォルトでは、TCP モニターは作成したサービスにバインドされます。 Adaptive Authentication NetScaler インスタンスでは、TCP モニターが使用されている場合、サービスはデフォルトで UP としてマークされます。
- 監視にはカスタム モニターの使用をお勧めします。
前提条件
負荷分散仮想サーバーのプライベート IP アドレス (RFC1918 アドレス)。 このアドレスは内部構成に使用されるため、ダミーの IP アドレスにすることができます。
負荷分散LDAPサーバー
負荷分散 LDAP サーバーの場合は、サービス グループを作成し、それを負荷分散仮想サーバーにバインドします。 LDAP サーバーの負荷分散用のサービスを作成しないでください。
NetScaler CLI を使用して LDAP を構成します。
LDAP を構成するには、次の CLI コマンドを参考にすることができます。
add serviceGroup <serviceGroupName> <serviceType>
bind servicegroup <serviceGroupName> (<IP> | <serverName>) <port>
-
add lb vserver <name> <serviceType> <ip> <port>
- ポートは 389 である必要があります。 このポートは内部通信に使用され、オンプレミス サーバーへの接続は、サービス グループに構成されたポートに基づいて SSL 経由で行われます。 bind lb vserver <name> <serviceGroupName>
add authentication ldapAction <name> {-serverIP} <ip_addr> | {-serverName <string>}} <lb vserver ip>
add authentication policy <ldap_policy_name> -rule <expression> -action <string>
bind authentication vserver auth_vs -policy <ldap_policy_name> -priority <ldap_policy_priority> -gotoPriorityExpression NEXT
NetScaler GUI を使用して LDAP を構成します。
- トラフィック管理 > 負荷分散 に移動し、 仮想サーバーをクリックします。
-
タイプ TCP およびポート 389 の仮想サーバーを作成します。
SSL/SSL_TCP タイプの負荷分散仮想サーバーを作成しないでください。
- トラフィック管理 > 負荷分散 に移動し、 サービス グループをクリックします。
- タイプ TCP およびポート 389 のサービス グループを作成します。
- 手順 1 で作成した仮想サーバーにサービス グループをバインドします。
手順の詳細については、「 基本的な負荷分散の設定」を参照してください。
負荷分散LDAPSサーバー
LDAPS サーバーの負荷分散では、Adaptive Authentication インスタンスへの内部 SSL 暗号化または復号化を回避するために、TCP タイプの負荷分散仮想サーバーを作成する必要があります。 この場合、負荷分散仮想サーバーが TLS 暗号化/復号化を処理します。 SSL タイプの負荷分散仮想サーバーを作成しないでください。
NetScaler CLI を使用して LDAPS を構成します。
LDAPS を設定するには、次の CLI コマンドを参考にしてください。
-
add lb vserver <name> <serviceType> <ip> <port>
- ポートは 636 である必要があります。 bind lb vserver <name> <serviceGroupName>
add authentication ldapAction <name> {-serverIP} <ip_addr> | {-serverName <string>}} <lb vserver ip>
add authentication policy <ldap_policy_name> -rule <expression> -action <string>
bind authentication vserver auth_vs -policy <ldap_policy_name> -priority <ldap_policy_priority> -gotoPriorityExpression NEXT
NetScaler GUI を使用して LDAPS を構成します。
- トラフィック管理 > 負荷分散 に移動し、 仮想サーバーをクリックします。
-
タイプ TCP およびポート 636 の仮想サーバーを作成します。
SSL/SSL_TCP タイプの負荷分散仮想サーバーを作成しないでください。
- トラフィック管理 > 負荷分散 に移動し、 サービスをクリックします。
- SSL_TCP タイプとポート 636 のサービスを作成します。
- 手順 1 で作成した仮想サーバーにサービスをバインドします。
手順の詳細については、「 基本的な負荷分散の設定」を参照してください。
カスタムモニターを作成する
NetScaler GUI を使用してカスタム モニターを作成します。
- Traffic Management > Load Balancing > Monitorsに移動します。
- LDAP タイプのモニターを作成します。 モニター プローブ間隔を 15 秒に設定し、応答タイムアウトを 10 秒に設定してください。
- このモニターをサービスにバインドします。
詳細については、「 カスタム モニター」を参照してください。
最大15個の管理IPアドレスを追加可能
Adaptive Authentication サービスを使用すると、最大 15 個のパブリック IP サブネットと個別の IP アドレスを入力して、Adaptive Authentication 管理コンソールにアクセスできます。
IP アドレス/サブネットを入力する際の注意点:
- パブリック IP サブネットの CIDR が /20 〜 /32.B の範囲内であることを確認します。
- エントリ間に重複がないことを確認してください。
例:
- 192.0.2.0/24 と 192.0.2.8 は受け入れられません。192.0.2.8 は 192.0.2.0/24 内にあるためです。
- 重複するサブネット: 192.0.2.0/24 と 192.0.0.0/20 はサブネットが重複しているため受け入れられません。
-
ネットワーク サブネット値を入力するときに、IP アドレス値としてネットワーク IP アドレスを入力します。
例:
- 192.0.2.2/24 は正しくありません。代わりに 191.0.2.0/24 を使用してください。
- 192.0.2.0/20 は正しくありません。代わりに 192.0.0.0/20 を使用してください。
この機能を有効にするには、Citrix サポートにお問い合わせください。
認証方法を適応認証に移行する
認証方法を Citrix Gateway として Adaptive Authentication をすでに使用しているお客様は、 Adaptive Authentication を移行し、Adaptive Authentication インスタンスから OAuth 構成を削除する必要があります。
- Citrix Gateway 以外の認証方法に切り替えます。
-
Citrix Cloud > Identity and Access Managementで、Citrix Gateway に対応する省略記号ボタンをクリックし、 切断をクリックします。
-
加入者エクスペリエンスへの影響を理解していますを選択し、 確認をクリックします。
確認をクリックすると、エンドユーザーへのワークスペース ログインが影響を受け、Adaptive Authentication が再度有効になるまで、認証に Adaptive Authentication は使用されません。
-
Adaptive Authentication インスタンス管理コンソールで、OAuth 関連の構成を削除します。
CLI を使用する場合:
unbind authentication vs <authvsName> -policy <oauthIdpPolName> rm authentication oauthIdpPolicy <oauthIdpPolName> rm authentication oauthIdpProfile <oauthIdpProfName> <!--NeedCopy-->
GUI を使用する場合:
- セキュリティ > AAA-アプリケーショントラフィック > 仮想サーバに移動します。
- OAuth ポリシーのバインドを解除します。
- セキュリティ > AAA - アプリケーション トラフィック > ポリシー > 認証 > 高度なポリシー > OAuth IDPに移動します。
- OAuth ポリシーとプロファイルを削除します。
-
Citrix Cloud > Identity and Access Managementに移動します。 [認証] タブの [適応型認証] で、省略記号メニューをクリックし、[ 管理] を選択します。
または、 https://adaptive-authentication.cloud.comにアクセスします。
- 詳細を見るをクリックします。
-
証明書のアップロード 画面で、次の操作を行います。
- アダプティブ認証 FQDN を追加します。
- 証明書とキーファイルを削除して再度アップロードしてください。
重要:
Adaptive Authenticationに移行せずに FQDN または証明書とキーのペアを直接編集すると、Identity and Access Management への接続が失敗し、次のエラーが表示されます。 これらのエラーを修正するには、Adaptive Authentication 方式に移行する必要があります。
- ADC コマンドがエラーで失敗しました。 ポリシーは指定された優先度にすでにバインドされています。
- ADC コマンドがエラーで失敗しました。 バインドされていないポリシーをバインド解除することはできません。
-
変更を保存をクリックします。
この時点で、Identity and Access Management では、 Adaptive Authentication が 接続済み として表示され、Adaptive Authentication インスタンスには OAuth プロファイルが自動的に構成されます。
これは GUI から検証できます。
- Adaptive Authentication インスタンスにアクセスし、資格情報を使用してログインします。
- セキュリティ > AAA-アプリケーショントラフィック > 仮想サーバに移動します。 OAuth IdP プロファイルが作成されたことを確認する必要があります。
- Citrix Cloud > Identity and Access Managementに移動します。 適応認証は 接続済み 状態です。
-
Adaptive Authentication ホームページで 有効 (手順 3) をクリックして、Adaptive Authentication 方式を再度有効にします。
この手順により、ワークスペース構成で認証方法として Adaptive Authentication が有効になります。
- 有効をクリックした後、手順 3 でワークスペース リンクをクリックします。 認証方法が Adaptive Authentication に変更されていることを確認する必要があります。
注意:
新規ユーザーは、OAuth 関連の構成を削除する手順を除いて、同じ手順に従う必要があります。
認証構成のサンプル
顧客は、選択した認証ポリシーを構成し、それを認証仮想サーバーにバインドできます。 認証仮想サーバーには認証プロファイル バインディングは必要ありません。 認証ポリシーのみを設定できます。 以下に使用例をいくつか示します。
重要:
認証構成はプライマリ ノードでのみ実行する必要があります。
条件付き認証による多要素認証
- デュアル ファクタ スキーマを使用した LDAP と RADIUS によるデュアル ファクタ認証 (ユーザー入力は 1 回のみ)
- 組織内のユーザーの部門(従業員、パートナー、ベンダー)に応じた認証ログオン方法(部門を選択するためのドロップダウンメニュー付き)
- ドロップダウンメニューによるユーザードメインに応じた認証ログオン方法
- 電子メール ID (またはユーザー名) 入力を最初の要素として設定し、電子メール ID を最初の要素としてグループ抽出に基づく条件付きアクセスを設定し、グループごとに異なるログオン タイプを提供します。
- ユーザー証明書を持つユーザーの場合は証明書認証を使用し、証明書を持たないユーザーの場合はネイティブ OTP 登録を使用する多要素認証
- ユーザーのホスト名入力に応じて条件付き認証を行う異なる認証タイプ
- ネイティブ OTP 認証による二要素認証
- Google 再 CAPTCHA
多要素認証によるサードパーティ統合
- Azure AD を SAML IdP として構成します (次の要素を LDAP ポリシーとして構成 - OAuth 信頼を完了するには NO_AUTH を使用します)
- 最初の要素として SAML を使用した条件付き認証、その後 SAML 属性に基づいて証明書または LDAP にカスタム ログインする
- 最初の要素はWeb認証ログイン、次にLDAP
デバイス姿勢スキャン (EPA)
- デバイス ポスチャ チェックによるバージョン チェックの後、準拠ユーザー (RADIUS) と非準拠ユーザー (LDAP) のカスタマイズされたログインを実行します。
- LDAP認証に続いて必須のデバイスポスチャスキャン
- AD認証前後のデバイスポスチャチェック - EPA前後を要因として
- EPA 要素としてのデバイス証明書