Gateway認証の nFactor
はじめに
nFactor 認証は、認証に関するまったく新しい可能性セットを可能にします。nFactor を使用する管理者は、仮想サーバーの認証要素を構成するときに、認証、承認、および監査の柔軟性を享受できます。
2 つのポリシーバンクまたは 2 つの要因によって、管理者が制限されなくなりました。政策銀行の数は、さまざまなニーズに合わせて拡張することができます。前述の要因に基づいて、nFactor は認証方法を決定します。動的ログインフォームと失敗時のアクションは、nFactor を使用して可能です。
注: nFactorは、Citrix ADCスタンダードエディションではサポートされていません。これは、Citrix ADCアドバンストエディションとCitrix ADCプレミアムエディションでサポートされています。
ユースケース
nFactor 認証は、ユーザプロファイルに基づくダイナミック認証フローを有効にします。場合によっては、これらはユーザーにとって直感的な単純なフローになることがあります。それ以外の場合は、アクティブディレクトリやその他の認証サーバーのセキュリティ保護と組み合わせることができます。 Gatewayに固有の要件をいくつか次に示します。
-
動的なユーザ名とパスワードの選択。従来、Citrix クライアント(ブラウザとReceiverを含む)では、最初のパスワードフィールドとしてアクティブディレクトリ(AD)パスワードが使用されていました。2 番目のパスワードは、ワンタイムパスワード (OTP) 用に予約されています。ただし、AD サーバーを保護するには、OTP を最初に検証する必要があります。nFactor は、クライアントの変更を必要とせずにこれを行うことができます。
-
マルチテナント認証エンドポイント。組織によっては、証明書ユーザーおよび証明書以外のユーザーに対して異なる Gateway サーバーを使用します。ユーザーが自分のデバイスを使用してログインする場合、ユーザーのアクセスレベルは、使用するデバイスに応じてCitrix ADCによって異なります。 Gatewayは、さまざまな認証ニーズに対応できます。
-
グループメンバーシップに基づく認証。一部の組織では、認証要件を決定するために AD サーバーからユーザープロパティを取得します。認証要件は、ユーザーごとに変更することができます。
-
認証のコファクタです。場合によっては、異なるユーザーセットを認証するために、異なる認証ポリシーのペアが使用されることがあります。ペアポリシーを指定すると、有効な認証が向上します。依存ポリシーは、1 つのフローから作成できます。このようにして、独立した一連のポリシーが独自のフローになり、効率性が向上し、複雑さが軽減されます。
認証応答の処理
Citrix Gateway のコールバック登録は、認証応答を処理します。AAAD(認証デーモン)応答と成功/失敗/エラー/ダイアログコードは、コールバックハンドルに送られます。成功/失敗/エラー/ダイアログコードは、Gateway が適切なアクションを実行するように指示します。
クライアントのサポート
次の表に、構成の詳細を示します。
クライアント | nFactor サポート | 認証ポリシーのバインドポイント | EPA |
---|---|---|---|
Webブラウザー | はい | 認証 | はい |
Citrix Workspaceアプリ | いいえ | VPN | × |
Gatewayプラグイン | いいえ | VPN | はい |
コマンドライン設定
Gateway 仮想サーバには、属性として指定された認証仮想サーバが必要です。これは、このモデルに必要な唯一の構成です。
add authnProfile <name-of-profile> -authnVsName <name-of-auth-vserver>
<!--NeedCopy-->
authnVsName は、認証仮想サーバーの名前です。この仮想サーバーは、高度な認証ポリシーで構成する必要があり、nFactor 認証に使用されます。
add vpn vserver <name> <serviceType> <IP> <PORT> -authnProfile <name-of-profile>
set vpn vserver <name> -authnProfile <name-of-profile>
<!--NeedCopy-->
ここで、authnProfile は以前に作成された認証プロファイルです。
相互運用に関する課題
レガシー Gatewayクライアントのほとんどは、rfWeb クライアントに加えて、Gateway から送信された応答に基づいてモデル化されています。たとえば、/vpn/index.html に対する 302 応答は、多くのクライアントで期待されます。また、これらのクライアントは、「pwcount」、「NSC_CERT」などのさまざまな Gatewayクッキーに依存しています。
エンドポイント分析(EPA)
認証、認可、および監査サブシステムは nFactor の EPA をサポートしていないため、Gateway 仮想サーバが EPA を実行します。EPA の後、ログイン資格情報は、前述の API を使用して認証仮想サーバーに送信されます。認証が完了すると、Gateway は認証後のプロセスを続行し、ユーザセッションを確立します。
設定ミスに関する考慮事項
Gateway クライアントは、ユーザーの資格情報を一度だけ送信します。Gateway は、ログイン要求とともにクライアントから 1 つまたは 2 つのクレデンシャルを取得します。レガシーモードでは、最大 2 つの要素があります。取得したパスワードは、これらの要因に使用されます。ただし、nFactor では、構成できるファクタの数は実質的に無制限です。Gateway クライアントから取得したパスワードは、設定された要素に対して(設定に従って)再利用されます。ワンタイムパスワード (OTP) を複数回再利用しないように注意する必要があります。同様に、管理者は、ある要素で再利用されたパスワードが実際にその要素に適用可能であることを確認する必要があります。
Citrix クライアントの定義
この構成オプションは、Citrix ADCがブラウザクライアントとReceiverなどのシッククライアントを判断する際に役立ちます。
管理者は、パターンセットns_vpn_client_userAgentsが提供され、すべてのCitrix クライアントのパターンを構成できます。
同様に、「Citrix Receiver」文字列を上記のパッチセットにバインドして、ユーザーエージェントに「Citrix Receiver」を持つすべてのCitrixクライアントを無視します。
Gatewayの nFactor の制限
次の条件が存在する場合、 Gateway認証の nFactor は発生しません。
-
認証プロファイルは、Citrix Gateway で設定されていません。
-
高度な認証ポリシーは、認証仮想サーバーにバインドされず、同じ認証仮想サーバーがauthnProfileに記載されています。
-
HTTPリクエスト内のユーザーエージェント文字列は、パッチセットns_vpn_client_useragentsで構成されたユーザーエージェントと一致します。
これらの条件が満たされない場合、Gateway にバインドされた従来の認証ポリシーが使用されます。
ユーザーエージェントまたはその一部が前述のパッチセットにバインドされている場合、それらのユーザーエージェントからのリクエストは nFactor フローに参加しません。たとえば、以下のコマンドは、すべてのブラウザの設定を制限します(すべてのブラウザがユーザーエージェント文字列に「Mozilla」が含まれていると仮定します)。
bind patset ns_vpn_client_useragents Mozilla
LoginSchema
LoginSchema は、ログオンフォームを論理的に表現したものです。XML 言語によって定義されています。loginSchemaの構文は、Citrixの共通フォームプロトコル仕様に準拠しています。
LoginSchema は、製品の「ビュー」を定義します。管理者は、フォームのカスタマイズした説明、補助テキストなどを提供できます。これには、フォーム自体のラベルが含まれます。お客様は、特定の時点で提示されたフォームを説明する成功/失敗メッセージを提供できます。
ログインスキーマとnFactorの知識が必要です
事前に構築されたログインスキーマファイルは、以下のCitrix ADCの場所/nsconfig/nsconfig/loginschema/LoginSchema/にあります。これらの事前構築された loginSchema ファイルは、一般的なユースケースに対応し、必要に応じて若干のバリエーションに合わせて変更できます。
また、カスタマイズが少ないほとんどの単一要素ユースケースでは、loginSchema (s) 設定は必要ありません。
管理者は、Citrix ADCが要因を検出できるようにする追加の構成オプションについて、ドキュメントを確認することをお勧めします。ユーザーがクレデンシャルを送信すると、管理者は複数のファクタを構成して、認証ファクタを柔軟に選択して処理できます。
LoginSchema を使用しない二要素認証の設定
Citrix ADCは、構成に基づいて二重要素要件を自動的に決定します。ユーザーがこれらの資格情報を提示すると、管理者は仮想サーバーでポリシーの最初のセットを構成できます。各ポリシーに対して、「nextFactor」を「パススルー」として構成できます。「パススルー」とは、Citrix ADCが既存の資格情報を使用してログオンを処理する必要があることを意味します。「パススルー」要素を使用することで、管理者はプログラムで認証フローを駆動できます。詳細については、nFactor 仕様または導入ガイドを参照することをお勧めします。「 多要素 (nFactor) 認証」を参照してください。
ユーザー名のパスワードの式
ログイン資格情報を処理するには、管理者は loginSchema を設定する必要があります。loginSchema のカスタマイズが少ない単一ファクタまたは二重ファクタの使用例では、指定された XML 定義は必要ありません。LoginSchemaには、ユーザーが提示するユーザー名/パスワードを変更するために使用することができ、このようなuserExpressionとpasswdExpressionなどの他のプロパティがあります。これらは高度なポリシー式であり、ユーザー入力を上書きするために使用することもできます。
nFactor 構成における高レベルの手順
次の図は、nFactor 構成に関連する高レベルの手順を示しています。
GUI の設定
ここでは、次のトピックについて説明します。
-
仮想サーバーの作成
-
認証仮想サーバーの作成
-
認証 CERT プロファイルの作成
-
認証ポリシーの作成
-
LDAP 認証サーバーの追加
-
LDAP 認証ポリシーの追加
-
Radius 認証サーバーを追加する
-
Radius 認証ポリシーの追加
-
認証ログインスキーマの作成
-
ポリシーラベルの作成
仮想サーバーの作成
-
Citrix Gateway->仮想サーバーに移動します。
-
[ 追加 ] ボタンをクリックして、負荷分散仮想サーバーを作成します。
-
次の情報を入力します。
パラメーター名 パラメータの説明 仮想サーバの名前を入力します。 Citrix Gateway仮想サーバーの名前。ASCII アルファベットまたはアンダースコア (_) 文字で始まり、ASCII 英数字、アンダースコア、ハッシュ (#)、ピリオド (.)、スペース、コロン (:)、アットマーク (@)、等しい (=)、およびハイフン (-) 文字のみを含める必要があります。仮想サーバの作成後に変更できます。次の要件は、Citrix ADC CLIにのみ適用されます。名前に1つ以上のスペースが含まれる場合は、名前を二重引用符または一重引用符で囲みます(「my server」や「my server」など)。 仮想サーバの IP アドレスタイプを入力します。 ドロップダウンメニューから [IP アドレス] または [アドレス指定不可] オプションを選択します。 仮想サーバの IP アドレスを入力します。 インターネットプロトコルアドレス (IP アドレス) は、通信にインターネットプロトコルを使用するコンピュータネットワークに参加している各デバイスに割り当てられる数値ラベルです。 仮想サーバのポート番号を入力します。 ポート番号を入力します。 認証プロファイルを入力します。 仮想サーバー上の認証プロファイルエンティティ。このエンティティを使用して、多要素(nFactor)認証のための認証、承認、および監査仮想サーバーに認証をオフロードできます。 RDP サーバープロファイルを入力します。 仮想サーバーに関連付けられている RDP サーバープロファイルの名前。 「最大ユーザー数」を入力します。 この仮想サーバで許可される同時ユーザー・セッションの最大数。この仮想サーバーにログオンできる実際のユーザー数は、ユーザーライセンスの合計数によって異なります。 最大ログイン試行回数を入力します。 ログオンの最大試行回数。 ログイン失敗タイムアウトを入力します。 ユーザーが最大許容試行回数を超えた場合に、アカウントがロックされる時間(分)。 Windows EPA プラグインのアップグレードを入力します。 Win のプラグインのアップグレード動作を設定するオプション。 Linux EPA プラグインのアップグレードに入ります。 Linux のプラグインのアップグレード動作を設定するオプション。 MAC EPA プラグインのアップグレードに入る Mac のプラグインのアップグレード動作を設定するオプション。 1 回ログイン このオプションは、この仮想サーバーのシームレスなSSOを有効/無効にします。 ICAのみ ONに設定すると、ユーザーがCitrix Workspace アプリまたはブラウザーを使用してログオンし、Wihomeパラメーターで指定されたCitrix Virtual Apps and Desktops環境で構成された公開アプリにアクセスできる、基本モードを意味します。ユーザーはCitrix Gateway プラグインを使用して接続できず、エンドポイントスキャンを構成できません。ログインしてアプリにアクセスできるユーザーの数は、このモードでのライセンスによって制限されません。-OFFに設定すると、ユーザーがCitrix Workspaceアプリ、ブラウザー、またはCitrix Gateway プラグインを使用してログオンできるSmartAccessモードを意味します。管理者は、エンドポイントスキャンをクライアントシステムで実行するように設定し、その結果を使用して公開アプリケーションへのアクセスを制御できます。このモードでは、クライアントは他のクライアントモード(VPN および CVPN)でGateway に接続できます。ログインしてリソースにアクセスできるユーザの数は、このモードの CCU ライセンスによって制限されます。 認証の有効化 Citrix Gateway に接続するユーザーの認証を要求します。 ダブルホップ Citrix Gateway アプライアンスをダブルホップ構成で使用します。ダブルホップ展開では、3 つのファイアウォールを使用して DMZ を 2 つのステージに分割することにより、内部ネットワークのセキュリティをさらに強化できます。このような展開では、DMZ に 1 つのアプライアンス、セキュアネットワークに 1 つのアプライアンスを持つことができます。 ダウン状態フラッシュ 仮想サーバーが [DOWN] とマークされている場合は、既存の接続を閉じます。これは、サーバーがタイムアウトした可能性があることを意味します。既存の接続を切断すると、リソースが解放され、場合によっては負荷分散セットアップの回復が高速化されます。[DOWN] とマークされている場合、接続を安全に閉じることができるサーバーでは、この設定を有効にします。トランザクションを完了する必要があるサーバーでは、DOWN 状態フラッシュを有効にしないでください。 DTLS このオプションは、仮想サーバー上のターンサービスを開始/停止します。 AppFlow ログ 標準の NetFlow または IPFIX 情報(フローの開始と終了のタイムスタンプ、パケットカウント、バイトカウントなど)を含む AppFlow レコードをログに記録します。また、HTTP Web アドレス、HTTP 要求メソッドと応答ステータスコード、サーバーの応答時間、待機時間など、アプリケーションレベルの情報を含むレコードもログに記録します。 ICAプロキシセッションの移行 このオプションは、ユーザーが別のデバイスからログオンしたときに、既存のICAプロキシセッションを転送するかどうかを決定します。 状態 仮想サーバーの現在の状態 (UP、DOWN、BUSY など)。 デバイス証明書の有効化 EPA の一部としてデバイス証明書チェックがオンかオフかを示します。 -
ページの「 サーバー証明書なし 」セクションを選択します。
-
[>] をクリックして、サーバー証明書を選択します。
-
SSL 証明書を選択し、[ 選択 ] ボタンをクリックします。
-
[バインド] をクリックします。
-
「 使用可能な暗号がありません」という警告が表示された場合は、[ OK] をクリックします。
-
[ 続行 ] ボタンをクリックします。
-
[認証] セクションで、右上の [ + ] アイコンをクリックします。
認証仮想サーバーの作成
-
[ セキュリティ]-> [Citrix ADC AAA]-[アプリケーショントラフィック]-[仮想サーバー] に移動します。
-
[追加] をクリックします。
-
認証仮想サーバーを作成するには、次の基本設定を行います。
注意: 必須フィールドは、設定名の右側に*で示されます。
a) 新しい認証仮想サーバ の名前 を入力します。
b) IPアドレスのタイプを入力します。[IP アドレスの種類] は、[アドレス指定不可] として構成できます。
c) IPアドレスを入力します。IP アドレスはゼロにできます。
d) 認証仮想サーバの プロトコルの種類を入力します。
e) 仮想サーバが接続を受け入れる TCPポートを入力します。
f) 認証仮想サーバによって設定された認証クッキーの ドメイン を入力します。
-
[OK] をクリックします。
-
[ サーバー証明書なし] をクリックします。
-
リストから目的のサーバー証明書を選択します。
-
目的の SSL 証明書を選択し、[ Select ] ボタンをクリックします。
注:認証仮想サーバーには、バインドされた証明書は必要ありません。
-
サーバー証明書のバインドを設定します。
-
SNI 処理に使用される証明書キーをバインドするには、[SNI のサーバ証明書 ] チェックボックスをオンにします。
-
[ バインド ] ボタンをクリックします。
-
認証 CERT プロファイルの作成
-
セキュリティ->Citrix ADC AAA-アプリケーショントラフィック->ポリシー->認証->基本ポリシー->CERTに移動します。
-
[プロファイル] タブを選択し、[ 追加] を選択します。
-
次のフィールドに入力して、認証 CERT プロファイルを作成します。必須フィールドは、設定名の右側に*で示されます。
-
Name :クライアント証明書認証サーバ・プロファイルの名前(アクション)。
-
2 要素 — この例では、2 要素認証オプションは NOOP です。
-
「ユーザー名フィールド」— ユーザー 名を抽出するクライアント証明書フィールドを入力します。「件名」または「発行者」のいずれかに設定する必要があります (両方の二重引用符を含む)。
-
グループ名フィールド -グループを抽出するクライアント証明書フィールドを入力します。「件名」または「発行者」のいずれかに設定する必要があります (両方の二重引用符を含む)。
-
デフォルトの認証グループ -抽出されたグループに加えて認証が成功したときに選択されるデフォルトのグループです。
-
-
[作成] をクリックします。
認証ポリシーの作成
-
セキュリティ->Citrix ADC AAA-アプリケーショントラフィック->ポリシー->認証->高度なポリシー->ポリシーに移動します。
-
[ 追加 ] ボタンを選択します。
-
認証ポリシーを作成するには、次の情報を入力します。必須フィールドは、設定名の右側に*で示されます。
a) 「 名前」— アドバンス認証ポリシーの名前を入力します。文字、数字、またはアンダースコア文字 (_) で始まり、文字、数字、ハイフン (-)、ピリオド (.)、ポンド (#)、スペース ()、アットマーク (@)、等しい (=)、コロン (:)、およびアンダースコア文字のみを含める必要があります。認証ポリシーの作成後は変更できません。
次の要件は、Citrix ADC CLIにのみ適用されます。名前に1つ以上のスペースが含まれる場合は、名前を二重引用符または一重引用符で囲みます(「認証ポリシー」や「認証ポリシー」など)。
b) アクションタイプ -認証アクションのタイプを入力します。
c) Action -ポリシーが一致した場合に実行する認証アクションの名前を入力します。
d) [Log Action ]-要求がこのポリシーに一致するときに使用するメッセージログアクションの名前を入力します。
e)「 式 」-Citrix ADCの名前付き規則の名前またはデフォルトの構文式を入力します。この規則は、認証サーバーでユーザーを認証するかどうかをポリシーが決定します。
f)「 コメント 」— このポリシーに関する情報を保持するコメントを入力します。
-
[作成] をクリックします。
LDAP 認証サーバの追加
-
[ セキュリティ]-> [Citrix ADC AAA]-[アプリケーショントラフィック]-> [ポリシー]-> [認証]-> [基本ポリシー]-> [LDAP] に移動します。
-
LDAP サーバを追加するには、[ サーバ ] タブを選択し、[ 追加 ] ボタンを選択します。
LDAP 認証ポリシーの追加
-
セキュリティ->Citrix ADC AAA-アプリケーショントラフィック->ポリシー->認証->高度なポリシー->ポリシーに移動します。
-
[ 追加 ] をクリックして、認証ポリシーを追加します。
-
認証ポリシーを作成するには、次の情報を入力します。必須フィールドは、設定名の右側に*で示されます。
a) 名前 -事前認証ポリシーの名前。 文字、数字、またはアンダースコア文字 (_) で始まり、文字、数字、ハイフン (-)、ピリオド (.)、ポンド (#)、スペース ()、アットマーク (@)、等しい (=)、コロン (:)、およびアンダースコア文字のみを含める必要があります。認証ポリシーの作成後は変更できません。
次の要件は、Citrix ADC CLIにのみ適用されます。名前に1つ以上のスペースが含まれる場合は、名前を二重引用符または一重引用符で囲みます(「認証ポリシー」や「認証ポリシー」など)。
b) アクションタイプ -認証アクションのタイプ。
c) Action -ポリシーが一致した場合に実行される認証アクションの名前。
d) Log Action -要求がこのポリシーに一致するときに使用するメッセージ・ログ・アクションの名前。
e) Expression -Citrix ADCの名前付きルールの名前、またはデフォルトの構文式。認証サーバーを使用してユーザーを認証するかどうかをポリシーが判断します。
f) コメント -このポリシーに関する情報を保持するためのコメント。
-
[作成] をクリックします。
RADIUS 認証サーバの追加
-
[ セキュリティ]-> [Citrix ADC AAA]-> [アプリケーショントラフィック]-> [ポリシー]-> [認証]-> [基本ポリシー]-> [RADIUS]に移動します。
-
サーバを追加するには、[ サーバ ] タブを選択し、[ 追加 ] ボタンを選択します。
-
認証 RADIUS サーバを作成するには、次のように入力します。必須フィールドは、設定名の右側に*で示されます。
a) RADIUS アクション の名前 を入力します。
b) RADIUS サーバに割り当てられているサーバ名またはサーバの IP アドレスを入力します。
c) RADIUSサーバが接続をリッスンする ポート番号 を入力します。
d) タイムアウト 値を数秒で入力します。これは、Citrix ADCアプライアンスがRADIUSサーバーからの応答を待機する値です。
e) RADIUSサーバーとCitrix ADCアプライアンスの間で共有される 秘密キーを 入力します。秘密キーは、Citrix ADCアプライアンスがRADIUSサーバーと通信できるようにするために必要です。
f) シークレットキーを確認します。
-
[作成] をクリックします。
RADIUS 認証ポリシーの追加
-
セキュリティ->Citrix ADC AAA-アプリケーショントラフィック->ポリシー->認証->高度なポリシー->ポリシーに移動します。
-
[ 追加 ] をクリックして、認証ポリシーを作成します。
-
認証ポリシーを作成するには、次の情報を入力します。必須フィールドは、設定名の右側に*で示されます。
a) 名前 -事前認証ポリシーの名前。 文字、数字、またはアンダースコア文字 (_) で始まり、文字、数字、ハイフン (-)、ピリオド (.)、ポンド (#)、スペース ()、アットマーク (@)、等しい (=)、コロン (:)、およびアンダースコア文字のみを含める必要があります。認証ポリシーの作成後は変更できません。
次の要件は、Citrix ADC CLIにのみ適用されます。名前に1つ以上のスペースが含まれる場合は、名前を二重引用符または一重引用符で囲みます(「認証ポリシー」や「認証ポリシー」など)。
b) アクションタイプ -認証アクションのタイプ。
c) Action -ポリシーが一致した場合に実行される認証アクションの名前。
d) Log Action -要求がこのポリシーに一致するときに使用するメッセージ・ログ・アクションの名前。
e) Expression -Citrix ADCの名前付きルールの名前、またはデフォルトの構文式。認証サーバーを使用してユーザーを認証するかどうかをポリシーが判断します。
f) コメント -このポリシーに関する情報を保持するためのコメント。
-
[OK]をクリックします。
-
認証ポリシーが表示されていることを確認します。
認証ログインスキーマの作成
-
[ セキュリティ]-> [Citrix ADC AAA]-[アプリケーショントラフィック]-[ログインスキーマ] に移動します。
-
[プロファイル] タブを選択し、[ 追加 ] ボタンをクリックします。
-
認証ログイン・スキーマを作成するには、次のフィールドに入力します。
a)「 名前」 を入力します。これは新しいログインスキーマの名前です。
b) 認証スキーマ を入力します。これは、ログインページのUIに送信される認証スキーマを読み取るためのファイルの名前です。このファイルには、ログインフォームをレンダリングできるようにするためのCitrix フォーム認証プロトコルごとの要素のxml定義が含まれている必要があります。管理者がユーザーに追加の資格情報を要求せず、以前に取得した資格情報を続行する場合は、引数として「noschema」を指定できます。これは、ユーザー定義のファクタで使用される loginSchemas にのみ適用され、仮想サーバのファクタには適用されません。
c) ユーザー式 を入力します。これは、ログイン中にユーザー名を抽出するための式です。
d) パスワード式 を入力する-これはログイン時のパスワード抽出の式です
e) ユーザー・クレデンシャル・インデックスを 入力します。これは、ユーザーが入力したユーザー名が、セッションに格納されるインデックスです。
f) パスワードクレデンシャルインデックスを 入力します。これは、ユーザーが入力したパスワードがセッションに格納されるインデックスです。
g) 認証強度 を入力します。これは現在の認証の重みです。
-
[作成] をクリックします。
- ログインスキーマプロファイルが表示されていることを確認します。
ポリシーラベルの作成
ポリシー・ラベルは、特定の要素の認証ポリシーを指定します。各ポリシーラベルは、1 つの要素に対応します。ポリシーラベルは、ユーザーに提示する必要があるログインフォームを指定します。ポリシー・ラベルは、認証ポリシーまたは別の認証ポリシー・ラベルの次の要素としてバインドする必要があります。通常、ポリシーラベルには、特定の認証メカニズムの認証ポリシーが含まれます。ただし、異なる認証メカニズムの認証ポリシーを持つポリシーラベルを使用することもできます。
-
セキュリティ->Citrix ADC AAA-アプリケーショントラフィック->ポリシー->認証->高度なポリシー->ポリシーラベルに移動します。
-
[追加] をクリックします。
-
認証ポリシー・ラベルを作成するには、次のフィールドに入力します。
a) 新しい認証ポリシーラベルの [Name] を入力します。
b) 認証ポリシーラベルに関連付けられた ログインスキーマ を入力します。
c) [ 続行] をクリックします。
-
ドロップダウンメニューから[Policy ] を選択します。
-
目的の 認証ポリシー を選択し、[ Select ] ボタンをクリックします。
-
次のフィールドに入力します。
a) ポリシーバインディングの [ Priority ] を入力します。
b)「 Goto Expression」 を入力します。この式は、現在のポリシー・ルールがTRUEと評価された場合に評価される次のポリシーの優先順位を指定します。
-
目的の認証ポリシーを選択し、[ Select ] ボタンをクリックします。
-
[ バインド ] ボタンをクリックします。
-
[完了] をクリックします。
-
認証ポリシー・ラベルを確認します。
nFactor 認証用の再キャプチャ設定
Citrix ADCリリース12.1ビルド50.x以降では、Citrix Gateway は、キャプチャの構成を簡素化する新しいファーストクラスのアクション「captchaAction」をサポートしています。キャプチャは、ファーストクラスのアクションであるように、それは、独自の要因であることができます。nFactorフローのどこにでもキャプチャを挿入できます。
以前は、RfWeb UI の変更を含むカスタム WebAuth ポリシーを記述する必要がありました。キャプチャーアクションが導入されたことで、JavaScriptを変更する必要はありません。
重要
Captchaがスキーマ内のユーザー名またはパスワードのフィールドと一緒に使用されている場合、Captchaが満たされるまで、送信ボタンは無効になります。
キャプチャの構成
キャプチャの構成には、2つの部分が含まれます。
- キャプチャを登録するためのGoogleの構成。
- ログインフローの一部としてキャプチャを使用するCitrix ADCアプライアンスの構成。
グーグルでキャプチャの設定
https://www.google.com/recaptcha/admin#list
でキャプチャのドメインを登録します。
-
このページに移動すると、次の画面が表示されます。
注
reCAPTCHA v2 のみを使用してください。目に見えないreCAPTCHAはまだ技術プレビュー中です。
-
ドメインを登録すると、「サイトキー」と「秘密キー」が表示されます。
注
セキュリティ上の理由から、「SiteKey」と「SecretKey」はグレー表示になっています。「SecretKey」は安全に保管する必要があります。
Citrix ADCアプライアンスでのキャプチャ構成
Citrix ADCアプライアンスのキャプチャ構成は、次の3つの部分に分けることができます。
- キャプチャ画面を表示する
- Googleサーバーにキャプチャ応答を投稿する
- LDAP 構成は、ユーザーログオンの 2 番目の要素です (オプション)
キャプチャ画面を表示する
ログインフォームのカスタマイズは、SingleAuthCaptcha.xml ログインスキーマを介して行われます。このカスタマイズは、認証仮想サーバーで指定され、ログインフォームをレンダリングするために UI に送信されます。組み込みのログインスキーマであるSingleAuthCaptcha.xmlは、Citrix ADCアプライアンス上の/nsconfig/loginSchema/ログインスキーマディレクトリにあります。
重要
- ユースケースと異なるスキーマに基づいて、既存のスキーマを変更できます。たとえば、Captcha係数(ユーザー名やパスワードなし)またはCaptchaとの二重認証だけが必要な場合。
- カスタム変更を実行した場合、またはファイルの名前を変更した場合は、すべてのloginSchemaを/nsconfig/loginschemaディレクトリから親ディレクトリ/nsconfig/loginschemaにコピーすることをお勧めします。
CLI を使用してキャプチャの表示を設定するには
add authentication loginSchema singleauthcaptcha -authenticationSchema /nsconfig/loginschema/SingleAuthCaptcha.xml
add authentication loginSchemaPolicy singleauthcaptcha -rule true -action singleauthcaptcha
add authentication vserver auth SSL <IP> <Port>
add ssl certkey vserver-cert -cert <path-to-cert-file> -key <path-to-key-file>
bind ssl vserver auth -certkey vserver-cert
bind authentication vserver auth -policy singleauthcaptcha -priority 5 -gotoPriorityExpression END
Googleサーバーにキャプチャ応答を投稿する
あなたは、ユーザーに表示されなければならないキャプチャを設定した後、管理者は、ブラウザからのキャプチャ応答を確認するために、Googleサーバーに構成を追加ポスト。
ブラウザからキャプチャ応答を確認するには
add authentication captchaAction myrecaptcha -sitekey <sitekey-copied-from-google> -secretkey <secretkey-from-google>
add authentication policy myrecaptcha -rule true -action myrecaptcha
bind authentication vserver auth -policy myrecaptcha -priority 1
AD 認証が必要な場合は、次のコマンドが必要です。それ以外の場合は、この手順を無視できます。
add authentication ldapAction ldap-new -serverIP x.x.x.x -serverPort 636 -ldapBase "cn=users,dc=aaatm,dc=com" -ldapBindDn adminuser@aaatm.com -ldapBindDnPassword <password> -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberof -subAttributeName CN -secType SSL -passwdChange ENABLED -defaultAuthenticationGroup ldapGroup
add authenticationpolicy ldap-new -rule true -action ldap-new
LDAP 構成は、ユーザーログオンの 2 番目の要素です (オプション)
LDAP認証はキャプチャ後に行われ、2番目の要素に追加します。
add authentication policylabel second-factor
bind authentication policylabel second-factor -policy ldap-new -priority 10
bind authentication vserver auth -policy myrecaptcha -priority 1 -nextFactor second-factor
管理者は、負荷分散仮想サーバーとCitrix Gateway アプライアンスのどちらを使用してアクセスするかに応じて、適切な仮想サーバーを追加する必要があります。ロードバランシング仮想サーバが必要な場合は、管理者が次のコマンドを設定する必要があります。
add lb vserver lbtest HTTP <IP> <Port> -authentication ON -authenticationHost nssp.aaatm.com`
<!--NeedCopy-->
nssp.aaatm.com — 認証仮想サーバーに解決します。
キャプチャのユーザー検証
前のセクションで説明したすべての手順を設定したら、以下に示すUIのスクリーンショットを確認する必要があります。
-
認証仮想サーバーがログインページを読み込むと、ログオン画面が表示されます。ログオン は、キャプチャが完了するまで無効になります。
-
[私はロボットではありません] オプションを選択します。キャプチャウィジェットが表示されます。
- 完了ページが表示される前に、一連のキャプチャ画像をナビゲートします。
-
AD 資格情報を入力し、[ ロボットではありません] チェックボックスをオンにして、 [ ログオン ] をクリックします。認証が成功すると、目的のリソースにリダイレクトされます。
注
- キャプチャがAD認証で使用されている場合、キャプチャが完了するまで、資格情報の送信ボタンは無効になります。
- キャプチャは、独自の要因で発生します。したがって、ADのような後続の検証はCaptchaの ‘nextfactor’で発生する必要があります。
この記事の概要
- はじめに
- ユースケース
- 認証応答の処理
- クライアントのサポート
- コマンドライン設定
- 相互運用に関する課題
- エンドポイント分析(EPA)
- 設定ミスに関する考慮事項
- Citrix クライアントの定義
- Gatewayの nFactor の制限
- LoginSchema
- ログインスキーマとnFactorの知識が必要です
- LoginSchema を使用しない二要素認証の設定
- ユーザー名のパスワードの式
- nFactor 構成における高レベルの手順
- GUI の設定
- 仮想サーバーの作成
- 認証仮想サーバーの作成
- 認証 CERT プロファイルの作成
- 認証ポリシーの作成
- LDAP 認証サーバの追加
- LDAP 認証ポリシーの追加
- RADIUS 認証サーバの追加
- RADIUS 認証ポリシーの追加
- 認証ログインスキーマの作成
- ポリシーラベルの作成
- nFactor 認証用の再キャプチャ設定