関連するアダプティブ認証設定
FQDN を編集する
Workspace 構成で認証方法としてアダプティブ認証が選択されている場合は 、FQDN を編集できません。FQDN を編集するには、別の認証方法に切り替える必要があります。ただし、必要に応じて証明書を編集できます。
重要:
- FQDN を変更する前に、新しい FQDN が IdP 仮想サーバーのパブリック IP アドレスにマッピングされていることを確認します。
- OAuthポリシーを使用してCitrix Gateway に接続している既存のユーザーは、 認証方法をアダプティブ認証に移行する必要があります。詳細については、「 認証方法をアダプティブ認証に移行する」を参照してください。
FQDN を編集するには、次の手順を実行します。
-
アダプティブ認証から別の認証方法に切り替えます。
-
[サブスクライバーエクスペリエンスへの影響を理解している]を選択し、[確認]をクリックします。
[確認]をクリックすると、エンドユーザーへのワークスペースログインが影響を受け、アダプティブ認証が再度有効になるまで、アダプティブ認証は認証に使用されません。そのため、メンテナンス時間中に FQDN を変更することをお勧めします。
-
[証明書のアップロード] 画面で、FQDN を変更します。
-
[変更の保存] をクリックします。
重要:
FQDN を編集する場合は、証明書も再度アップロードする必要があります。
-
アダプティブ認証のホームページで[有効にする](手順 3) をクリックして、アダプティブ認証方法を再度有効にします。
-
[ 更新] をクリックします。
カスタムワークスペース URL またはバニティ URL
カスタムワークスペースURLを使用すると、選択したドメインを使用してCitrix Workspaceストアにアクセスできるようになります。 ユーザーはデフォルトのワークスペースURLまたはカスタムワークスペースURL、あるいはその両方を使用してWorkspaceにアクセスできます。
カスタムワークスペースURLまたはバニティURLを設定するには、以下を実行する必要があります。
- カスタムドメインを設定します。詳細については、「 カスタムドメインの設定」を参照してください
-
クライアントID、シークレット、およびオーディエンスが現在またはデフォルトのプロファイル (AAuthAutoConfig_oauthIdpProf) と同じで、リダイレクト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ポリシーとプロファイルは、プロビジョニングフェーズ中にアダプティブ認証サービスによって作成されます。その結果、Citrix Cloud管理者は暗号化されていないクライアントシークレットにアクセスできません。暗号化されたシークレットは、ns.confファイルから取得できます。OAuthプロファイルを作成するには、暗号化されたシークレットを使用し、CLIコマンドのみを使用してプロファイルを作成する必要があります。
- NetScalerユーザーインターフェイスを使用してOAuthプロファイルを作成することはできません。
Adaptive Authentication インスタンスのアップグレードをスケジュールする
現在のサイトまたは配置では、アップグレードのメンテナンスウィンドウを選択できます。
重要:
アダプティブ認証インスタンスをランダムな RTM ビルドにアップグレードしないでください。すべてのアップグレードはCitrix Cloud によって管理されます。
-
アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
- アップグレードのスケジュールをクリックします。
- アップグレードの日時を選択します。
アダプティブ認証インスタンスのプロビジョニングを解除する
お客様は、以下の場合、およびCitrix サポートからの提案に従って、アダプティブ認証インスタンスのプロビジョニングを解除できます。
- Adaptive Authenticationインスタンスにはアクセスできません (特にスケジュールされたアップグレード後)。ただし、このシナリオは発生しない可能性があります。
- 顧客が VNet ピアリングモードからコネクタモードに、またはその逆に切り替える必要がある場合。
- 顧客が VNet ピアリングモードのプロビジョニング時に間違ったサブネットを選択した場合 (サブネットがデータセンターまたは Azure VNet 内の他のサブネットと競合する)。
注:
プロビジョニングを解除すると、インスタンスの設定バックアップも削除されます。そのため、Adaptive Authentication インスタンスをプロビジョニング解除する前に、バックアップファイルをダウンロードして保存する必要があります。
アダプティブ認証インスタンスのプロビジョニングを解除するには、以下を実行します。
-
アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
-
プロビジョニング解除をクリックします。
注:
プロビジョニングを解除する前に、 Citrix Gateway をワークスペース構成から切断する必要があります。
-
アダプティブ認証インスタンスのプロビジョニングを解除する顧客 ID を入力します。
ゲートウェイへの安全なアクセスを可能にする
- アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
-
「 安全な管理アクセス」をクリックします。
- [ キーの有効期限] で、新しい SSH キーの有効期限を選択します。
-
[ キーを生成してダウンロード] をクリックします。 ページを閉じると表示されないため、後で使用するために SSH 秘密鍵をコピーまたはダウンロードします。このキーは、ユーザー名
authadmin
でアダプティブ認証インスタンスにログインするために使用できます。以前のキーペアが期限切れになった場合は、[ Generate and Download keys ] をクリックして新しいキーペアを作成できます。ただし、アクティブにできるキーペアは 1 つだけです。
- [完了] をクリックします。
重要:
Windows で PuTTY を使用してアダプティブ認証インスタンスに接続している場合は、ダウンロードした秘密キーを PEM に変換する必要があります。詳しくは、https://www.puttygen.com/convert-pem-to-ppkを参照してください。
- 以下のコマンドを使用して、Windows (バージョン 10) の MAC または PowerShell/Command プロンプトからターミナル経由でアダプティブ認証インスタンスに接続することをお勧めします。
ssh -i <path-to-private-key> authadmin@<ip address of ADC>
- ADユーザーがアダプティブ認証GUIにアクセスできるようにするには、新しい管理者としてLDAPグループに追加する必要があります。詳しくは、https://support.citrix.com/article/CTX123782を参照してください。 その他のすべての構成では、CLIコマンドではなくアダプティブ認証GUIを使用することをお勧めします。
Azure VNet ピアリングを使用してオンプレミス認証サーバーへの接続をセットアップする
この構成は、接続タイプを Azure VNet ピアリングとして選択した場合にのみ設定する必要があります。
注:
Okta、Azure AD、Ping などのサードパーティ IdP を使用している場合は、この手順は不要です。
-
アダプティブ認証の接続 UI で、[ プロビジョニング] をクリックし、[ Azure VNet ピアリング] をクリックします。
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 を入力し、[ 取得] をクリックします。
これにより、カスタマー管理の VNet リソース ID に、SPN のネットワーク貢献者ロールが追加された候補 VNet が入力されます。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 Managed VNetに転送するようにファイアウォールとルーティングのルールをオンプレミスで変更することがあります。
- 一度に追加できる VNet ピアは 1 つだけです。現在、複数の VNet ピアリングは許可されていません。VNet ピアリングを削除するか、必要に応じて作成できます。
構成のバックアップと復元
アプリケーション配信管理サービスは、Adaptive Authentication インスタンスのバックアップ管理を実行します。詳しくは、「 NetScaler インスタンスのバックアップと復元」を参照してください。
- 「アプリケーション配信管理」タイルで、「 管理」をクリックします。
- インフラストラクチャ > インスタンスに移動し 、バックアップにアクセスします。
注:
オンボードされたサービスが表示されない場合は、アプリケーション配信管理サービスをオンボーディングしてください。詳細については、「 はじめに」を参照してください。
LDAP と LDAPS のロードバランシング設定の例
Citrixアダプティブ認証インスタンスは、負荷分散仮想サーバーを使用してLDAP/LDAPSサポートを提供します。
注:
- LDAP/LDAPS の負荷分散を使用していない場合は、LDAP サーバー用のサービスまたはサーバーを作成しないでください。アダプティブ認証トンネルが壊れる可能性があります。
- LDAP の負荷分散を使用している場合は、サービスグループを作成し、スタンドアロンサービスではなく負荷分散サービスにバインドします。
- 認証に負荷分散仮想サーバーを使用する場合は、LDAP アクションに実際の LDAP サーバーの IP アドレスの代わりに、負荷分散仮想サーバー IP アドレスを必ず追加してください。
- デフォルトでは、TCP モニターは作成したサービスにバインドされます。アダプティブ認証NetScalerインスタンスでは、TCPモニターが使用されている場合、サービスはデフォルトでUPとマークされます。
- 監視には、カスタムモニターを使用することをお勧めします。
前提条件
負荷分散仮想サーバーのプライベート IP アドレス (RFC1918 アドレス)。このアドレスは内部設定に使用されるため、ダミー IP アドレスでもかまいません。
LDAP サーバーの負荷分散
LDAP サーバーを負荷分散するには、サービスグループを作成し、それを負荷分散仮想サーバーにバインドします。LDAP サーバーの負荷分散用のサービスを作成しないでください。
NetScaler CLIを使用してLDAPを設定します。
次の CLI コマンドを参考にして LDAP を設定できます。
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サーバーの負荷分散では、アダプティブ認証インスタンスへの内部SSL暗号化または復号化を避けるために、TCPタイプの負荷分散仮想サーバーを作成する必要があります。この場合、負荷分散仮想サーバーが TLS 暗号化/復号化を処理します。SSL タイプの負荷分散仮想サーバーは作成しないでください。
NetScaler CLIを使用してLDAPSを設定します。
次の CLI コマンドを参考にして LDAPS を設定できます。
-
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を使用してカスタムモニターを作成します。
- [ トラフィック管理] > [負荷分散] > [モニター] に移動します。
- LDAP タイプのモニターを作成します。モニタプローブ間隔を 15 秒に、応答タイムアウトを 10 秒に設定していることを確認します。
- このモニターをサービスにバインドします。
詳細については、「 カスタムモニター」を参照してください。
最大 15 の管理 IP アドレスを追加する規定
アダプティブ認証サービスでは、最大 15 個のパブリック IP サブネットと個々の IP アドレスを入力して、アダプティブ認証管理コンソールにアクセスできます。
IP アドレス/サブネットを入力する際の注意点:
- パブリック IP サブネットの CIDR が /20 から /32.B の間にあることを確認してください。
- エントリ間に重複がないことを確認してください。
例:
- 192.0.2.8 は 192.0.5.0/24 に含まれるため、192.0.2.0/24 と 192.0.2.8 は受け入れられません。
- 重複するサブネット: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 として認証方法でアダプティブ認証をすでに使用しているお客様は、 アダプティブ認証を移行してから 、アダプティブ認証インスタンスからOAuth構成を削除する必要があります。
- Citrix Gateway 以外の別の認証方法に切り替えます。
-
[Citrix Cloud]>[IDとアクセス管理]で、[Citrix Gateway]に対応する省略記号ボタンをクリックし、[ 切断]をクリックします。
-
[ 登録者エクスペリエンスへの影響を理解しました] を選択し、[ 確認] をクリックします。
[確認]をクリックすると、エンドユーザーへのワークスペースログインが影響を受け、アダプティブ認証が再度有効になるまで、アダプティブ認証は認証に使用されません。
-
アダプティブ認証インスタンス管理コンソールで、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]>[IDとアクセス管理]に移動します。 「認証」タブの「アダプティブ認証」で、省略記号メニューをクリックし、「管理」を選択します。
- [ 詳細を表示] をクリックします。
- [ 証明書のアップロード ] 画面で、次の操作を行います。
- アダプティブ認証 FQDN を追加します。
- 証明書とキーファイルを削除して、もう一度アップロードします。
重要:
アダプティブ認証に移行せずにFQDN または証明書とキーのペアを直接編集すると、ID とアクセス管理への接続が失敗し、次のエラーが表示されます。これらのエラーを修正するには、アダプティブ認証方式に移行する必要があります。
- ADC コマンドがエラーで失敗しました。ポリシーは、指定された優先度に既にバインドされています。
- ADC コマンドがエラーで失敗しました。バインドされていないポリシーはバインド解除できません。
-
[変更の保存] をクリックします。
この時点で、ID とアクセス管理では、 アダプティブ認証が [ 接続済み ] と表示され、アダプティブ認証インスタンスには OAuth プロファイルが自動構成されています。
これは GUI から検証できます。
- アダプティブ認証インスタンスにアクセスし、認証情報を使用してログインします。
- [セキュリティ]>[AAA-アプリケーショントラフィック]>[仮想サーバ]に移動します。OAuth IdP プロファイルが作成されていることを確認する必要があります。
- [ Citrix Cloud]>[IDとアクセス管理]に移動します。アダプティブ認証は「 接続済み 」ステータスです。
-
アダプティブ認証のホームページで[有効にする](手順 3) をクリックして、アダプティブ認証方法を再度有効にします。
この手順により、ワークスペース構成で認証方法がアダプティブ認証として有効になります。
- [ 有効化] をクリックした後、手順 3 のワークスペースリンクをクリックします。認証方法がアダプティブ認証に変更されていることを確認する必要があります。
注:
新規ユーザーは、OAuth 関連の設定を削除する手順を除いて、同じ手順に従う必要があります。
認証設定の例
顧客は、任意の認証ポリシーを構成し、それを認証仮想サーバーにバインドできます。認証プロファイルのバインディングは、認証仮想サーバーには必要ありません。構成できるのは認証ポリシーだけです。以下はユースケースの一部です。
重要:
認証の構成は、プライマリノードでのみ行う必要があります。
条件付き認証による多要素認証
- 二重要素スキーマを使用した LDAP および RADIUS による二重要素認証 (ユーザー入力を 1 回のみ取得)
- 組織内のユーザーの部門(従業員、パートナー、ベンダー)に応じた認証ログオン方法と、部門を選択するためのドロップダウンメニュー付き
- ドロップダウンメニューによるユーザードメインに応じた認証ログオン方法
- 電子メールID(またはユーザー名)の入力を第1の要素として構成し、第1の要素に電子メールIDを使用したグループ抽出に基づく条件付きアクセスを使用し、グループごとに異なるログオンタイプを提供する
- ユーザー証明書を持つユーザーには証明書認証を使用し、非証明書ユーザーにはネイティブ OTP 登録を使用する多要素認証
- ユーザーのホスト名の入力に応じて、条件付き認証で異なる認証タイプ
- ネイティブ OTP 認証による二要素認証
- Google Re-CAPTCHA
マルチファクタ認証によるサードパーティ統合
- Azure AD を SAML IdP として構成する (次の要素を LDAP ポリシーとして構成する-OAuth の信頼を完了するには NO_AUTH)
- 第 1 要素を SAML とする条件付き認証、および SAML 属性に基づく証明書または LDAP へのカスタムログイン
- Webauth ログインの第 1 要因、続いて LDAP
デバイスのポスチャスキャン (EPA)
- バージョンチェックのためのデバイスポスチャチェックの後に、準拠(RADIUS)および非準拠ユーザ(LDAP)のカスタマイズされたログイン
- LDAP 認証とそれに続く必須のデバイスポスチャスキャン
- AD 認証前後のデバイスポスチャチェック-EPA の前後の要因
- EPA ファクターとしてのデバイス証明書