NSX Advanced Load Balancer は、仮想サービスでのクライアント SSL および TLS 接続の終了をサポートしています。この場合、サイトを認証し、安全な通信を確立するクライアントに証明書を送信する必要があります。
安全な接続を処理する仮想サービスには、以下が必要です。
SSL/TLS プロファイル
これにより、サポートされている暗号とバージョンが決まります。SSL/TLS プロファイルの詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「SSL/TLS プロファイル」トピックを参照してください。
SSL 証明書
これはサイトに接続しているクライアントに提示されます。
SSL 証明書は、NSX Advanced Load Balancer Web インターフェイスまたは API に接続している管理者に提示するためにも使用できます。また、クライアント (SE) 認証で SE とサーバ間の暗号化が必要な場合は、NSX Advanced Load Balancer SE でサーバに提示することもできます。
[SSL/TLS 証明書] ページでは、新しい SSL 証明書または証明書要求のインポート、エクスポート、生成を行うことができます。新しく作成された証明書は、NSX Advanced Load Balancer によって自己署名されるか、証明書署名リクエスト (CSR) として作成され、信頼できる認証局 (CA) に送信する必要があります。認証局は信頼できる証明書を生成します。
の自己署名証明書を作成すると、証明書と対応するプライベート キーの両方が生成されます。
インポートされた既存の証明書は、一致するキーが指定されるまで有効ではありません。
NSX Advanced Load Balancer は、PEM および PKCS #12 形式の証明書をサポートします。
[SSL/TLS 証明書] ページ
[SSL/TLS 証明書] ページを開きます。このタブには次の機能があります。
に移動して、[検索]:オブジェクトのリスト全体を検索します。
[作成]:ドロップダウン メニューから証明書のリストを表示し、証明書を作成します。
[編集]:[証明書の編集] ウィンドウを開きます。編集できるのは、対応するキーを持たない不完全な証明書のみです。
[エクスポート]:下矢印アイコンで証明書と対応するプライベート キーをエクスポートします。
[削除]:証明書は、現在仮想サービスに割り当てられていない場合にのみ削除できます。エラー メッセージは、仮想サービスが証明書を参照していることを示します。
このタブの表には、各証明書に関する次の情報が含まれています。
[名前]:証明書の名前が表示されます。証明書の名前の上にマウスを移動すると、証明書に自動的に関連付けられている中間証明書が表示されます。
[状態]:証明書の状態が表示されます。「緑」の状態は良好であることを示し、「黄色/オレンジ/赤」では、証明書がまもなく期限切れになるか、すでに期限切れになっていることを示し、証明書が不完全な場合は「灰色」の表示になります。
[共通名]:証明書が適用されるサイトの完全修飾名が表示されます。サイトが信頼済みとみなされるためには、このエントリはクライアントがブラウザに入力するホスト名と一致する必要があります。
[発行元]:認証局の名前が表示されます。
[アルゴリズム]:アルゴリズムが EC(楕円曲線)または RSA のいずれかとして表示されます。
[自己署名済み]:証明書が NSX Advanced Load Balancer で自己署名されているか、認証局によって署名されているかが表示されます。
[有効期限]:証明書の有効期限が切れる日時が表示されます。
証明書の作成
[作成] をクリックして、[新しい証明書 (SSL/TLS)] ウィンドウを開きます。
の順に移動します。新しい証明書を作成するときに、次のいずれかの証明書を選択できます。
[ルート/中間 CA 証明書]:この証明書は、アプリケーション証明書の証明書チェーンを自動的に作成するために使用されます。ファイルを使用して証明書をインポートしたり、テキストを貼り付けたりする以外の構成オプションはありません。ルート/中間証明書は、[SSL 証明書] ページの下部にある別のテーブルに表示されます。チェーンの中間証明書に依存するアプリケーション証明書をインポートする前に、ルート/中間証明書をインポートすることをお勧めします。
[アプリケーション証明書]:この証明書は、NSX Advanced Load Balancer での通常の SSL ターミネーションおよび復号化に使用されます。このオプションは、NSX Advanced Load Balancer が自分自身を認証する必要がある場合にバックエンド サーバに提示するためのクライアント証明書をインポートまたは作成するためにも使用されます。
[コントローラ証明書]:この証明書は、Controller クラスタの GUI および API に使用されます。アップロード後、 に移動して証明書を選択します。
新しい証明書を作成するには、次の手順を実行します。
[名前]:証明書の名前を指定します。
[タイプ]:作成する証明書のタイプをドロップダウン メニューから選択します。オプションは次のとおりです。
[自己署名済み]:NSX Advanced Load Balancer によって署名されたテスト証明書をすばやく作成します。クライアント ブラウザには、証明書が信頼されていないというエラーが表示されます。[HTTP アプリケーション プロファイルで HTTP Strict Transport Security (HSTS)] が有効になっている場合、クライアントは自己署名証明書を使用してサイトにアクセスできません。
[CSR]:最初に証明書要求を作成して有効な証明書を作成します。この要求は認証局に送信する必要があります。認証局は、NSX Advanced Load Balancer にインポートする必要がある有効な証明書を送り返します。
[インポート]:認証局から受信した、または別のサーバからエクスポートされた、完成した証明書をインポートします。
[共通名]:www.vmware.com など、サイトの完全修飾名を指定します。サイトが信頼済みとみなされるためには、このエントリはクライアントがブラウザに入力するホスト名と一致する必要があります。
作成する証明書のタイプに必要な情報を入力します。
自己署名証明書
CSR 証明書
証明書のインポート
OCSP Stapling は、ユーザー インターフェイスを使用して有効にして構成できます。詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』のトピック「NSX Advanced Load Balancer の OCSP Stapling」を参照してください。
自己署名証明書
NSX Advanced Load Balancer は自己署名証明書を生成できます。クライアント ブラウザはこれらの証明書を信頼せず、仮想サービスの証明書が信頼チェーンの一部でないことをユーザーに警告します。
自己署名証明書は、テストや、管理者がクライアントを制御し、ブラウザのセキュリティ アラートを安全にバイパスできる環境に適しています。パブリック Web サイトでは、自己署名証明書を使用しないでください。
[新しい証明書] ウィンドウで [タイプ] ドロップダウン メニューから [自己署名] オプションを選択した場合は、次の詳細を指定します。
[共通名]:www.vmware.com など、サイトの完全修飾名を指定します。サイトが信頼されていると見なされるには、このエントリがクライアントのブラウザに入力されたホスト名と一致する必要があります。
[組織]:NSX Advanced Load Balancer Networks, Inc. など、証明書を登録している会社またはエンティティ(オプション)。
[部門名]:開発など、証明書を担当する組織内のグループ(オプション)。
[国/地域]:組織が所在する国/地域(オプション)。
[都道府県]:組織が所在する都道府県(オプション)。
[市区町村]:組織の市区町村(オプション)。
[E メール]:証明書の E メール連絡先(オプション)。
[サブジェクトの別名 (SAN)]:サブジェクトの別名 (SAN) を使用すると、example.comや example.org など、単一の SSL 証明書で保護される追加のホスト名を指定できます。これらは、基本的に証明書で指定されているサブジェクトの代替 ID です。
[アルゴリズム]:EC(楕円曲線)または RSA のいずれかを選択します。RSA は古く、EC よりも安全性が低いと考えられていますが、より広範な古いブラウザと互換性があります。EC は新しく、計算コストが低く、一般的には安全性が高くなります。ただし、一部のクライアントではまだ受け入れられません。NSX Advanced Load Balancer では、仮想サービスを一度に 2 つの証明書(RSA と EC のそれぞれ 1 つずつ)で構成できます。これにより、クライアントと最適なアルゴリズムをネゴシエートできます。クライアントが EC をサポートしている場合、NSX Advanced Load Balancer はこのアルゴリズムを優先します。これにより、セキュリティを強化するために Perfect Forward Secrecy をネイティブでサポートできるというメリットが得られます。
[キーのサイズ]:ハンドシェイクに使用する暗号化のレベルを次のように選択します。
RSA 証明書には 2048 ビットが推奨です。値を大きくすると暗号化が強化される場合がありますが、NSX Advanced Load Balancer とクライアントの両方で必要な CPU リソースが増えます。暗号化を強化するには、代わりに ECC 証明書を使用します。
EC 証明書には SECP256R1 が推奨されます。
値を大きくすると暗号化が強化される場合がありますが、NSX Advanced Load Balancer とクライアントの両方で必要な CPU リソースが増えます。
[HSM 証明書を有効にする]:プライベート キーをコントローラまたはサービス エンジンにローカルに保存するのではなく、外部ハードウェア セキュリティ モジュールに保持します。このオプションを使用すると、HSM との通信に関する情報を含む HSM プロファイルを参照できます。
必要な詳細を指定した後、[保存] をクリックします。
CSR 証明書
証明書署名リクエスト (CSR) は、有効な SSL/TLS 証明書の作成に関連する 3 つの手順の最初の手順です。要求には、自己署名証明書と同じパラメータが含まれています。ただし、NSX Advanced Load Balancer は完了した証明書に署名しません。代わりに、クライアント ブラウザによって信頼される認証局によって署名されている必要があります。
[CSR] オプションは、[新しい証明書] ウィンドウの [タイプ] ドロップダウン メニューから選択できます。証明書署名リクエストの構成オプションは、自己署名証明書の場合と同じです。各フィールドの定義については、上記の説明を参照してください。
完了したら、[証明書の追加] ポップアップの左下にある [証明書署名要求] を選択して、完了した CSR を Thawte や Verisign などの信頼できる認証局 (CA) に転送します。次に、CA の Web サイトに直接コピーして貼り付けるか、後で使用するためにファイルに保存します。
CA が完了した証明書を発行したら、それを貼り付けるか、[証明書の追加] ポップアップの右下の [証明書] フィールドにアップロードします。この手順が完了するまで、証明書は NSX Advanced Load Balancer で使用できません。
CA が完了した証明書を返すまでに数日かかる場合があります。一方で、[新しい証明書] ウィンドウを閉じて [SSL/TLS 証明書] ページに戻ることができます。新しい証明書は、表の [有効期限] 列に「[待機中の証明書]」という表記で表示されます。
完了した証明書を受け取ったら、証明書の [編集] アイコンをクリックして [証明書の編集] を開き、証明書を貼り付けて [保存] をクリックして CSR 証明書を生成します。NSX Advanced Load Balancer は、完了した証明書からキーを自動的に生成します。
証明書のインポート
既存の PEM または PKCS /#12 SSL/ TLS 証明書を NSX Advanced Load Balancer に直接インポートできます(別のサーバまたはロード バランサからなど)。証明書には対応するプライベート キーがあります。このプライベート キーもインポートする必要があります。
NSX Advanced Load Balancer は、自己署名証明書または CSR 証明書のキーを自動的に生成します。
証明書をインポートするには、次の手順を実行します。
の順に移動します。
[作成] をクリックし、[アプリケーション証明書] などの証明書タイプを選択します。
[タイプ] をクリックし、[インポート] を選択します。証明書またはプライベート キーは、ファイルのコピー 貼り付けまたはアップロードによってインポートできます。
[PEM ファイル]:PEM ファイルには、プレーン テキストの Base64 エンコード形式の証明書またはプライベート キーが含まれています。証明書とプライベート キーは、個別の PEM ファイルに指定することも、単一の PEM ファイルに組み合わせることもできます。
証明書とプライベート キーが単一の PEM ファイルで提供されている場合は、[キーを貼り付け] テキスト ボックスに移動し、次のいずれかの方法でプライベート キーを追加します。
[ファイルのアップロード]:[ファイルのアップロード] ボタンをクリックし、PEM または PKCS12 ファイルを選択してから、[検証] ボタンをクリックしてファイルを解析します。アップロードに成功すると、[キー] フィールドに値が入力されます。
[貼り付け]:PEM キーをコピーして [キー] フィールドに貼り付けます。一部の電子メール クライアントまたはリッチ テキスト エディタの使用中に発生する可能性があるテキストに余分な文字が含まれていないことを確認します。キーと証明書をコピーして 1 つのファイルとして貼り付ける場合は、[検証] ボタンをクリックしてテキストを解析し、[証明書] フィールドに入力します。
証明書とプライベート キーが 2 つの個別の PEM ファイルで提供されている場合は、次の手順に従って各ファイルを個別にインポートします。
[証明書]:前述のように、コピーして貼り付けるか、ファイルをアップロードして [証明書を貼り付け] テキスト ボックスに証明書を追加します。
[キー]:コピーして貼り付けるか、ファイルをアップロードして [キーを貼り付け] フィールドにプライベート キーを追加します。
[PKCS#12 ファイル]:PKCS #12 ファイルには証明書とキーの両方が含まれています。PKCS #12 はバイナリ形式で、コピーして貼り付けることはできず、アップロードのみが可能です。[キーを貼り付け] に移動し、以下の手順に従って PKCS #12 ファイルをインポートします。
[ファイルのアップロード]:[ファイルのインポート] ボタンをクリックし、PKCS #12 ファイルを選択して、[検証] ボタンをクリックしてファイルを解析します。アップロードに成功すると、[キー] および [証明書] フィールドに値が入力されます。
[キーのパスフレーズ]:キー パスフレーズを追加して検証し、プライベート キーを暗号化することもできます。
[インポート]:[インポート] を選択して、新しい証明書とキーの追加を完了します。キーは証明書に埋め込まれ、NSX Advanced Load Balancer ユーザー インターフェイス内で 1 つのオブジェクトとして扱われます。
認証局
証明書を有効と見なすためには、信頼できる権限チェーンが必要です。使用する証明書が、すべてのクライアント ブラウザで認識されている認証局によって直接生成される場合、証明書チェーンは必要ありません。ただし、複数のレベルが必要な場合は、中間証明書が必要になる場合があります。サイトによってチェーン証明書が提示されない場合、クライアントは証明書で示されるパスをトラバースして独自に検証しますが、これにより DNS ルックアップが追加され、最初のサイトロードの時間が追加されます。理想的なシナリオは、サイト証明書とともにチェーン証明書を提示することです。
[証明書] ページの [認証局] セクションに追加されます。NSX Advanced Load Balancer は、チェーン内の次のリンクが存在することを検出した場合、自動的に証明書チェーンを構築します。
を介して、チェーン証明書または認証局の証明書がアップロードされると、チェーン証明書に添付されている証明書を検証するには、ページ上部の SSL 証明書テーブルで証明書の名前の上にポインタを置きます。NSX Advanced Load Balancer は複数のチェーン パスをサポートします。それぞれで同じ CA 発行者を共有することも、異なる発行者にチェーンすることもできます。
SSL/TLS プロファイル
NSX Advanced Load Balancer は、クライアントと仮想サービス間の SSL 接続を終了し、NSX Advanced Load Balancer とバックエンド サーバ間の暗号化を有効にする機能をサポートします。SSL/TLS プロファイルには、受け入れられた SSL バージョンのリストと SSL 暗号の優先順位付きリストが含まれています。
SSL/TLS プロファイルと SSL 証明書の両方を仮想サービスに割り当て、クライアント SSL/TLS 接続を終了するように構成する必要があります。NSX Advanced Load Balancer とサーバ間のトラフィックを暗号化する場合は、SSL/TLS プロファイルをプールに割り当てる必要があります。基本モードで新しい仮想サービスを作成するときに、デフォルトのシステム SSL/TLS プロファイルが自動的に使用されます。
SSL ターミネーションは、どのサービス ポートでも実行できます。ただし、ブラウザはデフォルトのポートを 443 と想定しています。ベスト プラクティスは、ポート 80 でサービスを作成して HTTP と HTTPS の両方を受け入れるように仮想サービスを構成し、[+] アイコンを選択してサービス ポートを追加し、SSL を有効にして新しいサービス ポートを 443 に設定することです。通常、HTTP から HTTPS へのリダイレクトが優先されます。これは、ポリシーまたは [System-HTTP-Secure] アプリケーション プロファイルを使用して実現できます。
各 SSL/TLS プロファイルには、RSA または楕円曲線証明書、またはその両方で使用できる、サポートされている SSL 暗号とバージョンのデフォルトのグループが含まれています。作成する新しい SSL/TLS プロファイルに、後で使用する証明書タイプに適した暗号が含まれていることを確認します。NSX Advanced Load Balancer に含まれるデフォルトの SSL/TLS プロファイルは、幅広いセキュリティを提供します。たとえば、標準プロファイルは一般的な展開に対して機能します。
新しい SSL/TLS プロファイルを作成するか、既存のプロファイルを使用すると、セキュリティ、互換性、計算費用の間でさまざまなトレードオフが発生します。たとえば、受け入れ可能な暗号と SSL バージョンのリストを増やすと、クライアントとの互換性が高まり、セキュリティが低下する可能性があります。
NSX Advanced Load Balancer を使用すると、複数の SSL プロファイルを単一の仮想サービスに関連付けることで、クライアント コミュニティ内の広範なセキュリティ ニーズに対応でき、またサービス エンジンはクライアントの IP アドレスに基づいて選択できるようになります。詳細については、このガイドの「クライアント IP ベースの SSL プロファイル」セクションを参照してください。
SSL プロファイル設定
の順に移動します。
[検索]:オブジェクトのリスト全体を検索します。
[作成]:新しいアプリケーションまたは
systemprofile
を開きます。[編集]:編集する既存のプロファイルを開きます。
[削除]:SSL/TLS プロファイルが現在仮想サービスに割り当てられていない場合にのみ削除できます。エラー メッセージは、仮想サービスがプロファイルを参照していることを示します。デフォルトのシステム プロファイルは変更できますが、削除することはできません。
このタブの表には、SSL/TLS プロファイルごとに次の情報が表示されます。
[名前]:プロファイルの名前。
[承諾済みバージョン]:プロファイルで承認され SSL および TLS バージョン。
SSL プロファイルの作成
SSL プロファイルを作成または編集するには、次の手順を実行します。
[名前]:SSL/TLS プロファイルの一意の名前を指定します。
[タイプ]:プロファイルのタイプをドロップダウン メニューから選択します。
[承諾済みバージョン]:ドロップダウン メニューから 1 つ以上の SSL/TLS バージョンを選択して、このプロファイルに追加します。時系列では、TLS v1.0 がサポートされる最も古いバージョンで、TLS v1.2 が最新バージョンです。SSL v3.0 は、NSX Advanced Load Balancer v15.2 以降ではサポートされなくなりました。一般的に SSL を使用すると、古いバージョンには多くの既知の脆弱性があり、新しいバージョンには未検出の脆弱性が多数存在します。セキュリティと同様に、NSX Advanced Load Balancer は、セキュリティの動的な性質を理解し、NSX Advanced Load Balancer を常に最新の状態に保つよう推奨します。一部の SSL 暗号は、サポートされる SSL または TLS の特定のバージョンに依存します。詳細については、「OpenSSL」を参照してください。
[承認された暗号]:[承認された暗号] フィールドに、承認された暗号のリストを入力します。入力する各暗号は、OpenSSL に記載されている暗号スイート名に準拠している必要があります。各暗号はコロンで区切ります。たとえば、AES:3DES は、このプロファイルが AES および 3DES 暗号を受け入れることを意味します。暗号をクライアントとネゴシエートする場合、NSX Advanced Load Balancer はリストに記載されている順番で暗号を優先します。SSL/TLS プロファイルは、RSA 証明書と楕円曲線証明書の両方で使用できます。これらの 2 種類の証明書では異なるタイプの暗号を使用できるため、両方のタイプに暗号を組み込むことが重要です。最も安全な暗号のみを選択すると、NSX Advanced Load Balancer の CPU 負荷が高くなる可能性があり、古いブラウザとの互換性も低下する可能性があります。
PKI プロファイル
PKI プロファイルの詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「PKI プロファイル」および「PKI プロファイル設定」トピックを参照してください。
証明書管理
新しい証明書を作成するには、次の手順を実行します。
ユーザー インターフェイスから、
の順に移動します。[作成] をクリックします。
[新しい証明書管理] 画面で、プロファイルの [名前] を入力します。
[ControlScript] フィールドで、必要に応じて必要なアラート スクリプト構成を選択します。
注:必要に応じて、ドロップダウン メニューで [作成] ボタンをクリックして、新しい ControlScript を作成します。
プロファイルで一部のパラメータ値をスクリプトに渡す必要がある場合は、[カスタム パラメータを有効にする] を選択します。
パラメータの [名前] および [値] を入力します。
注:アップロード後にファイルが変更された場合は、ControlScript を再アップロードして変更を反映します。
Trust Anchor サービスの場所 (URL) とサービスのログイン認証情報がスクリプトに渡されます。機密性の高いパラメータ(パスワードなど)の場合は、[機密] チェック ボックスを選択します。
パラメータに機密データであることを示すマークを付けると、その値が Web インターフェイスに表示されたり、API によって渡されることを防ぐことができます。CSR 作成時に動的に割り当てられるパラメータについては、[動的] チェック ボックスをオンにします。これにより、プロファイル内でパラメータの割り当てが解除されます。
[保存] をクリックします。
認証プロファイル
認証プロファイル (「認証プロファイル」) を使用すると、HTTP 基本認証を介してクライアントを仮想サービスに構成できます。
認証プロファイルは、仮想サービスの [詳細プロパティ] タブの HTTP 基本認証設定を介して有効になります。
NSX Advanced Load Balancer は、HTTP プロファイルの [認証] セクションで構成される SSL クライアント証明書を介したクライアント認証もサポートします。
認証プロファイル設定
[認証] タブを開きます。このタブには次の機能があります。
を選択して、[検索]:オブジェクトのリスト全体を検索します。
[作成]:[作成/編集] ウィンドウを開きます。
[編集]:[作成/編集] ウィンドウを開きます。
[削除]:認証プロファイルは、現在仮想サービスに割り当てられていないか、NSX Advanced Load Balancer で管理認証に使用されていない場合にのみ削除できます。
このタブの表には、権限プロファイルごとに次の情報が表示されます。
[名前]:プロファイルの名前。
[タイプ]:タイプは LDAP になります。
認証プロファイルの作成
認証プロファイルを作成または編集するには、次の手順を実行します。
![](images/GUID-8BA6D629-EB78-4F88-942E-C5D336C7CA0B-low.jpg)
[名前]:一意の名前を入力します。
[LDAP サーバ]:IP アドレスを追加して、1 つ以上の LDAP サーバを構成します。
[LDAP ポート]:これは LDAP サーバとの通信に使用するサービス ポートです。通常、LDAP の場合は 389、LDAPS (SSL) の場合は 636 です。
[TLS を使用したセキュア LDAP]:LDAP サーバとの安全な通信のために [startTLS] を有効にします。これには、サービス ポートの変更が必要になる場合があります。
[ベース DN]:LDAP ディレクトリのベース識別名 (DN)。DN が必要で、ユーザーまたはグループ検索 DN のように入力されていない場合に、設定のデフォルトとして使用されます。
[匿名バインド]:LDAP サーバにバインドしてユーザー認証情報を検証するために必要な最小 LDAP 設定。このオプションは、LDAP サーバの管理者アカウントにアクセスできない場合に便利です。
[ユーザー DN パターン]:ユーザー トークンを実際のユーザー名に置き換えると、LDAP ユーザーの DN パターンが LDAP ユーザーの割り当てに使用されます。パターンは、LDAP サーバのユーザー レコード パスと一致する必要があります。たとえば、cn=,ou=People,dc=myorg,dc=com は、ou "People" のすべてのユーザー レコードが見つかるパターンです。特定のユーザーの LDAP を検索するときに、トークンをユーザー名に置き換えます。
[ユーザー トークン]:LDAP トークンは、ユーザー DN パターンの実際のユーザー名で置き換えられます。たとえば、[ユーザー DN パターン] が「cn=-user-,ou=People,dc=myorg,dc=com」として構成されている場合、トークン値は -user- である必要があります。
[ユーザー ID 属性]:LDAP ユーザー ID 属性は、単一のユーザー レコードを一意に識別するログイン属性です。この属性の値は、ログイン プロンプトで使用されるユーザー名と一致する必要があります。
[ユーザー属性]:ユーザー割り当ての成功時に取得する LDAP ユーザー属性。これらの属性は、デバッグ目的でのみ使用されます。
[管理者バインド]:以下の [LDAP ディレクトリ設定] で構成された LDAP 管理者認証情報は、LDAP のユーザーまたはグループをクエリするときに、NSX Advanced Load Balancer を管理者としてバインドするために使用されます。
[管理バインド DN]:LDAP 管理者の完全な DN。管理バインド DN は、LDAP サーバにバインドするために使用されます。管理者は、ユーザー検索 DN またはグループ検索 DN の下のグループでユーザーを検索するのに十分な権限を持っている必要があります。
[管理バインド パスワード]:管理者パスワードです。パスワードの有効期限または変更は処理されません。パスワードは REST API および CLI では表示されません。
[ユーザー検索 DN]:LDAP ユーザー検索 DN は、LDAP ディレクトリ内の特定のユーザーを検索するためのルートです。この LDAP ディレクトリのサブツリーにあるユーザー レコードのみが認証に許可されます。ベース DN 値は、この値が構成されていない場合に使用されます。
[グループ検索 DN]:LDAP グループ検索 DN は、LDAP ディレクトリ内の特定のグループを検索するためのルートです。ユーザー メンバーシップがチェックされるのは、この LDAP ディレクトリ サブツリー内の一致するグループのみです。ベース DN 値は、この値が構成されていない場合に使用されます。
[ユーザー検索範囲]:LDAP ユーザーの検索範囲により、ユーザー検索の DN から始まるユーザー検索の深度を定義します。オプションは、ベース検索、1 つ下のレベルの検索、またはサブツリー全体の検索です。デフォルトのオプションは、ユーザー検索 DN で深度 1 レベルの検索を実行することです。
[グループ検索範囲]:LDAP グループの検索範囲により、グループ検索 DN から始まるグループ検索の深度を定義します。デフォルト値はサブツリー全体です。
[ユーザー ID 属性]:LDAP ユーザー ID 属性は、単一のユーザー レコードを一意に識別するログイン属性です。この属性の値は、ログイン プロンプトで使用されるユーザー名と一致する必要があります。
[グループ メンバー属性]:各グループ メンバーを識別する LDAP グループ属性。たとえば、member と memberUid は一般的に使用される属性です。
[ユーザー属性]:ユーザー割り当ての成功時に取得する LDAP ユーザー属性。これらの属性はデバッグ専用です。
[クライアントのユーザー ID に HTTP ヘッダーを挿入]:HTTP ヘッダーを、宛先サーバに送信する前にクライアント要求に挿入します。このフィールドは、ヘッダーに名前を付ける場合に使用されます。値はクライアントのユーザー ID になります。この同じユーザー ID 値は、仮想サービスのログの [ユーザー ID] フィールドにも使用されます。
[必要なユーザー グループ メンバーシップ]:ユーザーはこれらのグループのメンバーである必要があります。各グループは DN によって識別されます。たとえば、
cn=testgroup,ou=groups,dc=LDAP,dc=example,dc=com
などです。[認証情報キャッシュの有効期限]:クライアント認証がキャッシュに格納される最大許容期間。
[グループ メンバー属性が完全 DN です]:グループ メンバー エントリには、ユーザー ID 属性値だけでなく、完全な DN が含まれています。