セルフサービスパスワードリセット
セルフサービスパスワードリセットは、Web ベースのパスワード管理ソリューションです。これは、Citrix ADCアプライアンスおよびCitrix Gateway の認証、承認、監査機能の両方で使用できます。これは、パスワードを変更するための管理者の支援へのユーザーの依存を排除します。
セルフサービスパスワードリセットにより、エンドユーザーは、次のシナリオで安全にパスワードをリセットまたは作成できます。
- ユーザーがパスワードを忘れてしまいました。
- ユーザーはログオンできません。
これまでは、エンドユーザーが AD パスワードを忘れた場合、エンドユーザーは AD 管理者に連絡してパスワードをリセットする必要がありました。セルフサービスパスワードリセット機能を使用すると、エンドユーザーは管理者の介入なしにパスワードをリセットできます。
セルフサービスパスワードリセットを使用する利点の一部を次に示します。
- パスワードの自動変更メカニズムにより、ユーザーがパスワードのリセットを待機するリードタイムを排除し、生産性を向上させます。
- 自動パスワード変更メカニズムにより、管理者はその他の重要なタスクに集中できます。
次の図は、パスワードをリセットするためのセルフサービスパスワードリセットフローを示しています。
セルフサービスパスワードリセットを使用するには、ユーザーがCitrix認証、承認、監査またはCitrix Gateway仮想サーバーに登録されている必要があります。
セルフ・サービス・パスワード・リセットには、次の機能があります。
- 新規ユーザーの自己登録。新規ユーザーとして自己登録できます。
- 知識ベースの質問を設定します。管理者は、ユーザーに対して一連の質問を構成できます。
-
代替電子メール ID の登録。登録時に代替のEメールIDを入力する必要があります。ユーザーがプライマリ電子メール ID パスワードを忘れたため、OTP は代替電子メール ID に送信されます。
注:
バージョン 12.1 ビルド 51.xx 以降では、代替電子メール ID の登録はスタンドアロンとして行うことができます。新しいLoginschemaである AltEmailRegister.xml は、代替電子メール ID 登録のみを行うために導入されました。以前は、代替電子メール ID の登録は、KBA 登録中にのみ行うことができました。
- 忘れたパスワードをリセットします。ユーザーは、知識ベースの質問に答えることでパスワードをリセットできます。管理者は、質問を構成して保存できます。
セルフサービスパスワードリセットでは、次の 2 つの新しい認証メカニズムが提供されます。
-
知識ベースの質問と回答。知識ベースの質問と回答スキーマを選択する前に、Citrix認証、承認、監査、またはCitrix Gatewayに登録する必要があります。
-
電子メールの OTP 認証。OTP は、セルフサービスパスワードリセット登録時にユーザーが登録した代替電子メール ID に送信されます。
注
これらの認証メカニズムは、セルフサービスパスワードリセットのユースケース、および既存の認証メカニズムと同様の認証目的で使用できます。
前提条件
セルフサービスパスワードリセットを構成する前に、次の前提条件を確認してください。
- Citrix ADC 機能リリース 12.1、ビルド 50.28。
- サポートされるバージョンは 2016、2012、2008 の AD ドメイン機能レベルです。
- Citrix ADCにバインドされたldapBindユーザー名には、ユーザーのADパスへの書き込みアクセス権が必要です。
注
セルフサービスパスワードリセットは、nFactor 認証フローでのみサポートされます。詳しくは、「Citrix ADCを介したファクタ認証」を参照してください。
制限事項
セルフサービスパスワードリセットの制限事項を次に示します。
- セルフサービスパスワードのリセットは、認証バックエンドが LDAP の場合にのみ使用できます。
- 既に登録されている代替電子メール ID がユーザーに表示されません。
- 知識ベースの質問と回答、および電子メールの OTP 認証と登録は、認証フローの最初の要素にはなりません。
- ネイティブプラグインおよびReceiverの場合、登録はブラウザ経由でのみサポートされます。
- セルフサービスパスワードのリセットに使用される最小証明書サイズは 1024 バイトで、x.509 標準に従う必要があります。
アクティブディレクトリの設定
Citrix ADC 知識ベースの質問と回答、および電子メールOTPは、AD属性を使用してユーザーデータを格納します。質問と回答を代替電子メール ID とともに保存するように AD 属性を構成する必要があります。Citrix ADCアプライアンスは、ADユーザーオブジェクトの構成済みKB属性に格納します。AD 属性を設定する場合は、次の点を考慮してください。
- 属性の長さは 128 文字以上にする必要があります。
- AD 属性は、最大長の 32k 値をサポートする必要があります。
- 属性タイプは ‘ディレクトリ文字列’ でなければなりません。
- 1 つの AD 属性を使用して、知識ベースの質問と回答、および代替電子メール ID を使用できます。
- 単一の AD 属性を、ネイティブ OTP およびナレッジベースの質問と回答、または代替電子メール ID 登録に使用することはできません。
- Citrix ADC LDAP管理者は、選択したAD属性への書き込みアクセス権を持っている必要があります。
既存の AD 属性を使用することもできます。ただし、使用する予定の属性が他の場合に使用されていないことを確認してください。たとえば、userParameters は、使用できる AD ユーザー内の既存の属性です。この属性を確認するには、次の手順を実行します。
- [ADSI] に移動し、[ユーザを選択] を選択します。
- 右クリックして、属性リストまでスクロールします。
- [CN = テストユーザーのプロパティ] ウィンドウペインで、 userParameters 属性が設定されていないことがわかります。
セルフサービスパスワードリセット登録
Citrix ADCアプライアンスにセルフサービスパスワードリセットソリューションを実装するには、以下を実行する必要があります。
- セルフサービスパスワードリセット(知識ベースの質問と回答/EメールID)登録。
- ユーザー・ログオン・ページ(パスワードのリセット用。知識ベースの質問と回答、電子メールによるOTP検証と最終パスワードのリセット係数が含まれます)。
事前定義された質問カタログのセットは、JSONファイルとして提供されます。管理者は、Citrix ADC GUIを使用して、質問を選択し、セルフサービスパスワードリセット登録ログインスキーマを作成できます。次のいずれかのオプションを選択できます。
- 最大 4 つのシステム定義の質問を選択します。
- ユーザーが2つの質問と回答をカスタマイズするためのオプションを提供します。
CLI からデフォルトのナレッジベースの質問 JSON ファイルを表示するには
注
Citrix Gateway には、デフォルトでシステム定義の質問が含まれています。管理者は、「KBQuestions.json」ファイルを編集して、選択した質問を含めることができます。
システム定義の質問は英語でのみ表示され、これらの質問の言語ローカリゼーションサポートは利用できません。
知識ベースの質問と回答の登録を完了するには GUIを使用してログインスキーマ
-
[セキュリティ] > [AAA] — [アプリケーショントラフィック] > [ログインスキーマ] に移動します。
- [ログインスキーマ] ページで、[プロファイル] をクリックします。
- 「 KBA 登録ログインスキーマの追加」をクリックします。
-
「 認証ログイン・スキーマの作成 」ページで、 「スキーマ名」 フィールドに名前を指定します。
-
選択した質問を選択し、「 構成済み 」リストに移動します。
-
「 ユーザー定義の質問 」セクションでは、「Q1」および「A1」フィールドに質問と回答を入力できます。
-
[電子メール登録] セクションで、[代替電子メールを登録] オプションを選択します。OTP を受信するには、ユーザー登録ログオンページから 代替電子メール ID を登録できます。
- [作成] をクリックします。一度生成されたログインスキーマは、登録プロセス中に設定されたすべての質問をエンドユーザに表示します。
CLI を使用したユーザー登録および管理ワークフローの作成
設定を開始する前に、次の項目が必要です。
- 認証仮想サーバに割り当てられた IP アドレス
- 割り当てられた IP アドレスに対応する FQDN
- 認証用サーバー証明書仮想サーバー
デバイスの登録および管理ページを設定するには、認証仮想サーバが必要です。次の図は、ユーザー登録を示しています。
認証仮想サーバーを作成するには
-
認証仮想サーバを設定します。SSL タイプで、認証仮想サーバーをポータル・テーマにバインドする必要があります。
> add authentication vserver <vServerName> SSL <ipaddress> <port> > bind authentication vserver <vServerName> [-portaltheme<string>]
-
SSL 仮想サーバ証明書とキーのペアをバインドします。
> bind ssl vserver <vServerName> certkeyName <string>
例:
> add authentication vserver authvs SSL 1.2.3.4 443 > bind authentication vserver authvs -portaltheme RFWebUI > bind ssl vserver authvs -certkeyname c1
LDAP ログオンアクションを作成するには
> add authentication ldapAction <name> {-serverIP <ipaddr|ipv6_addr|> [-serverPort <port>] [-ldapBase <BASE>] [-ldapBindDn <AD USER>] [-ldapBindDnPassword <PASSWORD>] [-ldapLoginName <USER FORMAT>]
注
最初の要素として、任意の認証ポリシーを設定できます。
例:
> add authentication ldapAction ldap_logon_action -serverIP 1.2.3.4 -serverPort 636 -ldapBase "OU=Users,DC=server,DC=com" -ldapBindDn administrator@ctxnsdev.com -ldapBindDnPassword PASSWORD -ldapLoginName samAccountName -serverport 636 -sectype SSL -KBAttribute userParameters
LDAP ログオン用の認証ポリシーを作成するには
> add authentication policy <name> <rule> [<reqAction]
例:
> add authentication policy ldap_logon -rule true -action ldap_logon_action
ナレッジベースの質問と回答の登録アクションを作成するには
ldapaction には、2 つの新しいパラメータが導入されました。KBA認証(登録と検証)の場合は「KB属性」、ユーザーの代替電子メールIDを登録する場合は「alternateEmailAttr」です。
> add authentication ldapAction <name> {-serverIP <ipaddr|ipv6_addr|> [-serverPort <port>] [-ldapBase <BASE>] [-ldapBindDn <AD USER>] [-ldapBindDnPassword <PASSWORD>] [-ldapLoginName <USER FORMAT>] [-KBAttribute <LDAP ATTRIBUTE>] [-alternateEmailAttr <LDAP ATTRIBUTE>]
例:
> add authentication ldapAction ldap1 -serverIP 1.2.3.4 -sectype ssl -serverPort 636 -ldapBase "OU=Users,DC=server,DC=com" -ldapBindDn administrator@ctxnsdev.com -ldapBindDnPassword PASSWORD -ldapLoginName samAccountName -KBAttribute userParameters -alternateEmailAttr userParameters
ユーザー登録と管理画面を表示する
「KBARegistrationSchema.xml」ログインスキーマは、エンドユーザーにユーザー登録ページを表示するために使用されます。次の CLI を使用して、ログインスキーマを表示します。
> add authentication loginSchema <name> -authenticationSchema <string>
例:
> add authentication loginSchema kba_register -authenticationSchema /nsconfig/loginschema/LoginSchema/KBARegistrationSchema.xml
ユーザー登録と管理画面を表示するには、URLまたはLDAP属性の2つの方法があります。
URL を使用する
URL パスに「/register」(https://lb1.server.com/registerなど) が含まれている場合は、URL を使用してユーザー登録ページが表示されます。
登録ポリシーを作成してバインドするには
> add authentication policylabel user_registration -loginSchema kba_register
> add authentication policy ldap1 -rule true -action ldap1
> bind authentication policylabel user_registration -policy ldap1 -priority 1
URL に ‘/register’ が含まれている場合に、認証ポリシーを認証、承認、監査仮想サーバーにバインドするには
> add authentication policy ldap_logon -rule "http.req.cookie.value(\"NSC_TASS\").contains(\"register\")" -action ldap_logon
> bind authentication vserver authvs -policy ldap_logon -nextfactor user_registration -priority 1
証明書を VPN グローバルにバインドするには
bind vpn global -userDataEncryptionKey c1
注
AD 属性に格納されているユーザーデータ (KB Q&A と登録されている代替電子メール ID) を暗号化するには、証明書をバインドする必要があります。
属性の使用
認証ポリシーを認証、承認、および監査仮想サーバーにバインドして、ユーザーがすでに登録されているかどうかを確認できます。このフローでは、知識ベースの質問と回答の登録係数の前に前述のポリシーを、KBAattribute が設定された LDAP にする必要があります。これは、ADユーザーが登録されているか、AD属性を使用していないかを確認するためです。
重要
ルール「AAA.USER.ATTRIBUTE (「kba_registered」) .EQ (“0”)」は、新しいユーザーがナレッジベースの質問と回答と代替電子メールに登録することを強制します。
ユーザーがまだ登録されていないかどうかを確認する認証ポリシーを作成するには
> add authentication policy switch_to_kba_register -rule "AAA.USER.ATTRIBUTE(\"kba_registered\").EQ(\"0\")" -action NO_AUTHN
> add authentication policy first_time_login_forced_kba_registration -rule true -action ldap1
登録ポリシーラベルを作成し、LDAP 登録ポリシーにバインドするには
> add authentication policylabel auth_or_switch_register -loginSchema LSCHEMA_INT
> add authentication policylabel kba_registration -loginSchema kba_register
> bind authentication policylabel auth_or_switch_register -policy switch_to_kba_register -priority 1 -nextFactor kba_registration
> bind authentication policylabel kba_registration -policy first_time_login_forced_kba_registration -priority 1
認証ポリシーを認証、承認、監査仮想サーバーにバインドするには
bind authentication vserver authvs -policy ldap_logon -nextfactor auth_or_switch_register -priority 2
ユーザー登録と管理の検証
前のセクションで説明したすべての手順を設定したら、以下に示すUIのスクリーンショットが表示されます。
-
lb 仮想サーバの URL を入力します(例:https://lb1.server.com)。ログオン画面が表示されます。
-
ユーザー名とパスワードを入力します。[Submit] をクリックします。ユーザー登録 画面が表示されます。
- ドロップダウンリストから希望する質問を選択し、「 回答」を入力します。
- [Submit] をクリックします。ユーザー登録の成功画面が表示されます。
ユーザーログオンの構成ページ
この例では、管理者は、最初の要素が LDAP ログオンであると想定しています(エンドユーザーがパスワードを忘れた場合)。次に、ナレッジベースの質問と回答の登録と電子メール ID OTP 検証に従い、最後にセルフサービスパスワードリセットを使用してパスワードをリセットします。
セルフサービスパスワードのリセットには、任意の認証メカニズムを使用できます。強力なプライバシーを実現し、不正なユーザーのパスワードのリセットを回避するために、知識ベースの質問と回答のどちらか、OTPまたは両方を電子メールで送信することをお勧めします。
ユーザーログオンページの構成を開始する前に、次の項目が必要です。
- ロードバランサ仮想サーバの IP
- ロードバランサ仮想サーバーの対応する FQDN
- ロードバランサーのサーバー証明書
CLI を使用してロードバランサ仮想サーバーを作成する
内部 Web サイトにアクセスするには、バックエンドサービスを前面にする LB 仮想サーバーを作成し、認証ロジックを認証仮想サーバーに委任する必要があります。
> add lb vserver lb1 SSL 1.2.3.162 443 -persistenceType NONE -cltTimeout 180 -AuthenticationHost otpauth.server.com -Authentication ON -authnVsName authvs
> bind ssl vserver lb1 -certkeyname c1
ロードバランシングでバックエンドサービスを表現するには、次の手順を実行します。
> add service iis_backendsso_server_com 1.2.3.4 HTTP 80
> bind lb vserver lb1 iis_backendsso_server_com
最初のポリシーとして認証を無効にした LDAP アクションの作成
> add authentication ldapAction ldap3 -serverIP 1.2.3.4 -serverPort 636 -ldapBase "OU=Users,DC=server,DC=com" -ldapBindDn administrator@ctxnsdev.com -ldapBindDnPassword PASSWORD -ldapLoginName samAccountName -authentication disabled
> add authentication policy ldap3 -rule aaa.LOGIN.VALUE("passwdreset").EQ("1") -action ldap3
ナレッジベースの質問と回答の検証アクションを作成する
セルフサービスパスワードリセットフローでのナレッジベースの質問と回答の検証では、認証を無効にして LDAP サーバを設定する必要があります。
> add authentication ldapAction <LDAP ACTION NAME> -serverIP <SERVER IP> -serverPort <SERVER PORT> -ldapBase <BASE> -ldapBindDn <AD USER> -ldapBindDnPassword <PASSWORD> -ldapLoginName <USER FORMAT> -KBAttribute <LDAP ATTRIBUTE> - alternateEmailAttr <LDAP ATTRIBUTE> -authentication DISABLED
例:
> add authentication ldapAction ldap2 -serverIP 1.2.3.4 -serverPort 636 -ldapBase "OU=Users,DC=server,DC=com" -ldapBindDn administrator@ctxnsdev.com -ldapBindDnPassword PASSWORD -ldapLoginName samAccountName -KBAttribute userParameters -alternateEmailAttr userParameters -authentication disabled
CLI を使用してナレッジベースの質問と回答の検証用の認証ポリシーを作成するには
add authentication policy kba_validation -rule true -action ldap2
電子メール検証アクションの作成
LDAP は、セルフサービスパスワードリセット登録の一部としてユーザーの電子メール ID または代替電子メール ID を必要とするため、電子メール検証要素の前段階的な要素である必要があります。
注:
電子メールOTPソリューションが機能するには、SMTPサーバーでログインベースの認証が有効になっていることを確認してください。
ログインベースの認証が有効になっていることを確認するには、SMTP サーバーで次のコマンドを入力します。ログインベースの認証が有効になっている場合、出力に AUTH LOGIN というテキストが太字で表示されます。
root @ns # telnet <IP address of the SMTP server> <Port number of the server>
ehlo
例:
root @ns # telnet 10.106.3.66 25
Trying 10.106.3.66...
10.106.3.66に接続されている。
エスケープ文字は「^]」です。
220 E2K13.NSGSanity.com Microsoft ESMTP MAIL Service ready at Fri, 22 Nov 2019 16:24:17 +0530
ehlo
250-E2K13.NSGSanity.com Hello [10.221.41.151]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH LOGIN
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST
ログインベースの認証を有効にする方法については、https://support.microfocus.com/kb/doc.php?id=7020367
を参照してください。
CLI を使用して電子メールアクションを設定するには
add authentication emailAction emailact -userName sender@example.com -password <Password> -serverURL "smtps://smtp.example.com:25" -content "OTP is $code"
例:
add authentication emailAction email -userName testmail@gmail.com -password 298a34b1a1b7626cd5902bbb416d04076e5ac4f357532e949db94c0534832670 -encrypted -encryptmethod ENCMTHD_3 -serverURL "smtps://10.19.164.57:25" -content "OTP is $code" -emailAddress "aaa.user.attribute(\"alternate_mail\")"
注
設定の「emailAddress」パラメータは、PI 式です。したがって、これは、セッションからのデフォルトのユーザーの電子メール ID、またはすでに登録されている代替電子メール ID のいずれかを取るように構成されています。
GUI を使用して電子メール ID を設定するには
- [セキュリティ] > [AAA — アプリケーショントラフィック] > [ポリシー] > [認証] > [詳細ポリシー] > [アクション] > [認証電子メールアクション] に移動します。[追加] をクリックします。
-
[認証電子メールアクションの作成] ページで詳細を入力し、[作成] をクリックします。
CLI を使用して電子メール検証用の認証ポリシーを作成するには
add authentication policy email_validation -rule true -action email
パスワードリセット係数の認証ポリシーを作成するには
add authentication policy ldap_pwd -rule true -action ldap_logon_action
ログインスキーマによるUIの提示
パスワードをリセットするには、セルフサービスパスワードリセット用の LoginSchema が 3 つあります。次の CLI コマンドを使用して、3 つのログインスキーマを表示します。
root@ns# cd /nsconfig/loginschema/LoginSchema/
root@ns# ls -ltr | grep -i password
-r--r--r-- 1 nobody wheel 2088 Nov 13 08:38 SingleAuthPasswordResetRem.xml
-r--r--r-- 1 nobody wheel 1541 Nov 13 08:38 OnlyUsernamePasswordReset.xml
-r--r--r-- 1 nobody wheel 1391 Nov 13 08:38 OnlyPassword.xml
CLI を使用して 1 つの認証パスワードリセットを作成するには
> add authentication loginSchema lschema_password_reset -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuthPasswordResetRem.xml"
> add authentication loginSchemaPolicy lpol_password_reset -rule true -action lschema_password_reset
ポリシーラベルを使用して、ナレッジベースの質問と回答とEメールによるOTP検証ファクタを作成
最初の要素が LDAP ログオンの場合、次のコマンドを使用して、次の要素に対する知識ベースの質問と回答および電子メールの OTP ポリシーラベルを作成できます。
> add authentication loginSchema lschema_noschema -authenticationSchema noschema
> add authentication policylabel kba_validation -loginSchema lschema_noschema
> add authentication policylabel email_validation -loginSchema lschema_noschema
ポリシーラベルによるパスワードリセット係数の作成
次のコマンドを使用して、ポリシーラベルを使用してパスワードリセット係数を作成できます。
> add authentication loginSchema lschema_noschema -authenticationSchema noschema
> add authentication policylabel password_reset -loginSchema lschema_noschema
> bind authentication policylabel password_reset -policyName ldap_pwd -priority 10 -gotoPriorityExpression NEXT
次のコマンドを使用して、ナレッジベースの質問と回答と電子メールポリシーを以前に作成したポリシーにバインドします。
> bind authentication policylabel email_validation -policyName email_validation -nextfactor password_reset -priority 10 -gotoPriorityExpression NEXT
> bind authentication policylabel kba_validation -policyName kba_validation -nextfactor email_validation -priority 10 -gotoPriorityExpression NEXT
フローをバインドする
LDAP ログオンの認証ポリシーの下に LDAP ログオンフローが作成されている必要があります。このフローでは、ユーザーは最初のLDAPログオンページに表示されたパスワードを忘れたリンクをクリックし、KBA検証に続いてOTP検証、最後にパスワードリセットページをクリックします。
bind authentication vserver authvs -policy ldap3 -nextfactor kba_validation -priority 10 -gotoPriorityExpression NEXT
すべての UI フローをバインドするには
bind authentication vserver authvs -policy lpol_password_reset -priority 20 -gotoPriorityExpression END
パスワードをリセットするためのユーザーログオンワークフロー
次に、ユーザーがパスワードをリセットする必要がある場合のユーザーログオンワークフローを示します。
-
lb 仮想サーバの URL を入力します(例:https://lb1.server.com)。ログオン画面が表示されます。
-
[パスワードを忘れた場合] をクリックします。検証画面には、ADユーザーに対して登録された最大6つの質問と回答のうち2つの質問が表示されます。
-
質問に答えて、[ログオン] をクリックします。登録した代替メールIDで受信したOTPを入力する必要があるメールOTP検証画面が表示されます。
-
電子メールの OTP を入力します。電子メールの OTP 検証が成功すると、パスワードのリセットページが表示されます。
-
新しいパスワードを入力し、新しいパスワードを確認します。[Submit] をクリックします。パスワードのリセットに成功すると、パスワードのリセットの成功画面が表示されます。
これで、リセットパスワードを使用してログオンできます。
トラブルシューティング
Citrix には、セルフサービスパスワードリセットを使用するときに直面する可能性のある基本的な問題のいくつかをトラブルシューティングするオプションがあります。次のセクションでは、特定の領域で発生する可能性のある問題のトラブルシューティングについて説明します。
NSログ
ログを分析する前に、次のコマンドを使用してログレベルを debug に設定することをお勧めします。
> set syslogparams -loglevel DEBUG
登録
次のメッセージは、ユーザー登録が成功したことを示します。
"ns_aaa_insert_hash_keyValue_entry key:kba_registered value:1"
Nov 14 23:35:51 <local0.debug> 10.102.229.76 11/14/2018:18:05:51 GMT 0-PPE-1 : default SSLVPN Message 1588 0 : "ns_aaa_insert_hash_keyValue_entry key:alternate_mail value:eyJ2ZXJzaW9uIjoiMSIsICJraWQiOiIxbk1oWjN0T2NjLVVvZUx6NDRwZFhxdS01dTA9IiwgImtleSI6IlNiYW9OVlhKNFhUQThKV2dDcmJSV3pxQzRES3QzMWxINUYxQ0tySUpXd0h4SFRIdVlWZjBRRTJtM0ZiYy1RZmlQc0tMeVN2UHpleGlJc2hmVHZBcGVMZjY5dU5iYkYtYXplQzJMTFF1M3JINFVEbzJaSjdhN1pXUFhqbUVrWGdsbjdUYzZ0QWtqWHdQVUI3bE1FYVNpeXhNN1dsRkZXeWtNOVVnOGpPQVdxaz0iLCAiaXYiOiI4RmY3bGRQVzVKLVVEbHV4IiwgImFsZyI6IkFFUzI1Nl9HQ00ifQ==.oKmvOalaOJ3a9z7BcGCSegNPMw=="
知識ベースの質問と回答の検証
次のメッセージは、ナレッジベースの質問と回答の検証に成功したことを示します。
"NFactor: Successfully completed KBA Validation, nextfactor is email"
電子メール ID の検証
次のメッセージは、パスワードのリセットが成功したことを示します。
"NFactor: Successfully completed email auth, nextfactor is pwd_reset"
nFactor ビジュアライザーを使用した SSPR の設定
SSPR の設定を開始する前に、次の LDAP サーバーを追加する必要があります。
-
ユーザー認証およびAD属性が指定された認証が有効な標準LDAPサーバ。
-
認証なしでユーザーパラメータ抽出のためのLDAPサーバー。
-
認証なしでSSLでパスワードをリセットするためのLDAPサーバー。また、ユーザーの詳細を格納するために使用するAD属性は、このサーバーで定義する必要があります。
-
認証が有効で、AD 属性が指定された、ユーザー登録用の LDAP サーバ
-
完全なフローを以下に示します。
-
次の CLI コマンドを使用して、証明書をグローバルにバインドします。
バインド vpn グローバル-ユーザーデータ暗号化キーワイルドカード
LDAP サーバーが追加されたので、ビジュアライザを使用して nFactor の設定を続行します
-
[セキュリティ] > [AAA] > [アプリケーショントラフィック] > [nFactor ビジュアライザー] > [nFactor フロー] に移動し、[追加] をクリックして、ボックス内のプラスアイコンをクリックします。
-
フローに名前を付けます。
-
[スキーマの追加] をクリックします。これは、既定のスキーマとして機能します。ログインスキーマページで「 追加 」をクリックします。
-
以下に示すように、スキーマに名前を与えた後、スキーマを選択します。スキーマ を選択する右上隅にある [選択] をクリックします。
-
[作成] をクリックし、[OK] をクリックします。
デフォルトのスキーマが追加されたら、次の3つのフローを設定する必要があります。
- ユーザー登録:明示的なユーザー登録
- パスワードのリセット: パスワードのリセット用
- 通常のログイン+登録ユーザーチェック:ユーザーが登録され、正しいパスワードを入力した場合、ユーザーはログインします。ユーザーが登録されていない場合は、ユーザーが登録ページに移動します。
ユーザー登録
私たちは、スキーマを追加した後に残したところから継続してみましょう。
-
[Add Policy] をクリックすると、ユーザーが明示的に登録しようとしているかどうかがチェックされます。
-
[作成] をクリックし、[追加] をクリックします。
-
強調表示された緑色の「+」アイコンをクリックして、ユーザ登録フローに次の認証要素を追加します。
-
[作成] をクリックします。
-
[ユーザー登録 1 ファクタの ポリシーの追加] をクリックします。
-
認証ポリシーを作成します。このポリシーは、ユーザー情報を抽出して検証してから、登録ページにリダイレクトします。
-
[作成] をクリックし、[追加] をクリックします。
-
緑色の「+」アイコンをクリックしてユーザー登録の別の要素を作成し、「 作成」をクリックします。[スキーマの追加]をクリックします。
-
次のスキーマを作成します。
-
[ポリシーの追加] をクリックし、次の認証ポリシーを作成します。
-
[作成] をクリックし、[追加] をクリックします。
パスワードのリセット
-
青色の「+」アイコンをクリックして、親 SSPR ファクタに別のポリシー(パスワードリセットフロー)を追加します。
-
[追加] をクリックし、以下の認証ポリシーを作成します。このポリシーは、ユーザーがログインページで「パスワードを忘れた場合」をクリックした場合にトリガーされます。
-
[作成] をクリックし、[追加] をクリックします。
-
パスワードリセット認証ポリシーの緑色の「+」アイコンをクリックして、別の要素を追加します。
-
[作成] をクリックします。
-
[Add policy] をクリックして、上記で作成したファクタの認証ポリシーを作成します。この要因は、ユーザーを検証するためのものです。
-
[作成] をクリックし、[追加] をクリックします。
-
緑色の「+」アイコンをクリックして、パスワードファクタフローに別の要素を追加します。これにより、パスワードをリセットするために提供された回答が検証されます。[作成] をクリックします。
-
[Add Policy] をクリックして、ファクタの認証ポリシーを追加します。
-
以前に作成した同じ認証ポリシーをドロップダウンメニューから選択し、[Add] をクリックします。
通常のログイン+登録ユーザーチェック
-
青い「+」アイコンをクリックして、別の認証ポリシー(通常のログインフロー)を親 SSPR 要素に追加します。
-
[追加] をクリックして、通常のユーザーログイン用の以下の認証ポリシーを作成します。
-
[作成] をクリックし、[追加] をクリックします。
-
上記で作成したポリシーの緑色の「+」アイコンをクリックして、別の要素(決定ブロック)を追加します。[作成] をクリックします。
-
[作成] をクリックします。
-
[Add Policy] をクリックして、このディシジョンファクタの認証ポリシーを作成します。
-
[作成] をクリックし、[追加] をクリックします。これは、ユーザーが登録されているかどうかをチェックします。
-
緑色の「+」アイコンをクリックして、登録ポリシーをユーザーに指します。
-
ドロップダウンメニューから登録係数を選択し、[Create] をクリックします。
-
青い「+」アイコンをクリックして、決定ブロックに別のポリシーを追加します。このポリシーは、登録ユーザーが認証を終了するためのものです。
-
[ポリシーの追加] をクリックして、以下の認証ポリシーを作成します。
-
[作成] をクリックし、[追加] をクリックします。