26 クライアント/サーバー間のセキュリティ構成
次の各トピックでは、クライアント/サーバー間のセキュアな通信の構成について説明します。
ディレクトリ・データへのアクセスの保護の詳細は、「データへのアクセス制御」を参照してください。
プロキシとディレクトリ・サーバーまたはデータ・ソースの間のセキュリティ構成の詳細は、「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
26.1 SSLの迅速な起動と実行
Oracle Unified Directoryには、SSLおよびStartTLSを構成し、使用するためのいくつかのオプションが用意されています。構成オプションが豊富だと、テクノロジに不慣れな人やテスト目的で迅速に起動と実行を試したい人は厄介に感じるかもしれません。
この項では、Oracle Unified Directoryが自己署名証明書を使用するSSLベースの接続を受け入れるために実行する必要があるステップをリストします。
この項の手順では、信頼されるキーストアの知識が前提となります。
-
キーストアの詳細は、「キー・マネージャ・プロバイダの構成」を参照してください。
-
トラスト・ストアの詳細は、「信頼マネージャ・プロバイダの構成」を参照してください。
ノート:
通常の運用で自己署名証明書を使用することはお薦めできません。通常の運用で証明書をインストールする場合は、「キー・マネージャ・プロバイダの構成」の手順に従ってください。
26.1.1 既存の秘密キーおよび証明書を使用したSSLの設定
opensslコマンド行ツールで生成したセキュリティ証明書がすでにある場合、Oracle Unified Directoryで使用するにはキーストアを作成し、証明書を更新する必要があります。
次の例では、次の証明書ファイルがすでに存在します。
-
ca.crt
認証局公開キー(証明書)
-
mycert.key
以前に生成した証明書の秘密キー
-
mycert.crt
以前に生成した証明書の公開キー
既存のセキュリティ証明書を更新するには:
これでJKSキーストアkeystore.jksとこれに含まれる証明を使用してキー・マネージャ・プロバイダを構成できます。「JKSキー・マネージャ・プロバイダの構成」を参照してください。
26.1.2 自己署名証明書を使用したSSLベースの接続の受入れ
このステップは、インストール時にSSLおよびStartTLS設定が指定されなかったか、これらの設定を変更する場合にのみ必要です。
この手順の前提条件は次のとおりです:
-
Oracle Unified Directoryが作業中のシステムにインストールされています。
-
Java
keytoolユーティリティがパス内にあります。それがない場合は、パスに追加するか、コマンド呼出し時に完全パスを指定してください。keytoolユーティリティは、Java Runtime Environment (JRE)に提供されています。 -
管理コネクタがデフォルト・ポート(4444)でリッスンし、
dsconfigコマンドがローカル・ホスト上で実行されているサーバーにアクセスしています。そうでない場合は、--portオプションと--hostnameオプションを指定する必要があります。
-
keytoolコマンドに-genkeypairオプションを指定して、証明書用の秘密キーを生成します。たとえば:
$ keytool -genkeypair -alias server-cert -keyalg rsa \ -dname "CN=myhost.example.com,O=Example Company,C=US" \ -keystore config/keystore -storetype JKS
-
-aliasalias。キーストア内の証明書を参照するために使用する名前を指定します。サーバーが使用するデフォルト名はserver-certです。 -
-keyalgalgorithm。秘密キーを生成するために使用するアルゴリズムを指定します。これは通常、rsaです。 -
-dnamesubject。証明書に使用するサブジェクトを指定します。環境に合せて、
-dname引数の値を変更します:CN属性の値は、証明書がインストールされているシステムの完全修飾名です。O属性の値は、社名または組織名です。C属性の値は、2文字の国名の省略形です。 -
-keystorepath。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。サーバーによって使用されるデフォルトのキーストア・パスは、config/keystoreです。 -
-keypasspassword。キーストア内の秘密キーを保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。 -
-storepasspassword。キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。 -
-storetypetype。使用されるキーストア・タイプを指定します。たとえば、JKSキーストアの場合、値は常にJKSです。
キーストアの内容を保護するパスワードと秘密キーを保護するパスワードの入力が要求されます。
-
-
キーのための自己署名証明書を生成します。
たとえば:
$ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore -storetype JKS
-
-aliasalias。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypairオプションを使用して秘密キーを生成したときに指定した値と同一である必要があります。 -
-validitydays。証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。 -
-keystorepath。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。 -
-keypasspassword。キーストア内の秘密キーを保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。 -
-storepasspassword。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。 -
-storetypetype。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。
キーストア・パスワードおよび秘密キーのパスワードの入力を要求されたら、前のステップで入力したパスワードを入力します。
-
-
config/keystore.pinという名のテキスト・ファイルを作成します。このファイルには、キーストアの内容を保護するためのパスワードを指定する必要があります。このファイルを変更する場合は、キーストア・マネージャ構成と一致する必要があることに注意してください。別のファイル名を使用する場合は、該当するキーストア・マネージャの
key-store-fileプロパティをそのパスおよびファイル名と一致させる必要があります。 -
作成した証明書の公開キーをエクスポートします。
たとえば:
$ keytool -exportcert -alias server-cert -file config/server-cert.txt -rfc \ -keystore config/keystore -storetype JKS
-
新規にトラスト・ストアを作成して、それにサーバー証明書をインポートします。
たとえば:
$ keytool -importcert -alias server-cert -file config/server-cert.txt \ -keystore config/truststore -storetype JKS
-
dsconfigコマンドを使用して、キー・マネージャ・プロバイダ、信頼マネージャ・プロバイダおよび接続ハンドラを有効にします。たとえば:
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n set-key-manager-provider-prop --provider-name JKS --set enabled:true $ dsconfig -D "cn=directory manager" -j pwd-file -X -n set-trust-manager-provider-prop --provider-name JKS --set enabled:true $ dsconfig -D "cn=directory manager" -j pwd-file -X -n set-connection-handler-prop --handler-name "LDAPS Connection Handler" --set trust-manager-provider:JKS --set key-manager-provider:JKS --set listen-port:1636 --set enabled:true
ポート
1636は標準のLDAPSポートですが、そのポートがすでに占有されている場合や、レギュラー・ユーザーの場合は使用できないことがあります。1636以外のポート上でSSLベースの接続を受け入れる必要がある場合は、最後のコマンドのlisten-portプロパティを使用するポート番号に変更します。-
ステップ1で秘密キーを生成したときに
-keypassおよび-storepassに異なる値を指定した場合は、次のようにdsconfigを使用してキー・パスワードを指定する必要があります。$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \ create-key-manager-provider-key-pin --provider-name JKS --set key-pin-file:<file with key password> --type generic --pin-name server-cert
キーPINの名前には、証明書の別名と同じ名前を指定します。これは、キー・マネージャ・プロバイダの各証明書に関連付けられているキーPIN/パスワードを指定するために必要です。
-
ステップ3で
config/keystore.pinと異なる場所および名前のテキスト・ファイルを作成した場合、たとえば、ファイル名がconfig/mykeystore.pinだとしたら、以下のように情報を指定します:$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \ set-key-manager-provider-prop --provider-name JKS --set enabled:true \ --set keystore-pin-file:/config/mykeystore.pin
キーストアおよびトラスト・ストアの詳細は、「キー・マネージャ・プロバイダの構成」および「信頼マネージャ・プロバイダの構成」をそれぞれ参照してください。
-
-
これでサーバーはSSLベースのクライアント接続を受け入れる第2のリスナーを持つことになります。
ldapsearchコマンドで、以下のように構成をテストします:$ ldapsearch --port 1636 --useSSL --baseDN "" --searchScope base "(objectClass=*)"
サーバーの証明書を信頼するかどうか尋ねられます。
yesと入力すると、ルートDSEエントリが戻されます。
26.2 キー・マネージャ・プロバイダの構成
キー・マネージャ・プロバイダは、SSLまたはStartTLSネゴシエーションを実行するときにディレクトリ・サーバーによって使用される証明書へのアクセスを提供します。
この項では、キー・マネージャ・プロバイダの構成について説明します。
詳細は、『Oracle Unified Directory構成リファレンス』のキー・マネージャ・プロバイダの構成に関する項を参照してください。
26.2.1 キー・マネージャ・プロバイダの概要
Oracle Unified Directoryでは、特定のキー・マネージャ・プロバイダのキーストア・フォーマットがサポートされます。
キー・マネージャ・プロバイダを次に示します。
-
JKSキーストア、Java Secure Socket Extension (JSSE)によって使用されるデフォルトのキーストア・フォーマット
-
PKCS #12ファイル
-
ハードウェア・ベースのデバイス(ハードウェア・セキュリティ・モジュール(HSM)または暗号アクセラレータなど)
-
PKCS #11デバイス(特定のハードウェア・ベースのキー・マネージャ・プロバイダ)
ノート:
PKCS #11は、プロキシ・サーバー・インスタンスとの使用がサポートされていません。
後続の項で、これらのキー・マネージャ・プロバイダを使用するためのOracle Unified Directoryの構成プロセスについて説明します。
管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様に、管理コネクタにはキー・マネージャが必要です。Oracle Unified Directoryは、管理コネクタ専用のキー・マネージャを提供します。これはデフォルトで有効になっています。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
26.2.2 JKSキー・マネージャ・プロバイダの使用
JKSキーストアは、大半のJSSEの実装で使用されるデフォルトのキーストアであり、多くの環境で優先されるキーストア・タイプです。このキーストア・タイプを使用するようにサーバーを構成するには、まず有効な証明書を含むJKSキーストアを取得する必要があります。これを行うには、自己署名証明書を生成するか、既存の認証局(CA)に証明書署名リクエストを発行して署名された証明書をインポートします。
ここで述べたすべてのステップでkeytoolユーティリティを使用する必要があります。このユーティリティはJavaランタイム環境に用意されています。このユーティリティは通常、Javaインストール・ディレクトリのルート下のbinディレクトリにあります。keytoolユーティリティの使用方法の詳細は、Java公式ドキュメント(http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。
JKSキー・マネージャ・プロバイダを使用する手順は次のとおりです:
26.2.2.1 秘密キーの生成
自己署名証明書を使用する場合でも、また証明書署名リクエストを生成する場合でも、まず秘密キーを生成する必要があります。これは、-genkeypairオプションを指定してkeytoolユーティリティによって実行できます。このオプションには次の引数を指定できます:
表26-1 秘密キーの引数
| 引数 | 説明 |
|---|---|
|
|
キーストア内の証明書を参照するために使用する名前を指定します。サーバーによって使用されるデフォルト名は |
|
|
秘密キーを生成するために使用するアルゴリズムを指定します。これは通常、 |
|
|
証明書に使用するサブジェクトを指定します。サブジェクトには通常、最低でも |
|
|
秘密キー情報を含むファイルのパスを指定します。ディレクトリ・サーバーによって使用されるデフォルトのキーストア・パスは、 |
|
|
キーストア内の秘密キーを保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。 これはオプションのパラメータであり、コマンドライン履歴にクリア・テキスト・パスワードが記憶されるため、使用しないことをお薦めします。 |
|
|
キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。 これはオプションのパラメータであり、コマンドライン履歴にクリア・テキスト・パスワードが記憶されるため、使用しないことをお薦めします。 |
|
|
使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常に |
keytool -genkeypairコマンドを使用して秘密キーを生成します:必要なパスワードの入力を求められます。
$ keytool -genkeypair -alias server-cert -keyalg rsa \ -dname "CN=server.example.com,O=example.com,C=US" \ -keystore config/keystore.jks -storetype JKS
26.2.2.2 証明書への自己署名
自己署名証明書の場合は、-selfcertオプションを使用します。このオプションに使用される最も重要な引数は、次のとおりです:
表26-2 自己署名証明書のオプション
| 引数 | 説明 |
|---|---|
|
|
キーストア内の証明書を参照するために使用する名前を指定します。 |
|
|
証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。 |
|
|
キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。 |
|
|
キーストア内の秘密キーを保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。 これはオプションのパラメータであり、コマンドライン履歴にクリア・テキスト・パスワードが記憶されるため、使用しないことをお薦めします。 |
|
|
キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。 これはオプションのパラメータであり、コマンドライン履歴にクリア・テキスト・パスワードが記憶されるため、使用しないことをお薦めします。 |
|
|
使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常に |
keytool -selfcertコマンドを使用して自己署名証明書を生成します:必要なパスワードの入力を求められます。
$ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore.jks -storetype JKS
26.2.2.3 外部認証局を使用した証明書への署名
外部認証局を使用して証明書に署名する場合は、-certreqオプションを使用して証明書署名リクエスト(CSR)を生成します。認証局にCSRを提出して署名してもらいます。この方法と、署名済証明書を取得する方法は、認証局によって異なる場合があります。
26.2.2.4 JKSキー・マネージャ・プロバイダの構成
署名済の証明書(自己署名か外部CAによる署名かを問わず)を含むJKSキーストアを作成したときに、そのキーストアのキー・マネージャ・プロバイダ・エントリの構成により、そのキーストアを使用するようにサーバーを構成できます。
この例ではdsconfigを使用してデフォルトのJKSキー・マネージャ・プロバイダのプロパティを構成します。キー・マネージャ・プロバイダのすべてのプロパティの詳細は、『Oracle Unified Directory構成リファレンス』のファイル・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。
dsconfigコマンドを使用してキー・マネージャ・プロバイダ・エントリを構成します。
dsconfig -D "cn=Directory Manager" -j pwd-file -X -n \ set-key-manager-provider-prop --provider-name "JKS" \ --set enabled:true --set "key-store-type:JKS" \ --set "key-store-file:config/keystore.jks" \ --set "key-store-pin-file:key-store-pwd-file"
「秘密キーの生成」のステップ1で秘密キーを生成したときに、-keypassおよび-storepassに異なる値を指定した場合は、dsconfigを使用してキー・パスワードを指定する必要があります。たとえば:
dsconfig -D "cn=directory manager" -j pwd-file -X -n \ create-key-manager-provider-key-pin --provider-name JKS --set key-pin-file:<file with key password> --type generic --pin-name server-cert
重要: キーPINの名前を指定する場合は、証明書の別名と同じ名前を使用します。キー・マネージャ・プロバイダの各証明書に関連付けられているキーPIN/パスワードを指定するために、キーPINの名前および証明書の別名は同じにする必要があります。
26.2.3 PKCS #12キー・マネージャ・プロバイダの使用
PKCS #12は、秘密キーを含めて、証明書情報を格納するための標準フォーマットです。Oracle Unified Directoryは証明書の秘密キーを含む証明書キーストアとしてPKCS #12ファイルを使用できます。
PKCS #12は証明書情報を格納するための共通のフォーマットであるため、このフォーマットの証明書をすでに持っているか、使用する認証局(CA)がこのフォーマットで証明書を作成することがあります。場合によっては、既存の証明書をPKCS #12フォーマットに変換できます。たとえば、Network Security Services (NSS)証明書データベースにすでに証明書がある場合は、NSS pk12utilツールでそれをインポートできます。
次の例では、pk12utilツールを使用して、データベース../../alias/slapd-config-key3.dbに含まれるserver-certという名の証明書をPKCS #12ファイル/tmp/server-cert.p12にエクスポートします:
$ ./pk12util -n server-cert -o /tmp/server-cert.p12 \ -d ../../alias -P "slapd-config-"
PKCS #12フォーマットの証明書を新規作成するには、「JKSキー・マネージャ・プロバイダの使用」の手順を使用してJKSキーストア内の証明書を取得します。手順の中で唯一異なる点は、keytoolコマンドを呼び出すときに、-storetype JKSでなく-storetype PKCS12を使用する点です。PKCS #12ファイルの中の自己署名証明書を使用するには、次のコマンドを使用します:
$ keytool -genkeypair -alias server-cert -keyalg rsa \ -dname "CN=server.example.com,O=example.com,C=US" \ -keystore config/keystore.p12 -storetype PKCS12 $ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore.p12 -storetype PKCS12
サーバーはJKSと同様に、PKCS #12証明書ファイルで使用するためにJKSキー・マネージャ・プロバイダの構成エントリと同一構成属性を使用するテンプレートのキー・マネージャ・プロバイダを提供します。相違点は、key-store-type属性の値がPKCS12であり、key-store-file属性がJKSキーストアでなく、PKCS #12ファイルの場所を参照する必要がある点です。次の例では、dsconfigを使用してPKCS #12キーストア・マネージャ・プロバイダを構成します:
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n\ set-key-manager-provider-prop --provider-name "PKCS12" --set enabled:true \ --set java-class:org.opends.server.extensions.FileBasedKeyManagerProvider \ --set enabled:true --set "key-store-type:PKCS12" \ --set "key-store-file:/config/keystore.p12" \ --set "key-store-pin:secret"
構成可能なプロパティの完全なリストは、『Oracle Unified Directory構成リファレンス』のファイル・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。
26.2.4 PKCS #11キー・マネージャ・プロバイダの概要
PKCS #11は、暗号情報を保持し、暗号機能を実行できるデバイスと対話するために使用される標準インタフェースです。
PKCS #11インタフェースには、ディレクトリ・サーバーについて2つの共通する使用法があります:
-
暗号アクセラレータは、このインタフェースを使用して製品による暗号処理を外部ボード(または場合によっては、システムのCPU内部の特殊モジュールや、OSカーネル内部のフレームワーク)に任せることができるため、暗号処理を高速化できます。
-
ハードウェア・セキュリティ・モジュール(HSM)は、このインタフェースを使用して、キー情報を格納するための安全なリポジトリを提供します。これは重要なキー情報が漏えいする危険性を顕著に減らし、安全な通信メカニズムの全体的整合性の保護に役立ちます。
ノート:
PKCS #11フォーマットは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。
Oracle Unified Directoryでは、現在、Solaris OS暗号フレームワークを使用してSolaris 10以上(SPARCおよびx86/x64システム上)が稼働するシステム上でのみテストおよび検証されたPKCS #11サポートが提供されます。このSolaris OS暗号フレームワークに接続するデバイスはこの方法でサポートされます。これにはソフトトークン・デバイスが含まれます。このデバイスはソフトウェアでシミュレートされるため、PKCS #11サポートを提供するハードウェア・デバイスの有無にかかわらずSolaris暗号フレームワークをサポートするすべてのシステムで使用できます。
サードパーティのPKCS #11デバイスがSolarisシステムにインストールされている場合、通常はすでにSolaris OS暗号フレームワークでそのデバイスへのアクセスが構成されています。ただし、単にソフトウェア・トークンを使用する場合や、Sun Fire T1000またはT2000システムで実行してUltraSPARC—T1 CPUに搭載された暗号プロセッサの利点を活用する場合は通常、PKCS #11インタフェースを初期化する必要があります。それには、まず証明書ストア用に使用するPINを選択します。そのためのコマンドは次のとおりです:
$ pktool setpin
このコマンドにより現在のパスフレーズの入力が求められます。Solaris OS暗号フレームワークをまだ使用していない場合、デフォルトのパスフレーズはchangemeです。次に新しいパスワードの入力が2回求められます。
ノート:
ユーザーごとに証明書セットが異なるため、ユーザーとしてログインするか、ディレクトリ・サーバーを実行するために使用されるロールとしてログインするときにこのステップを実行します。
この時点で、Java keytoolユーティリティを使用してPKCS #11を通してSolaris暗号フレームワークと対話することができます。これはJKSまたはPKCS#12キーストアでの操作とほとんど同じですが、次のような例外があります:
-
-keystore引数の値には、NONEを指定します。 -
-storetype引数の値には、PKCS11を指定します。 -
-keypass引数は使用できません。パスワードを省略しても、パスワードの入力は求められません。 -
-storepass引数の値には、pktool setpinコマンドを使用するときに選択したパスフレーズを指定します。もう1つの方法として、この引数をコマンド行に指定しない場合、これは要求されたときに入力すべきパスワードです。
たとえば、次のコマンドはPKCS #11インタフェースを使用して、Solaris暗号フレームワークを通して自己署名証明書を生成します:
$ keytool -genkeypair -alias server-cert -keyalg rsa \ -dname "CN=server.example.com,O=example.com,C=US" \ -keystore NONE -storetype PKCS11 $ keytool -selfcert -alias server-cert -validity 1825 \ -keystore NONE -storetype PKCS11
証明書がPKCS #11キーストアにインストールされたら、ディレクトリ・サーバーを構成してそのキーストアを使用する必要があります。JKSおよびPKCS#12キーストア・マネージャ・プロバイダのエントリと同じ方法でPKCS #11キーストア・プロバイダを構成します。このとき、key-store-file属性は指定しないでください。ただし、PINは必須なので、直接PINファイルに指定するか、Javaプロパティか環境変数を通して指定します。
次の例では、dsconfigを使用してPKCS #11キー・マネージャ・プロバイダを構成します:
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \ set-key-manager-provider-prop --provider-name "PKCS11" --set enabled:true \ --set enabled:true --set "key-store-type:PKCS11" \ --set "key-store-file:/config/keystore" \ --set "key-store-pin:secret"
構成可能なプロパティの完全なリストは、『Oracle Unified Directory構成リファレンス』のPKCS11キー・マネージャ・プロバイダの構成に関する項を参照してください。
26.2.5 ハードウェア・ベースのキー・マネージャ・プロバイダの概要
ハードウェア・ベース・タイプのキー・マネージャ・プロバイダを作成できます。ハードウェア・ベースのキー・マネージャ・プロバイダにより、サーバーは汎用のハードウェア・ベースのキー・ストアを介して秘密キー情報にアクセスできます。この標準インタフェースは、暗号アクセラレータおよびハードウェア・セキュリティ・モジュールによって使用されます。
暗号アクセラレータは、このインタフェースを使用して製品による暗号処理を外部ボード(または場合によっては、システムのCPU内部の特殊モジュールや、OSカーネル内部のフレームワーク)に任せることができるため、暗号処理を高速化できます。
ハードウェア・セキュリティ・モジュール(HSM)は、このインタフェースを使用して、キー情報を格納するための安全なリポジトリを提供します。これは重要なキー情報が漏えいする危険性を顕著に減らし、安全な通信メカニズムの全体的整合性の保護に役立ちます。
Oracle Unified Directoryでハードウェアベースのキー・マネージャ・プロバイダを使用するには、HSMと統合されるようOracle Unified Directoryで使用するJava仮想マシンを構成する必要があります。HSMが正しく構成されていることを確認するには、keytoolを使用してそのコンテンツを読み取ります。
キーストアへのアクセスに使用するPINを指定するには、Javaプロパティ、環境変数、PIN値またはクリア・テキストのPINを含むファイルへのパスのうち、いずれかを構成します。
次の例では、dsconfigを使用してハードウェア・ベースのキー・マネージャ・プロバイダを構成します。
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \ set-key-manager-provider-prop --provider-name "Hardware-Based" \ --set enabled:true --set "key-store-type:Hardware-Based" \ --set "key-store-file:/config/keystore" \ --set "key-store-pin:secret"
構成可能なプロパティの完全なリストは、『Oracle Unified Directory構成リファレンス』のハードウェア・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。
26.2.6 本番サーバーでの証明書の置換えについて
本番サーバーでは、証明書を置き換えるには、新しい証明書をリクエストする必要があります。SSLベースの接続ハンドラ(デフォルト名はLDAPS)のkey-manager-providerプロパティは、セキュリティに使用すべきキーストア・マネージャを指定します。
本番サーバーで証明書を置き換えるには、新しい証明書をリクエストして適切なキー・マネージャ・プロバイダを構成します。詳細は、「JKSキー・マネージャ・プロバイダの使用」、「PKCS #12キー・マネージャ・プロバイダの使用」または「PKCS #11キー・マネージャ・プロバイダの概要」を参照してください。
key-manager-providerプロパティのデフォルト値は"JKS"で、SSL接続ハンドラがデフォルトでJKSキー・マネージャ・プロバイダを使用することを意味します。別のキー・マネージャ・プロバイダを使用する場合は、SSL接続ハンドラのこのプロパティを適宜変更します。
新しい証明書をインストール後、サーバーを再起動する必要があります。
26.3 信頼マネージャ・プロバイダの構成
Oracle Unified Directoryは、信頼マネージャ・プロバイダを使用して提出された証明書を信頼するかどうかを決定します。信頼マネージャは、システム全体のセキュリティ上重要な役割を担っています。これはクライアントからのインバウンド接続や別のサーバーへのアウトバウンド接続の相手側システムが申告どおりの本人であることを保障します。
次の各トピックでは、信頼マネージャ・プロバイダに関する情報およびそれらの使用について説明します。
26.3.1 証明書信頼メカニズムの概要
信頼マネージャ・プロバイダは、偽造証明書を使用した攻撃や介入者攻撃を防ぐためにSSLやStartTLSを使用するときにセキュリティを向上させることができます。
信頼マネージャ・プロバイダの2つの主要な使用例を以下に示します:
-
インバウンド接続: SSLまたはStartTLSネゴシエーション・プロセス中にクライアントが自身の証明書をサーバーに提出します。これはSASL EXTERNAL認証で使用される可能性があります。
-
アウトバウンド接続: サーバーが外部のシステムとのSSLベースの接続を確立しようとします。たとえば、同期、プロキシ、または連鎖操作が目的です。
信頼マネージャは暗号強度に影響を与えません。このため、サーバーとそのピアだけが通信を理解できます。サードパーティのオブザーバーは通信を解読できません。信頼マネージャはピアが申告どおりに本人であることを保証し、機密情報が他人になりすましたピアに不注意に開示されないようにします。
信頼マネージャは、ピアの証明書が信頼できるものかどうか判断するために、いくつかの要因を検討します。この項では、このプロセスで検討される一般的ないくつかの基準について説明します。
最も単純な信頼メカニズムの1つは証明書の有効期限です。すべての証明書には、"notBefore"および"notAfter"タイムスタンプによって境界される有効期間を示す特定のウィンドウがあります。現在の時間が"notAfter"タイムスタンプを超えると、証明書が期限切れとなり、信頼マネージャによって拒否されます。同様に、現在の時間が"notBefore"タイムスタンプより前の場合にも証明書は拒否されます。通常、"notBefore"タイムスタンプは証明書が署名された時間に設定されますが、ただちに有効にならない証明書が発行されることがあります。そのような場合は、ピアからのアクセスが期限前に許可されないようにすることが重要です。
ピアの証明書を信頼するかどうか判断する際に非常に重要なもう1つの要因は、ピアの証明書チェーンです。あるシステムが別のシステムに証明書を提出する場合、提出するものは自身の証明書だけではなく、プロセスに関連するすべてのエンティティを記述する証明書チェーンを提出します。信頼マネージャがピアを信頼するかどうか判断する場合に、信頼マネージャはまず、トラスト・ストアを見てそこに通信相手の証明書が含まれているか確認します。証明書が見つかると、有効期限を過ぎているなど、他の理由がなければ、ピアは信頼されます。ピアの証明書が見つからない場合、信頼マネージャはピアの証明書に署名するために使用された、チェーン内の次の証明書(発行者証明書)を探します。トラスト・ストアに発行者の証明書が含まれる場合、サーバーはその発行者の証明書を信頼し、暗黙にそれが署名したすべての証明書を信頼します。このプロセスは、トラスト・ストア内で証明書の1つが見つかるか、チェーンのルートに達するまで(この場合、ルート証明書は自己署名であるためそれ自体の発行者です)証明書チェーンで継続されます(発行者の証明書に署名した証明書、等々)。ピアのチェーン内のどの証明書もトラスト・ストアに含まれない場合、ピアの証明書は拒否されます。
このプロセスにより、膨大な数の証明書が使用される環境(たとえば、膨大な数のサーバーを持つ環境や多数のクライアントがSASL EXTERNAL認証を使用する環境)の管理が大幅に簡素化されます。トラスト・ストアは個々のピアの証明書を持っている必要はありません。トラスト・ストアは、ピアの証明書チェーン内の証明書を1つだけ持つことができます。たとえば、サーバーに提出された正当なすべての証明書が同一発行者によって署名されている場合、トラスト・ストアにその発行者の証明書があれば、すべてのピアが暗黙に信頼されます。
環境によっては、ピアの証明書チェーンを信頼するかどうか判断するときに考慮すべきその他の要素があります。たとえば、無効になった証明書や有効期限内であり信頼された発行者によって署名されていても有効と見なすべきでないすべての証明書のリストを含む証明書失効リスト(CRL)があります。たとえば、これは証明書の持主である社員が退職したときや証明書の秘密キーが信用できなくなったときに利用できます。オンライン証明書ステータス・プロトコル(OCSP、RFC 2560 (http://www.ietf.org/rfc/rfc2560.txt)に記載)も類似したメカニズムを持ち、信頼マネージャは特定の証明書がまだ有効かどうかをOCSPサーバーに問い合せることがあります。Oracle Unified Directoryは現在、ピアの証明書チェーンが信頼できるものかどうか判断するときにCRLやOCSPの使用をサポートしていません。
管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様に、管理コネクタには信頼マネージャが必要です。Oracle Unified Directoryは、管理コネクタ専用の信頼マネージャを提供します。これはデフォルトで有効になっています。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
26.3.2 ブラインド信頼マネージャ・プロバイダについて
ブラインド信頼マネージャ・プロバイダは、提示されたすべての証明書を信頼する単純なプロバイダです。これは有効期限、証明書の署名者、件名、別名などの条件を確認しません。
Oracle Unified Directoryは、ブラインド信頼マネージャ・プロバイダを提供しますが、これはデフォルトで無効になっています。enabled属性の値をtrueに変更することにより、このプロバイダを有効にできます。ブラインド信頼マネージャ・プロバイダには、その他の構成属性は必要ありません。
ノート:
ブラインド信頼マネージャ・プロバイダは、プロキシ・サーバー・インスタンスではサポートされません。
次の例ではdsconfigを使用してブラインド信頼マネージャ・プロバイダを構成します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-trust-manager-provider-prop --provider-name "Blind Trust"
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のブラインド信頼マネージャ・プロバイダの構成に関する項を参照してください。
注意:
ブラインド信頼マネージャ・プロバイダは、テスト用にのみ提供されており、本番サーバー用ではありません。特にSASL EXTERNAL認証を許可するように構成されたサーバーでは使用しないでください。クライアントがSASL EXTERNALを使用して証明書を認証し、サーバーがクライアントによって提出されるすべての証明書を盲目的に受け入れてしまうと、ユーザーは自己署名証明書を作成して、ディレクトリ内のあらゆるユーザーになりすますことができます。
26.3.3 JKS信頼マネージャ・プロバイダの使用
JKSキーストアを使用してキー・マネージャ・プロバイダ用にキー情報を提供できるのと同様に、信頼マネージャ・プロバイダによって使用される情報を提供するために使用することもできます。通常、JKSファイルをトラスト・ストアとして使用するのは、それをキーストアとして使用するのと似ています。ただし、ファイルをトラスト・ストアとして使用するときには秘密キー情報にアクセスしないため、コンテンツにアクセスするときに通常はPINは必要ありません。
JKS信頼マネージャ・プロバイダが、ピアの証明書チェーンを信頼するかどうか判断するときに、2つの要因を検討します:
-
ピアの証明書が有効期限内かどうか。
-
チェーン内の証明書が1つ以上トラスト・ストアに含まれているかどうか。
ピアの証明書の有効期限が切れていたり、証明書チェーン内の証明書が1つもトラスト・ストアに含まれていない場合、JKS信頼マネージャによってピアの証明書が拒否されます。
keytool -importcertユーティリティを使用して、証明書をJKSトラスト・ストアにインポートします。-importcertオプションは以下の引数を使用します:
表26-5 -importcertのオプション
| 引数 | 説明 |
|---|---|
|
|
トラスト・ストア内の証明書に名前を指定します。証明書ごとに一意の名前を指定します。ニックネームは主にトラスト・ストア内の証明書の管理用であり、証明書が信頼されているかどうかに影響を与えません。 |
|
|
インポートする証明書を含むファイルへのパスを指定します。ファイルは、RFC 1421 ( |
|
|
信頼情報を含むファイルのパスを指定します。トラストストアに指定した場合、ディレクトリ・サーバーによって使用されるデフォルトの |
|
|
トラスト・ストア・ファイルの形式を指定します。JKS信頼マネージャの場合、これは |
|
|
トラスト・ストアのコンテンツを保護するために使用するパスワードを指定します。トラスト・ストア・ファイルがない場合、この値はトラスト・ストアに割り当てられるパスワードです。これ以降は、このパスワードを使用して、トラスト・ストアと対話する必要があります。このオプションを省略すると、パスワードはユーザーからインタラクティブに要求されます これはオプションのパラメータであり、コマンドライン履歴にクリア・テキスト・パスワードが記憶されるため、使用しないことをお薦めします。 |
ルートCA証明書をJKSトラスト・ストアにインポートするためのコマンドの例を次に示します。トラスト・ストアがない場合、このコマンドは証明書をインポートする前にトラスト・ストアを作成します。
$ keytool -importcert -alias rootca -file /tmp/rootca_cert.txt -keystore config/truststore.jks -storetype JKS
Oracle Unified Directoryには、JKS信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfigを使用してJKS信頼マネージャ・プロバイダの次のプロパティを構成します:
表26-6 JKS信頼マネージャ・プロバイダのプロパティ
| プロパティ | 説明 |
|---|---|
|
|
JKS信頼マネージャ・プロバイダが有効かどうかを示します。JKS信頼マネージャ・プロバイダは、このプロパティの値が |
|
|
トラスト・ストア・ファイルへのパスは通常、 |
|
|
トラスト・ストアの形式。JKSトラスト・ストア・プロバイダの場合、このプロパティの値は |
次の例では対話モードでdsconfigを使用して、JKS信頼マネージャ・プロバイダを構成します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-trust-manager-provider-prop --provider-name "JKS" \ --set enabled:true --set "trust-store-type:JKS" \ --set key-store-file:config/keystore
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。
26.3.4 PKCS #12信頼マネージャ・プロバイダの使用
PKCS #12信頼マネージャ・プロバイダは主に、PKCS #12ファイルで使用されるピアまたは発行者の証明書をすでに持っている場合に便利です。この形式の証明書を持っていない場合は、かわりにJKS信頼マネージャ・プロバイダを使用します。Java keytoolユーティリティは現在、信頼された(公開キーのみで秘密キーを持たない)証明書のPKCS #12ファイルへのインポートをサポートしていません。
Oracle Unified Directoryには、PKCS #12信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfigを使用してPKCS #12信頼マネージャ・プロバイダの次のプロパティを構成します:
表26-7 PKCS #12信頼マネージャ・プロバイダのプロパティ
| プロパティ | 説明 |
|---|---|
|
|
PKCS #12信頼マネージャ・プロバイダが有効かどうかを示します。信頼マネージャ・プロバイダは、このプロパティの値がtrueの場合を除き、他のサーバー・コンポーネントによって使用されることはありません |
|
|
トラスト・ストアの形式を指定します。PKCS #12信頼マネージャ・プロバイダの場合、値は |
|
|
トラスト・ストア・ファイルへのパスを指定します。これは通常、 |
PKCS #12ファイルのコンテンツにアクセスするにはPINが必要です。この場合、次の構成属性の1つを使用してパスワードを指定する必要があります。(現在、パスワードはクリア・テキストで指定する必要があります。)
表26-8 PKCS#12構成属性
| 属性 | 説明 |
|---|---|
|
|
トラスト・ストアに直接アクセスするために必要なPINを指定します |
|
|
トラスト・ストアにアクセスするために必要なPINを含むファイルへのパスを指定します。このプロパティの値は絶対パスかサーバー・ルートに対する相対パスです |
|
|
トラスト・ストアへのアクセスに必要なPINが格納されたJavaプロパティの名前を指定します |
|
|
トラスト・ストアへのアクセスに必要なPINが格納された環境変数の名前を指定します |
次の例では、対話モードでdsconfigを使用して、PKCS #12信頼マネージャ・プロバイダを構成します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-trust-manager-provider-prop --provider-name "PKCS12"
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。
26.4 証明書マッパーの構成
証明書マッパーは、クライアントによって提出された証明書を検査し、その証明書と関連づけられるディレクトリ内のユーザーにそれをマップします。証明書マッパーは、ディレクトリ・サーバー・インスタンスのみに構成されます。プロキシ・インスタンスやゲートウェイ・インスタンスには構成されません。
証明書マッパーは、主にSASL EXTERNAL認証を処理するために使用されます。クライアントはSASL EXTERNAL認証で、パスワードやその他の形式の資格証明より、SSL証明書を使用してサーバーの認証を受けようとします。
Oracle Unified Directoryはデフォルトで次の証明書マッパーを提供します。
ユーザーのデプロイ要件に合せて、カスタムの証明書マッパーを作成することもできます。
証明書マッパーは、グローバル・サーバー構成レベルかネットワーク・グループ・レベルかのいずれかで定義されます。証明書マッパーがネットワーク・グループで定義されると、それによってグローバル・サーバー構成で定義された証明書マッパーが置き換えられます。ネットワーク・グループで定義された証明書マッパーがない場合は、グローバル証明書マッパーが使用されます。使用すべき証明書マッパーを定義するには、グローバル構成またはネットワーク・グループのcertificate-mapperプロパティを設定します。
この項の例では、dsconfigコマンドを使用して証明書マッパーを変更します。dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
26.4.1 Subject Equals DN証明書マッパーの使用
Subject Equals DN証明書マッパーは、クライアント証明書のサブジェクトが対応するユーザー・エントリの識別名(DN)と同一であることを期待する単純な証明書マッパーです。この証明書マッパーの使用は、関連付けられた構成属性がないため簡単です。ただし、証明書のサブジェクトとユーザーDNは異なることが多いため、このマッパーはほとんどの環境に適していません。
サーバーはデフォルトでSubject Equals DN証明書マッパーを使用します。サーバーが使用する証明書マッパーを変更するには、dsconfigを使用して適切なグローバル構成プロパティを設定します。次のコマンドにより、サーバーが使用する証明書マッパーが、Subject Equals DNからサブジェクト属性からユーザーに置き換えられます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-global-configuration-prop \ --set certificate-mapper:"Subject Attribute to User Attribute"
グローバル・サーバー構成によって参照される場合、Subject Equals DN証明書マッパーは無効にできません。マッパーを無効にするには、前述のとおりデフォルトの証明書マッパーを変更する必要があります。
26.4.2 サブジェクト属性からユーザー属性証明書マッパーの使用
サブジェクト属性からユーザー属性証明書マッパーは、それらが共通に持つ属性セットに基づいてクライアント証明書をユーザー・エントリにマップします。具体的には、証明書サブジェクトから指定の属性セットの値を取得し、対応する属性セットに同一値を持つユーザー・エントリを検索します。
dsconfigを使用して、この証明書マッパーのプロパティを設定します:
-
subject-attribute-mapping。証明書サブジェクトからの属性をユーザー・エントリの属性にマップする複数値プロパティです。この属性の値は、証明書サブジェクトの中の属性名、コロン、ユーザーのエントリの中の対応する属性名で構成されます。たとえば、値e:mailは、証明書サブジェクトからのe属性をユーザー・エントリのmail属性にマップします。1つ以上の属性マッピングを定義する必要があります。デフォルトのマッピングは、e:mailとcn:cnです。 -
user-base-dn。ベースDNのセットを指定する複数値プロパティです。サーバーは、このDN下で一致するエントリを探します。この属性に値がないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。
次の例では、dsconfigを使用してサブジェクト属性からユーザー属性証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-certificate-mapper-prop \ --mapper-name "Subject Attribute to User Attribute" \ --set user-base-dn:ou=people,dc=example,dc=com
複数の属性マッピングが定義されていると、それらを組み合せてAND検索を実行します。たとえば、2つのマッピングcn:cnとe:mailが定義されていると、サブジェクトE=john.doe@example.com,CN=John Doe,O=Example Corp,C=USを持つ証明書がサーバーに提出されると、検索フィルタ(&(cn=John Doe)(mail=john.doe@example.com))が生成されます。マッピングが定義されていても証明書サブジェクトに含まれていない属性は、生成された検索フィルタには含まれません。生成された検索フィルタに使用できる属性はすべて、この証明書マッパーによって検索可能なすべてのリモートLDAPデータベース内の索引と対応している必要があります。
マッピングを成功させるには、生成された検索フィルタをディレクトリ(マッパーのベースDNの範囲内)の中の1人のユーザーと正確に一致させる必要があります。生成された条件と一致するユーザーがいないか、複数のユーザーが一致すると、マッピングは失敗します。
26.4.3 サブジェクトDNからユーザー属性への証明書マッパーの使用
サブジェクトDNからユーザー属性への証明書マッパーは、提出された証明書のサブジェクトをユーザー・エントリ内の指定された属性内で検索することによってマッピングを確立しようとします。この場合、ユーザー・エントリに、それらのユーザーと関連付けられた証明書のサブジェクトが移入されるようにする必要があります。ただし、このプロセスは、ユーザー・エントリに含まれるすべての証明書を自動的に識別し、それらの証明書のサブジェクトを別の属性に追加するプラグインによって将来自動化される可能性があります。
dsconfigを使用して、この証明書マッパーのプロパティを設定します:
-
subject-attribute。これは単一値属性で、値はユーザー・エントリ内に証明書サブジェクトを含む属性タイプの名前です。この属性はサーバー・スキーマ内で定義されます。これには、検索対象のすべてのバックエンド内で等価索引を設定する必要があります。サーバーによって受信された証明書のサブジェクトDNには、証明書がRDNコンポーネントによって作成された場合でも、それらのコンポーネントの間にスペースは含まれません。ユーザー・エントリ内の
subject-attributeの値でも、RDNコンポーネント間にスペースを含めないようにして、受信した証明書のサブジェクトDNと正確に一致させます。たとえば、元の証明書は次のような場合:keytool -printcert -file cert.002 Owner: CN=test, O=Test Certificate Issuer: CN=test, O=Test Certificate Serial number: 49b55976 Valid from: Mon Mar 09 19:01:26 MET 2009 until: Sat Mar 08 19:01:26 MET 2014 Certificate fingerprints: MD5: 5E:08:78:36:DF:25:F4:6C:43:9E:7B:CF:1F:1E:B9:6B SHA1: B7:B9:1C:A0:B0:52:C3:87:3C:C2:70:27:11:6F:5E:58:C5:33:9D:6B Signature algorithm name: SHA1withRSA Version: 3ユーザー・エントリのサブジェクト属性に定義されたサブジェクトDNは次のとおりです:
CN=test,O=Test Certificate
subject-attributeのRDNコンポーネント間のスペースを削除します。 -
user-base-dn。これはベースDNのセットを指定する複数値属性です。サーバーは、このDN下で一致するエントリを探します。この属性に値がないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。
次の例では、dsconfigを使用してサブジェクトDNからユーザー属性への証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-certificate-mapper-prop \ --mapper-name "Subject DN to User Attribute" \ --set user-base-dn:ou=people,dc=example,dc=com
ユーザーが持っている証明書のサブジェクトを保持する標準の属性はありませんが、この目的に使用できるカスタム属性タイプds-certificate-subject-dnを定義します。この属性は、ds-certificate-user補助オブジェクト・クラスとともにユーザー・エントリに追加できます。これは複数値属性です。ユーザーが複数の証明書を持つ場合、各証明書のサブジェクトが別個の値として属性に含まれる必要があります。
この属性には、デフォルトで索引が設定されません。このため、使用する場合は、対応するバックエンドを更新して、この属性の等価索引が含まれるようにします。
マッピングを成功させるには、証明書マッパーを(マッパーのベースDNの範囲内の)1人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。
26.4.4 サブジェクト代替名からユーザー属性への証明書マッパーの使用
ユーザー属性のサブジェクト代替名証明書マッパーは、指定された証明書のサブジェクト代替名拡張の下にあるプリンシパル名(または他の名前)をフェッチして、Oracle Unified Directoryと証明書とのマッピングを確立しようとします。ユーザー・エントリには、それらのユーザーと関連付けられた証明書のサブジェクト代替名拡張の下にあるプリンシパル名(または他の名前)が入力されるようにする必要があります。
dsconfigを使用して、この証明書マッパーのプロパティを設定します:
-
subject-alternative-name-attribute-mapping証明書サブジェクトからの属性をユーザー・エントリの代替属性にマップする複数値プロパティです。この属性の値は、証明書サブジェクトの中のプリンシパル名属性、コロン、ユーザーのエントリの中の対応する属性名で構成されます。たとえば、値
user.421はプリンシパル名にマッピングされ、OUDへの問合せはSANマッパーで定義されたマッピング構成に基づきます。たとえば、図26-1は、
subject-alternative-name-attribute-mapping値が1.3.6.1.4.1.311.20.2.3:cn(1.3.6.1.4.1.311.20.2.3= Principal Nameおよびcn =user.421)であるスマート・カード・ログイン・ユースケースでの、サブジェクト代替名からユーザー属性への証明書マッパーを含む証明書です。次の例では、属性マッピングはマッパーで次のように定義されています。
証明書拡張で、
subject-alternative-name-attribute-mapping値は1.3.6.1.4.1.311.20.2.3:cn@:ou(cn=EMPID123およびou=Orgainzation1)です -
user-base-dnこの証明書マッパーで使用されるベースDNのセットを指定する複数値プロパティです。
スマート・カード・ユーザーは、ログインまたは認証時に証明書をESSOに提出し、それがOracle Unified Directoryに渡されます。Oracle Unified Directoryは、この証明書を読み取り、サブジェクト代替名と呼ばれる証明書拡張のいずれかに存在するサブジェクトまたはユーザー詳細を取得する必要があります。サブジェクト代替名には、oidが1.3.6.1.4.1.311.20.2.3であり実際のサブジェクト詳細を保持するプリンシパル名属性があります。Oracle Unified Directoryによってこの値が読み取られ、認証が実行されます。
ノート:
複数の属性マッピングが定義されていると、それらを組み合せてAND検索を実行します。たとえば、2つのマッピングcn:cnとe:mailが定義されていると、サブジェクトE=john.doe@example.com,CN=John Doe, O=Example Corp,C=USを持つ証明書がサーバーに提出されると、検索フィルタ(&(cn=John Doe)(mail=john.doe@example.com)).が生成されますマッピングが定義されていても証明書サブジェクトに含まれていない属性は、生成された検索フィルタには含まれません。生成された検索フィルタに使用できる属性はすべて、この証明書マッパーによって検索可能なすべてのリモートLDAPデータベース内の索引と対応している必要があります。次のコマンドを使用して、サブジェクト代替名からユーザー属性への証明書マッパーを有効化できます。
-
set-certificate-mapper-propの使用:$ dsconfig set-certificate-mapper-prop \ --mapper-name "Subject Alternative Name To User Attribute" \ --set enabled:true -n -X -h localhost -p 1444 -D "cn=directory manager" -j pwdfile
-
set-global-configuration-propの使用:$ dsconfig set-global-configuration-prop \ --set certificate-mapper:"Subject Alternative Name To User Attribute" -n -X -h localhost -p 1444 -D "cn=directory manager" -j pwdfile
subject-alternative-name-attribute-mappingを含むスマート・カード・ログイン・ユースケースのコンテナ構造を次の例で説明します。
-
user-base-dn値dc=example、dc=comおよびsubject-alternative-name-attribute-mapping値が1.3.6.1.4.1.311.20.2.3:cn@:ou(ou=organization1およびcn=EMPID123):com,example, organization1, users, EMPID123 EMPID456 ...... -
user-base-dn値ou=users、dc=example、dc=comおよびsubject-alternative-name-attribute-mapping値が1.3.6.1.4.1.311.20.2.3:cn@:ou(ou=organization1およびcn=EMPID123):com, example, users, organization1, EMPID123 EMPID456 ......
user-base-dnを設定し、サーバーの検索範囲をdc=example,dc=comに限定することでサブジェクト代替名からユーザー属性への証明書マッパーを構成できます。 $ dsconfig set-certificate-mapper-prop \ --mapper-name "Subject Alternative Name To User Attribute" \ --set user-base-dn:dc=example,dc=com --hostname localhost --port 1444 --portProtocol LDAP --trustStorePath /<oud-instance>/OUD/config/admin-truststore --bindDN "cn=Directory Manager" --bindPasswordFile pwdfile --no-prompt
マッピングを成功させるには、生成された検索フィルタをディレクトリ(マッパーのベースDNの範囲内)の中の1人のユーザーと正確に一致させる必要があります。生成された条件と一致するユーザーがいないか、複数のユーザーが一致すると、マッピングは失敗します。
26.4.5 フィンガープリント証明書マッパーの使用
フィンガープリント証明書マッパーは、ユーザー・エントリ内の指定された属性で、提出された証明書のMD5またはSHA1フィンガープリントを検索することによってマッピングを確立しようとします。
ノート:
JDK 8では、無効化されたアルゴリズムのリストにMD5が追加されます。このJDKリリースでは、署名付きMD5 JARファイルが検証される方法について新しい制限が導入されました。署名付きJARファイルがMD5を使用している場合、署名検証操作ではその署名は無視され、JARは署名されていないものとして扱われます。この制限を元に戻すには、java.securityファイルのセキュリティ・プロパティjdk.jar.disabledAlgorithmsを更新して、無効化されたアルゴリズムのリストからMD5を削除する必要があります。java.securityファイルは、JAVA_HOME/jre/lib/security/java.securityにあります。
この場合、ユーザー・エントリに、証明書フィンガープリントが移入されるようにする必要があります。フィンガープリントは標準の16進表記で、各バイトはコロンで区切られます(たとえば、07:5A:AB:4B:E1:DD:E3:05:83:C0:FE:5F:A3:E8:1E:EB)。将来、このプロセスは、ユーザー・エントリに含まれるすべての証明書を自動的に識別し、それらの証明書のフィンガープリントを適切な属性に追加するプラグインによって自動化される可能性があります。
dsconfigを使用して、この証明書マッパーのプロパティを設定します:
-
fingerprint-attribute。単一値属性を指定します。その値は、ユーザー・エントリ内の証明書フィンガープリントを含む属性タイプの名前です。この属性はサーバー・スキーマ内で定義する必要があります。また、検索対象のすべてのバックエンド内で等価索引を設定する必要があります。 -
fingerprint-algorithm。証明書フィンガープリントを計算するために、そのダイジェスト・アルゴリズムを使用するのか指定します。値はMD5かSHA1のいずれかです。 -
user-base-dn。ベースDNのセットを指定する複数値属性を指定します。サーバーは、このDN下で一致するエントリを探します。このプロパティがないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。
次の例では、dsconfigを使用してフィンガープリント証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-certificate-mapper-prop \ --mapper-name "Fingerprint Mapper" \ --set user-base-dn:ou=people,dc=example,dc=com
証明書フィンガープリントを保持する標準の属性はありませんが、この目的に使用できるカスタム属性タイプds-certificate-fingerprintを定義します。この属性は、ds-certificate-user補助オブジェクト・クラスとともにユーザー・エントリに追加できます。これは複数値属性です。ユーザーが複数の証明書を持つ場合、各証明書のフィンガープリントが別個の値として属性に含まれる必要があります。ただし、どのサーバー・バックエンドでも、この属性タイプにはデフォルトで索引が設定されません。このため、使用する場合は、すべての対応するバックエンドに、この属性の等価索引を追加します。
マッピングを成功させるには、証明書マッパーを(マッパーのベースDNの範囲内の)1人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。
26.5 LDAPおよびJMX用のSSLおよびStartTLSの構成
1つ以上の有効なキー・マネージャ・プロバイダおよび1つ以上の有効な信頼マネージャ・プロバイダとともにOracle Unified Directoryを構成したときに、接続ハンドラにSSLおよびStartTLSを有効にできます。
この項の例では、dsconfigコマンドを使用してサーバー構成を変更します。dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。SSL証明書を信頼する方法を含めて、適切な接続オプションを指定する必要があります。これらの例では、-Xオプションを使用してすべての証明書を信頼します。
この項には次のトピックが含まれます:
26.5.1 LDAPおよびLDAPS接続ハンドラの構成
LDAP接続ハンドラは、LDAPを使用したクライアントとのすべての通信の管理に責任を持ちます。デフォルトでは、LDAPプロトコルは通信を保護するためのどのような形のセキュリティも指定しませんが、SSLを使用するか、TLS起動拡張操作の使用を許可するように構成できます。
サーバーは、このために使用できる2つの接続ハンドラを構成します。LDAP接続ハンドラ・エントリがデフォルトで有効にされており、暗号化されていないLDAP通信に使用される場合、StartTLSをサポートするように構成することもできます。詳細は、「StartTLSサポートの有効化」を参照してください。
LDAPS接続ハンドラ・エントリは無効になりますが、SSLベースの通信を有効にするデフォルト構成が設定されます。詳細は、「SSLベースの通信の有効化」を参照してください。
次の各トピックでは、dsconfigを使用してLDAPおよびLDAPS接続ハンドラ・パラメータを構成する方法について説明します。
26.5.1.1 接続ハンドラの有効化
接続ハンドラのenabledプロパティをtrueに設定します。
この例ではLDAP接続ハンドラを有効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler" \ --set enabled:true
26.5.1.2 接続ハンドラのリスニング・ポートの指定
接続ハンドラのlisten-portプロパティを設定します。
listen-portプロパティは、この接続ハンドラを通してサーバーと通信するときに使用するポート番号を指定します。
暗号化されていないLDAP通信(またはStartTLSを使用するLDAP)に使用する標準ポートは389で、SSL暗号化LDAP用の標準ポートは636です。ただし、環境によっては、これを変更した方がよい場合や変更する必要がある場合もあります(たとえば、標準ポートがすでに使用されていたり、1024以下のポートをブラインドできる十分な権限のないユーザーとしてUNIXシステムで実行する場合など)。
UNIX系システムでは、1024未満のポート番号は、権限付きユーザー(root)のみに制限されます。OUDインスタンス、OUD設定およびOUDインスタンスの実行に1024未満のポート番号を使用する場合は、権限付きユーザー(root)としてコマンドを実行する必要があります。したがって、一般ユーザーとして実行しているプロセスにこれらのポートを割り当てることはできません。このため、一般ユーザーとしてサーバーを実行する場合、1389 (デフォルトでLDAP接続に使用)などの権限付きポートを使用します。同様に、SSLベースの接続の一般ユーザーとして実行する場合は、デフォルトの1636ポートを使用できます。
この例ではLDAPS接続ハンドラのリスニング・ポートを1636に設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAPS Connection Handler" \ --set listen-port:1636
26.5.1.3 接続ハンドラの認可ポリシーの指定
接続ハンドラのssl-client-auth-policyプロパティを設定します。
ssl-client-auth-policyプロパティは、SSLまたはStartTLSネゴシエーション・プロセス中にクライアント証明書をリクエストするときの接続ハンドラの行動を指定します。値がoptionalの場合、サーバーはクライアントに自身の証明書の提出をリクエストしますが、クライアントが証明書を提出しない場合でも接続を許可します。値がrequiredの場合、サーバーはクライアントに自身の証明書の提出をリクエストし、クライアントがそれに応じないと接続をすべて拒否します。値がdisabledの場合、サーバーはクライアントに自身の証明書の提出をリクエストしません。
この例では、LDAPS接続ハンドラの認可ポリシーをrequiredに設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAPS Connection Handler" \ --set ssl-client-auth-policy:required
26.5.1.4 接続ハンドラの証明書へのニックネームの指定
接続ハンドラのssl-cert-nicknameプロパティを設定します。
ssl-cert-nicknameプロパティは、SSLまたはStartTLSネゴシエーション中にサーバーがクライアントに提出する証明書のニックネームを指定します。このプロパティは主に、複数の証明書がキーストアに存在し、リスナー・インスタンスにどの証明書を使用すべきか指定するときに便利です。
この例ではLDAP接続ハンドラの証明書のニックネームをserver-certに設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler" \ --set ssl-cert-nickname:server-cert
26.5.1.5 接続ハンドラのキー・マネージャ・プロバイダの指定
接続ハンドラのkey-manager-providerプロパティを設定します。
key-manager-providerプロパティは、使用可能な構成されたキー・マネージャ・プロバイダの中から、接続ハンドラがSSLまたはStartTLSネゴシエーションのためのキー情報を取得するために使用するキー・マネージャ・プロバイダを指定します。
この例ではこの例ではLDAP接続ハンドラのキー・マネージャ・プロバイダをJKSに設定します。コマンドを実行するには、指定されたキー・マネージャが構成済である必要があります。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler" \ --set key-manager-provider:JKS
26.5.1.6 接続ハンドラの信頼マネージャ・プロバイダの指定
接続ハンドラのtrust-manager-providerプロパティを設定します。
trust-manager-providerプロパティは、使用可能な構成された信頼マネージャ・プロバイダの中から、接続ハンドラが提出されたクライアント証明書を信頼すべきかどうか判断するために使用する信頼マネージャ・プロバイダを指定します。
この例ではLDAP接続ハンドラの信頼マネージャをJKSに設定します。コマンドを実行するには、指定されたキー・マネージャが構成済である必要があります。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler" \ --set trust-manager-provider:JKS
26.5.1.9 接続ハンドラでのプロトコル・バージョンおよび暗号スイートの指定
デフォルトでは、SSL/TLSベースの通信をサポートするOracle Unified Directory接続ハンドラは、システム・デフォルトのSSL/TLSプロトコルおよび暗号スイートをサポートします。システム・デフォルトのSSL/TLSプロトコルおよび暗号スイートをオーバーライドするように、対応する接続ハンドラのssl-protocolおよびssl-cipher-suiteプロパティを構成できます。
次の接続ハンドラによってssl-protocolおよびssl-cipher-suiteプロパティがサポートされています。
-
LDAPS
-
管理コネクタ
次の例では、LDAPS接続ハンドラについて、ssl-protocolをTLSv1.1に、ssl-cipher-suiteをTLS_DHE_RSA_WITH_AES_128_CBC_SHA256に設定できます。
$ dsconfig set-connection-handler-prop \ --handler-name LDAPS Connection Handler \ --set ssl-cipher-suite:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 \ --set ssl-protocol:TLSv1.1
26.5.2 JMX接続ハンドラについて
JMX接続ハンドラは、JMX (Java Management Extensions)プロトコルを使用してクライアントと通信できます。このプロトコルでは、StartTLSを使用して同一ポート上で暗号化通信と非暗号化通信の両方を許可できませんが、暗号化されないJMX通信、またはSSL暗号化JMX通信のいずれか一方を許可するように構成できます。
JMX接続ハンドラは、JMX上の通信のためのサーバーのデフォルト構成を提供します。この接続ハンドラでSSLを有効化するには、dsconfigを使用して次の構成属性を設定します:
表26-9 JMX接続ハンドラの属性
| 属性 | 説明 |
|---|---|
|
|
接続ハンドラがSSLネゴシエーションのためのキー情報を取得するために使用するキー・マネージャ・プロバイダの構成エントリのDNを指定します |
|
|
クライアントに提出される証明書のニックネーム(または別名)を指定します |
|
|
接続ハンドラがSSLを使用してクライアントと通信するかどうかを示します。 |
次の例では対話モードでdsconfigを使用してJMX接続ハンドラを構成します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-connection-handler-prop --handler-name "JMX Connection Handler"
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のJMX接続ハンドラの構成に関する項を参照してください。
26.6 レプリケーションのための暗号化マネージャでのSSLプロトコルおよび暗号スイートの構成
デフォルトでは、Oracle Unified Directoryサーバー・インスタンス間のレプリケーションでは、暗号化マネージャによって容易になったSSLベースの通信を使用します。Oracle Unified Directoryでは、レプリケーションのためのSSL/TLS通信が容易になるように、システム・デフォルトのプロトコルおよび暗号スイートをサポートしています。
サポートされているシステム・デフォルトのTLSプロトコルおよび暗号スイートのリストは、「Oracle Unified Directoryがサポートしているシステム・デフォルトのTLSプロトコル」を参照してください。この動作は、暗号化マネージャのssl-protocolおよびssl-cipher-suiteプロパティを構成することでオーバーライドできます。暗号化マネージャの構成可能なプロパティのリストを表示するには、『Oracle Unified Directory構成リファレンス』の暗号化マネージャに関する項を参照してください。
次の例では、暗号化マネージャのssl-protocolをTLSv1.1に、ssl-cipher-suiteをTLS_DHE_RSA_WITH_AES_128_CBC_SHA256に設定できます。
$ dsconfig set-crypto-manager-prop \ --set ssl-cipher-suite:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 \ --set ssl-protocol:TLSv1.1
26.7 TLS通信のシステム・デフォルトのプロトコルおよび暗号スイートのオーバーライド
ldapsearch (他のldapツールを含む)、dsconfig、dsreplication、ds2oudなどのCLIツールでは、システム・デフォルトのプロトコルおよび暗号スイートがOracle Unified DirectoryサーバーとのTLS通信に使用されます。
これで、ldapsearchなどの任意のCLIツールを実行したとき、OUDサーバーとのTLS通信中に、この構成が使用されるようになります。次のサンプルを参照してください。
tls_protocols=TLSv1.1,TLSv1
cipher_suite_sequence=TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA
OUDインスタンスの外部のCLIコマンドの場合、またはJava引数をINSTANCE_DIR/OUD/config/java.propertiesを使用して構成できないコマンドの場合、対応するCLIスクリプトを編集し、TLS構成ファイルの絶対位置を指定するcustom.config.location javaシステム・プロパティを追加する必要があります。
たとえば、-Dcustom.config.location=/scratch/tlsconfig.properties
特定のプロトコルおよび暗号スイートを使用するようにoud-replication-gateway-setup/oud-replication-gateway-setup.batツールを構成するには、スクリプトを編集してシステム・プロパティを追加する必要があります。次に示すコマンドに従います。
"${OPENDS_JAVA_BIN}" -client -Dcustom.config.location=/scratch/tlsconfig.properties ${SCRIPT_NAME_ARG} com.sun.gateway.server.tools.setup.ReplicationGatewaySetupLauncher "${@}".batファイルの場合:
"%OPENDS_JAVA_BIN%" -client -Dcustom.config.location=/scratch/tlsconfig.properties %SCRIPT_NAME_ARG% com.sun.gateway.server.tools.setup.ReplicationGatewaySetupLauncher %*26.8 SASL認証の使用
LDAPプロトコル定義には、クライアントがサーバーの認証を受けるための2つの方法、つまりLDAP簡易認証とSASL認証が提供されています。
ノート:
SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。
LDAP簡易認証では、クライアントはユーザーのDNおよびパスワードを指定します。これは最も一般的な認証メカニズムであり、通常は最も使用法が簡単です。ただし、次のようないくつかの制約があります:
-
ユーザーは常に完全なDNを指定する必要があります。ユーザー名のようなユーザー・フレンドリなものに置き換えられません。
-
パスワード・ベースの認証のみ許可されます。
-
クライアントは完全なクリアテキスト・パスワードをサーバーに提供する必要があります。
これらの問題を解決するために、SASL (Simple Authentication and Security Layer)を使用してクライアントと通信することもできます(SASLの定義はRFC 4422 http://www.ietf.org/rfc/rfc4422.txtを参照)。これは非常に広範なフレームワークであり、サーバーに多数の認証方法のサポートを可能にします。
SASLオプションについては、次の各項で説明します。
26.8.1 サポートされているSASLメカニズムについて
SASLメカニズムは拡張性が高く、認証を実行するためにクライアントがサーバーに提供する必要がある情報はメカニズムごとに異なります。
次のSASLメカニズムがサポートされます。
ノート:
プロキシ・サーバーで現在サポートされている唯一のSASLメカニズムはANONYMOUSです。
その他のサポートされるSASLメカニズムは次のとおりです。
-
ANONYMOUS
このメカニズムは実際にはクライアントを認証しませんが、デバッグ用のサーバー・ログにトレース情報を含めるメカニズムを提供します。
-
CRAM-MD5
このメカニズムは後方互換背のために提供されています。本番環境では、CRAM-MD5を構成しないでください。かわりに、より安全なDIGEST-MD5メカニズムを使用します。
-
DIGEST-MD5
このメカニズムにより、クライアントはサーバーにパスワードを送信せずにパスワードベースの認証を使用できます。そのかわりに、クライアントは単にパスワードを知っているという情報を提供するだけです。このメカニズムはCRAM-MD5より多くのオプションとセキュリティを提供します。
-
EXTERNAL
このメカニズムにより、クライアントはLDAP通信の直接のフローの外部で提供される情報に基づき自身を識別できます。Oracle Unified Directoryでは、これはSSLクライアント証明書を使用して可能です。
-
GSSAPI
このメカニズムにより、クライアントはKerberos V5環境への参加を通してサーバーから認証を受けることができます。
-
PLAIN
追加のSASLメカニズムのサポートは、サーバーにカスタムのSASLメカニズム・ハンドラを実装することにより追加できます。
SASLメカニズムは非常に拡張性が高いため、認証を実行するためにクライアントがサーバーに提供する必要がある情報はメカニズムごとに異なります。そのため、Oracle Unified Directoryクライアントはユーザー用の汎用インタフェースを使用してこの情報を提供します。これは、-oまたは--saslOption引数を通して公開されます。この引数の値は、名前と値のペアである必要があります。mechオプションを使用して、使用するSASLメカニズムを選択します。たとえば:
--saslOption mech=DIGEST-MD5
使用可能なその他のオプションは、選択されたSASLメカニズムによって異なります。これについては以下の項で説明します。
26.8.2 認可IDについて
以下の多数のSASLメカニズムは、ユーザーDNでなく、認可IDに基づいてユーザーを識別できる機能を提供します。
認可IDは次のいずれかの形式で指定します:
-
dn:dn
これには、認証のためにユーザーの完全なDNを指定します(たとえば、dn:uid=john.doe,ou=People,dc=example,dc=com)。dn:の値にDNが指定されないと、匿名ユーザーとして取り扱われます。この形式は以下に示す多数のSASLメカニズムによって拒否されます。
-
u:username
これには完全なDNでなく、ユーザーのユーザー名を指定します(たとえば、u:john.doe)。
u:username形式を使用した場合、そのユーザー名を対応するユーザー・エントリに変換するためにサーバーによって使用されるメカニズムは、サーバー内のIDマッピング構成に基づきます。
26.8.3 ANONYMOUSメカニズムのSASLオプションについて
ANONYMOUSメカニズムは、実際には認証の実行には使用されず、これに追加の必須オプションはありません。
ただし、次のオプションを指定できます:
trace
サーバーのアクセス・ログに書き込まれるトレース文字列を指定するために使用します。これはデバッグやクライアントの識別に便利です。ただし、認証せずにこの値の妥当性を信頼することはできません。
次のコマンドはSASL匿名認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=ANONYMOUS \ --saslOption "trace=Example Trace String" --baseDN "" \ --searchScope base "(objectClass=*)"
26.8.4 CRAM-MD5メカニズムのSASLオプションについて
CRAM-MD5メカニズムにより、サーバーにクリアテキスト・パスワードを送信せずにパスワードベースの認証を実行できます。クリアテキスト・パスワードとサーバーによって提供されるランダム生成されたデータを組み合せたMD5ダイジェストを提供することによって認証が実行されます。これはリプレーアタックの防止に役立ちます。
SASL CRAM-MD5メカニズムには、指定する必要がある1つのSASLオプションがあります:
authid
これはサーバーの認証を受けるユーザーのIDを指定します。これは前述の認可IDの値です。
パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL CRAM-MD5認証の使用例を示します:
ldapsearch --hostname server.example.com --port 1389 --saslOption mech=CRAM-MD5 \ --saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"
26.8.5 DIGEST-MD5メカニズムのSASLオプションについて
DIGEST-MD5メカニズムはCRAM-MD5メカニズムと類似していますが、クライアントとサーバーの両方からのランダムなデータを組み合せるため、安全性が増し、リプレイ・アタックや介入者攻撃の両方に有効です。
DIGEST-MD5認証は次のようなSASLオプションも提供します。
authid
サーバーの認証を受けるユーザーのIDを指定します。このオプションは必須です。
realm
このオプションはDNとして指定しないでください。
ノート:
realmオプションは使用しないでください。これはサーバーがIDをマッピングするときに使用されません。
digest-uri
クライアントがサーバーとの通信に使用するダイジェストURIを指定します。これはオプションのパラメータです。指定する場合は、ldap/serveraddress形式を使用します。serveraddressは完全修飾のサーバー・アドレスです。
ノート:
本番環境ではdigest-uriオプションを使用しないでください。
authzid
認証プロセス中に使用される認可IDを指定します。このオプションは、認証後の接続でリクエストされた操作が別のユーザーの認可の元で実行されることを示すために使用できます。
パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL DIGEST-MD5認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=DIGEST-MD5 \ --saslOption authid=u:john.doe --saslOption realm=dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)"
26.8.6 EXTERNALメカニズムのSASLオプションについて
EXTERNALメカニズムを使用して、LDAPセッションの外部にあるサーバーが使用できる情報に基づいて認証を実行します。現在、これはSSLクライアント認証によってのみ使用可能です。この場合、クライアントのSSL証明書がクライアントの認証に使用されます。そのため、サーバーと通信するときにはSSLまたはStartTLSを使用し、クライアント証明書キーストアが使用できる必要があります。
EXTERNALメカニズムは追加のSASLオプションをサポートしません。通常は、--saslOption mech=EXTERNALまたは--useSASLExternalのいずれかを使用してリクエストできます。次のコマンドは、SASL EXTERNAL認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1636 --useSSL \ --keyStorePath /path/to/key.store --keyStorePasswordFile /path/to/key.store.pin \ --trustStorePath /path/to/trust.store --saslOption mech=EXTERNAL --baseDN "" \ --searchScope base "(objectClass=*)"
詳細は、SASL External認証の構成を参照してください。
26.8.7 GSSAPIメカニズムのSASLオプションについて
GSSAPIメカニズムは、Kerberos V5環境で認証を実行するために使用され、クライアント・システムを構成して、このような環境に参加させます。
GSSAPIメカニズムで使用できるオプションは次のとおりです:
-
authidユーザーを識別するために使用される認証IDを指定します。IDは、前述の認可IDの形式でなく、Kerberosプリンシパルの形式で指定する必要があります。バインドを試みる前に、ユーザーがKerberos認証を使用しない場合は、このオプションを指定する必要があります。
-
authzid
認可処理の実行対象となるユーザーを識別するための認可IDを指定します。この機能はまだサポートされていません
-
quality-of-protection通信に使用する保護の質を指定します。現在クライアントによってサポートされるquality-of-protectionの値は
authのみです。サーバーによってサポートされる値は、auth-intとauth-confです。
ユーザーがGSSAPIの使用を試みるときに、システム上にすでに有効なKerberosチケットを持っている場合、クライアントがそれを使用するとパスワードが不要になります。ただし、ユーザーが有効なKerberosチケットを持っていないか、チケットが受け入れられない場合は、--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用してパスワードを指定する必要があります。
次のコマンドは、すでに有効なKerberosセッションを持つユーザーに対するSASL GSSAPI認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=GSSAPI \ --saslOption authid=jdoe@EXAMPLE.COM --baseDN "" --searchScope base "(objectClass=*)"
26.8.8 PLAINメカニズムのSASLオプションについて
PLAINメカニズムは、LDAP簡易認証と同一の機能を多数提供しますが、ユーザーは通常、完全DNでなく認可IDの形式で識別されます。
SASL PLAIN認証を使用するときに、次のオプションを使用できます:
-
authid
サーバーの認証を受けるユーザーのIDを指定します。これは前述の認可IDの値です。このオプションは必須です。
-
authzid
認可処理の実行対象となるユーザーのIDを指定します。認可IDの形式で指定する必要があります。この機能はまだサポートされていません。
パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL PLAIN認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=PLAIN \ --saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"
26.8.9 DIGEST-MD5 SASLメカニズムについて
DIGEST-MD5 SASLメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。
DIGEST-MD5パスワードではクリアテキスト・パスワードは公開されないため、クライアントとサーバーの間の通信がセキュアでない場合に、簡易認証またはPLAIN SASLメカニズムよりも大幅に安全です。
RFC 2831 (http://www.ietf.org/rfc/rfc2831.txt)にDIGEST-MD5 SASLメカニズムについて記載されていますが、改訂された仕様はdraft-ietf-sasl-rfc2831bisに記載されています。このプロセスは、次のとおりです。
-
クライアントは、メカニズム名が
DIGEST-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・プロトコルopタイプを含むメッセージをサーバーへ送信します。 -
サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(nonce)、その他のものを含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。
-
クライアントはサーバーから送信されたnonce、クライアント自体がランダムに生成したデータ(cnonce)、認証ID、オプション認可ID、ユーザーのクリアテキスト・パスワードおよびその他の情報を取得し、それを使用してMD5ダイジェストを作成します。次にクライアントは、そのダイジェストおよびその他のクリアテキスト情報を含む2番目のバインド・リクエスト・メッセージをサーバーに返信します。
-
サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常
successまたはinvalid credentialsの結果とともに)クライアントに送信します。 -
完全性または機密性、あるいはその両方で接続を保護する必要があることを示す保護品質(QoP)の値をクライアントが要求した場合は、サーバーはクライアントとの必要なネゴシエーションを開始します。現在、ディレクトリ・サーバーでは、完全性または機密性保護を使用するDIGEST-MD5メカニズムの使用をサポートしていません。
DIGEST-MD5 SASLメカニズムはCRAM-MD5 SASLメカニズムとよく似ていますが、CRAM-MD5がサーバーからのランダム・データのみを含めるのに対して、DIGEST-MD5はクライアントとサーバーの両方からであるため、多少厳格です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。
26.9 SASL認証の構成
多様なSASL認証メカニズムを使用するようにディレクトリ・サーバーを構成できます。
SASL認証メカニズムの一部を次に示します。
ノート:
SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。
26.9.1 SASL EXTERNAL認証の構成
SASL EXTERNALメカニズムは、厳密なLDAP通信の外部で提供される情報を使用して、クライアントがサーバーに認証してもらうために使用できます。現在、LDAP通信にかぎり、SSLまたはStartTLSネゴシエーション中にサーバーに提示されたクライアント証明書を使用する認証がサポートされます。
次の各項では、SASL認証について説明します。
26.9.1.1 SASL EXTERNAL認証を可能にするためのLDAP接続ハンドラの構成
ディレクト・サーバーがクライアント証明書をユーザー・エントリにマッピングするには、クライアント証明書を処理できるように接続ハンドラを構成する必要があります。dsconfigを使用して次のLDAP接続ハンドラのプロパティを構成します:
-
ssl-client-auth-policy。SSLまたはStartTLSネゴシエーション・プロセス中にクライアント証明書の提出をクライアントに要求するかどうかを指定します。SASL EXTERNAL認証をサポートするには、
optionalかrequiredか、どちらかの値を指定します。値がdisabledの場合、クライアントは証明書の提出を求められず、認証に使用できる証明書はありません。 -
trust-manager-provider。ディレクトリ・サーバーがクライアント証明書の妥当性を信頼するかどうか判断するために使用される信頼マネージャ・プロバイダのDNを指定します。サーバーがクライアント証明書を信頼しない場合、SSLまたはStartTLSネゴシエーションは失敗し、クライアントはSASL EXTERNAL認証をリクエストできません。サーバーが正当でないクライアント証明書を信頼した場合、悪意のあるユーザーは証明書を偽造してディレクトリ内の任意のユーザーになりすますことができます。通常は、JKSまたはPKCS12信頼マネージャ・プロバイダを使用し、対応するトラスト・ストアはクライアント証明書の署名に使用される発行者証明書のみを使用してロードされる必要があります。
ノート:
dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。SSL証明書を信頼する方法を含めて、適切な接続オプションを指定する必要があります。これらの例では、-Xオプションを使用してすべての証明書を信頼します。
次の例では、対話モードでdsconfigを使用してLDAP接続ハンドラのプロパティを設定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-j pwd-file -X \ set-connection-handler-prop --handler-name "LDAP Connection Handler"
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のLDAP接続ハンドラの構成に関する項を参照してください。
26.9.1.2 EXTERNAL SASLメカニズム・ハンドラの構成
SASL EXTERNALバインド・リクエストは、SASLメカニズム・ハンドラによって処理されます。dsconfigコマンドを使用して、次のSASLメカニズム・ハンドラのプロパティを設定します:
-
java-class。SASLメカニズム・ハンドラのロジックを提供するJavaクラスの完全修飾名を指定します。EXTERNALメカニズムの場合、この値は常に
org.opends.server.extensions.ExternalSASLMechanismHandlerです。拡張プロパティ。 -
enabled。EXTERNAL SASLメカニズムが有効で、使用できるかどうかを示します。クライアントにSASL EXTERNAL認証の使用を許可しない場合は、値を
falseに変更します。 -
certificate-mapper。クライアント証明書とユーザー・エントリのマッピングに使用される証明書マッパーの構成エントリのDNを指定します。
-
certificate-validation-policy。マッピングの確立後に、ディレクトリ・サーバーがユーザーのエントリ内でクライアント証明書を探すかどうかを指定します。値が
alwaysの場合、マッピングされたユーザーのエントリにクライアントが提出した証明書が含まれているときにのみ認証が成功します。値がifpresent(デフォルト値)で、ユーザーのエントリに1つ以上の証明書が含まれている場合、それらの証明書の1つがクライアントによって提出された証明書と一致するときにのみ認証が成功します。値がifpresentで、ユーザーのエントリに証明書が含まれていない場合でも、信頼マネージャによって受け入れられ、証明書マッパーによってマッピングされる場合は認証が成功します。値がneverの場合、ユーザーのエントリに1つ以上の証明書が含まれる場合でも、サーバーはユーザーのエントリ内で一致する証明書を探しません。 -
certificate-attribute。
certificate-validation-policyプロパティにalwaysまたはifpresentの値が含まれる場合に、調べられるユーザー証明書を持つ属性の名前を指定します。
次の例では、対話モードでdsconfigを使用してEXTERNAL SASLメカニズム・ハンドラのプロパティを設定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-j pwd-file -X \ set-sasl-mechanism-handler-prop --handler-name "EXTERNAL"
構成可能なプロパティのリストは、『Oracle Unified Directory構成リファレンス』のSASLメカニズム・ハンドラの構成に関する項を参照してください。
26.9.2 SASL DIGEST-MD5認証の構成
ユーザーに対するアクセス制御および権限の制約は、認可IDキーワード(authzid)を使用して実行できます。ユーザーがauthzidキーワードを使用しない場合は、これらの制約は適用されません。DIGEST-MD5およびauthzidキーワードを使用してバインドするユーザーは、次の要件を満たす必要があります:
-
認証ID (
authid) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。 -
認証ID (
authid)エントリには、proxied-auth権限を含める必要があります。次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。
次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。
26.9.3 SASL GSSAPI認証の構成
ユーザーに対するアクセス制御および権限の制約は、認可IDキーワード(authzid)を使用して実行します。ユーザーがauthzidキーワードを使用しない場合は、制約は適用されません。
GSSAPIを使用してバインドを実行するユーザーは、次の要件を満たす必要があります:
-
認証ID (
authid) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。 -
認証ID (
authid)エントリには、proxied-auth権限を含める必要があります。
次の例では3つのサンプル・エントリを含むテスト環境を作成し、GSSAPI SASLメカニズムを使用したユーザー認証の要件を示します。これらの例では、有効なキータブ・ファイルを含めて完全に構成されたKerberos環境が必要です。
26.10 GSSAPI SASL認証のためのKerberosおよびOracle Unified Directoryサーバーの構成
GSSAPI SASL認証のためにKerberos Version 5を構成できます。
次の各項では、KerberosおよびOracle Unified Directoryの構成について説明します。
26.10.1 ホスト上でのKerberos V5の構成
LDAPクライアントを実行するホスト・マシンでKerberos V5を構成できます。
ホスト上でKerberos V5を構成するには、次のステップを実行します。
26.10.2 Kerberos認証のSASLオプションの指定
Kerberosのインストール時に適切なSASLオプションを指定できます。
Kerberosのインストールの場合、次のステップを実行します。
26.10.3 GSSAPIとSASLを使用したKerberos認証の構成
Oracle Unified Directoryディレクトリ・サーバー用のKerberosの構成は複雑な場合があります。最初にKerberosのマニュアルを参照してください。
さらに詳細について知りたい場合は、次に示す例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合せて手順を変更してください。
Solaris OSでのKerberosの構成と使用の詳細は、システム管理ガイド: セキュリティ・サービスを参照してください。このマニュアルはSolarisマニュアル・セットの一部です。マニュアル・ページを参照することもできます。
この例についての情報と使用するステップは、次のとおりです:
26.10.3.1 この例の前提
この手順例では、1台目のマシンをKDC (Key Distribution Center)として操作し、2台目のマシンではディレクトリ・サーバーを実行できるように構成する処理について説明します。この手順の結果として、ユーザーはGSSAPIによってKerberos認証を実行できるようになります。
同じマシン上でKDCとディレクトリ・サーバーの両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDCマシンとディレクトリ・サーバー・マシンで重複するステップは、一度行うのみですみます。
この手順では、使用される環境に関する前提条件がいくつかあります。手順例を使用する場合は、環境に合せて値を変更してください。前提条件は次のとおりです:
-
このシステムには、推奨される最新のパッチ・クラスタのインストールされた最新のSolaris 10ソフトウェアがインストールされています。適切なSolarisパッチがインストールされていない場合、ディレクトリ・サーバーに対するKerberos認証は失敗する可能性があります。
-
Kerberosデーモンを実行するマシンは、
kdc.example.comという完全修飾ドメイン名を持ちます。このマシンは、ネーミング・サービスにDNSを使用するように構成する必要があります。この構成は、Kerberosの必要条件です。fileなど、他のネーミング・サービスをかわりに使用すると、特定の操作が失敗することもあります。 -
ディレクトリ・サーバーを実行するマシンは、
directory.example.comという完全修飾ドメイン名を持ちます。このマシンも、ネーミング・サービスにDNSを使用するように構成する必要があります。 -
Directory Serverマシンは、Kerberosによってディレクトリ・サーバーに対する認証を行うためのクライアント・システムとして機能します。この認証は、ディレクトリ・サーバーとKerberosデーモンの両方と通信できる任意のシステムから実行できます。しかし、この例で必要なコンポーネントはすべて、Oracle Unified Directoryディレクトリ・サーバーによって提供され、認証はこのシステムから実行されます。
-
ディレクトリ・サーバー内のユーザーは、
uid=username,ou=People,dc=example,dc=comの形式のDNを持ちます。対応するKerberosプリンシパルは、username@EXAMPLE.COMです。別のネーミング・スキームを使用する場合は、別のGSSAPIアイデンティティ・マッピングを使用する必要があります。
26.10.3.2 Kerberosクライアント構成ファイルの編集(すべてのマシン)
/etc/krb5/krb5.conf構成ファイルは、KDCと通信するためにKerberosクライアントが必要とする情報を提供しています。
Kerberosを使用してディレクトリ・サーバーに対する認証を行うKDCマシン、ディレクトリ・サーバー・マシンおよび任意のクライアント・マシン上の/etc/krb5/krb5.conf構成ファイルを編集します。
-
"___default_realm___"をすべて"EXAMPLE.COM"に置き換えます。 -
"___master_kdc___"をすべて"kdc.example.com"に置き換えます。 -
"___slave_kdcs___"の含まれる行を削除して、Kerberosサーバーが1つしか存在しないようにします。 -
"___domain_mapping___"を".example.com = EXAMPLE.COM"に置き換えます(example.comの最初のピリオドに注意)。
更新された/etc/krb5/krb5.conf構成ファイルは次の例のコンテンツと類似しています。
26.10.3.2.1 編集後のKerberosクライアント構成ファイル/etc/krb5/krb5.conf
#pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
gkadmin = {
help_url =
http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
}
26.10.3.3 管理サーバーACL構成ファイルの編集(すべてのマシン)
/etc/krb5/kadm5.acl構成ファイル内の"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。
編集後の管理サーバーACL構成ファイル
# # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # # pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" */admin@EXAMPLE.COM *
26.10.3.4 KDCサーバー構成ファイルの編集(KDCマシン)
/etc/krb5/kdc.confファイルを編集して、"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。
編集後のKDCサーバー構成ファイル/etc/krb5/kdc.conf
# Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)kdc.conf 1.2 02/02/14 SMI"
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
}
26.10.3.5 KDCデータベースの作成(KDCマシン)
$/usr/sbin/kdb5_util create -r EXAMPLE.COM -sInitializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key:passwordRe-enter KDC database master key to verify:password$
26.10.3.6 管理プリンシパルとキータブの作成(KDCマシン)
次のコマンドを使用して、kws/admin@EXAMPLE.COMというプリンシパルの管理ユーザーと、管理デーモンによって使用されるサービス・キーを作成します。
$/usr/sbin/kadmin.localkadmin.local:add_principal kws/adminEnter password for principal "kws/admin@EXAMPLE.COM":secretRe-enter password for principal "kws/admin@EXAMPLE.COM":secretPrincipal "kws/admin@EXAMPLE.COM" created. kadmin.local:ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.comEntry for principal kadmin/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.comEntry for principal changepw/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:ktadd -k /etc/krb5/kadm5.keytab kadmin/changepwEntry for principal kadmin/changepw with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:quit$
26.10.3.7 Kerberosデーモンの開始(KDCマシン)
KerberosデーモンはSMF (Service Management Facility)フレームワークによって管理されます。次のコマンドを実行して、KDCおよび管理デーモンを開始します:
$/etc/init.d/kdc start$/etc/init.d/kdc.master start$ $svcadm disable network/security/krb5kdc$svcadm enable network/security/krb5kdc$svcadm disable network/security/kadmin$svcadm enable network/security/kadmin$
KDCプロセスは、/usr/lib/krb5/krb5kdcとプロセス・リストに表示されます。管理デーモンは、/usr/lib/krb5/kadmindと表示されます。
26.10.3.8 KDCマシンとOracle Unified Directoryマシンに対するホスト・プリンシパルの追加(KDCマシン)
KDCのKerberosデータベースとディレクトリ・サーバー・マシンにホスト・プリンシパルを追加するには、次の一連のコマンドを使用します。ホスト・プリンシパルは、klistなどの特定のKerberosユーティリティによって使用されます。
$ /usr/sbin/kadmin -p kws/adminEnter Password:secretkadmin:add_principal -randkey host/kdc.example.comPrincipal "host/kdc.example.com@EXAMPLE.COM" created. kadmin:ktadd host/kdc.example.comEntry for principal host/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin:add_principal -randkey host/directory.example.comPrincipal "host/directory.example.com@EXAMPLE.COM" created. kadmin:ktadd host/directory.example.comEntry for principal host/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin:quit$
26.10.3.9 ディレクトリ・サーバーに対するLDAPプリンシパルの追加(KDCマシン)
ディレクトリ・サーバーで認証中のユーザーが保持するKerberosチケットを検証できるようにするには、ディレクトリ・サーバーディレクトリ・サーバーが独自のプリンシパルを保持する必要があります。現在Oracle Unified Directoryは、ldap/fqdn@realmのプリンシパルを要求するためにハードコーディングされています。ここで、fqdnはディレクトリ・サーバーの完全修飾ドメイン名で、realmはKerberosレルムです。fqdnは、Oracle Unified Directoryのインストール時に指定された完全修飾名と一致する必要があります。この場合、ディレクトリ・サーバーのプリンシパルは、ldap/directory.example.com@EXAMPLE.COMとなります。
次のコマンド・シーケンスを使用して、ディレクトリ・サーバーのLDAPプリンシパルを作成します:
$/usr/sbin/kadmin -p kws/adminEnter Password:secretkadmin:add_principal -randkey ldap/directory.example.comPrincipal "ldap/directory.example.com@EXAMPLE.COM" created. kadmin:quit$
26.10.3.10 KDCへのテスト・ユーザーの追加(KDCマシン)
Kerberos認証を実行するには、Kerberosデータベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名をkerberos-testにします。つまりKerberosプリンシパルがkerberos-test@EXAMPLE.COMになります。
この例の一連のコマンドを使用してユーザーを作成します:
$/usr/sbin/kadmin -p kws/adminEnter Password:secretkadmin:add_principal kerberos-testEnter password for principal "kerberos-test@EXAMPLE.COM":secretRe-enter password for principal "kerberos-test@EXAMPLE.COM":secretPrincipal "kerberos-test@EXAMPLE.COM" created. kadmin:quit$
26.10.3.11 ディレクトリ・サーバー・マシン: Oracle Unified Directoryのインストール
Oracle Unified Directoryをインストールします。次の表に、この項の例で使用するインストール設定を示します。
| 変数タイプ | サンプル値 |
|---|---|
|
ディレクトリ・サーバーの完全修飾DNS名 |
|
|
サーバー・ポート |
|
|
接尾辞 |
|
|
インストール・ディレクトリ |
|
|
Oracle Unified Directoryサーバー・ユーザー |
|
|
Oracle Unified Directoryサーバー・グループ |
|
|
Kerberosテスト・プリンシパル |
|
|
Oracle Unified Directoryキータブ・パス |
|
ノート:
ディレクトリ・サーバーの完全修飾DNS名は、すべてのサーバー(Oracle Unified Directoryサーバー、Kerberos Key Distribution Center (KDC)およびGSSAPI SASLを使用してサーバーにバインドする予定のクライアント・マシン)上で同一IPアドレスに変換される必要があります。
26.10.3.12 ディレクトリ・サーバーLDAPの作成と構成(ディレクトリ・サーバー・マシン)
これまでに説明したように、GSSAPIによってKerberosユーザーを認証するには、Oracle Unified DirectoryはKDC内に独自のプリンシパルを持つ必要があります。プリンシパル情報は、ディレクトリ・サーバー・マシン上のKerberosキータブ内に格納されている必要があります。この情報は、ディレクトリ・サーバーが動作するユーザー・アカウントが参照できるファイル内にある必要があります。
ノート:
このステップは、GSSAPI SASL mechanism handlerを構成する前に実行する必要があります。ハンドラは初期化する前にキータブ・ファイルが存在することを確認します。
正しいプロパティを持つキータブ・ファイルを作成するには、次の一連のコマンドを使用します:
$kadmin -p kws/admin@EXAMPLE.COMkadmin: addprinc -randkey ldap/directory.example.com WARNING: no policy specified for ldap/directory.example.com@EXAMPLE.COM; defaulting to no policy Principal "ldap/directory.example.com@EXAMPLE.COM" created. kadmin:ktadd -k asinst_1/oud/config/oud.keytab ldap/directory.example.comEntry for principal ldap/directory.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:asinst_1/oud/config/oud.keytab. Entry for principal ldap/directory.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:asinst_1/oud/config/oud.keytab. Entry for principal ldap/directory.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:asinst_1/oud/config/oud.keytab. Entry for principal ldap/directory.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:asinst_1/oud/config/oud.keytab. kadmin:quit
このカスタムのキータブのアクセス権と所有権を変更します。キータブを、ディレクトリ・サーバーを実行するために使用されるユーザー・アカウントの所有にし、そのユーザーしか参照できないようにします:
$chown oud:oud asinst_1/oud/config/oud.keytab$chmod 600 asinst_1/oud/config/oud.keytab
これらの変更を有効にするには、ディレクトリ・サーバーを停止し、再起動する必要があります。
26.10.3.13 GSSAPIを有効にするためのディレクトリ・サーバーの構成(ディレクトリ・サーバー・マシン)
このステップでは、directory.example.comディレクトリ・サーバー・ホスト上のGSSAPI SASL mechanism handlerを管理する例を示します。
次の例に従ってdsconfigコマンドを使用してディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラを有効にし、asinst_1/oud/config/oud.keytabを使用するようにそのハンドラを構成します。
$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file set-sasl-mechanism-handler-prop \ --handler-name GSSAPI \ --set enabled:true \ --set keytab:asinst_1/oud/config/oud.keytab \ --set server-fqdn:directory.example.com
このコマンドの最後の行はGSSAPI SASLメカニズムのプロパティserver-fqdnをdirectory.example.comに設定します。これはオプションのパラメータです。ディレクトリ・サーバー・ホスト上でのホスト名の検索によりLDAPプリンシパルの作成に使用された正確なホスト名が間違えなく返される場合は、省略しても構いません。このプロパティを設定すると、2つの名前を確実に一致させられます(この例では、directory.example.com)。
ディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラのプロパティを調べて構成が正しいことを確認します。
$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file \ get-sasl-mechanism-handler-prop \ --handler-name GSSAPI Property : Value(s) ----------------------:---------------------- enabled : true identity-mapper : Regular Expression kdc-address : - keytab : asinst_1/oud/config/oud.keytab principal-name : - quality-of-protection : none realm : - server-fqdn : directory.example.com
トラブルシューティングの必要がある場合は、dsconfigを使用してディレクトリ・サーバー・ホストdirectory.example.com上のすべてのSASLメカニズム・ハンドラのステータスをリストすることができます。
$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file \ list-sasl-mechanism-handlers SASL Mechanism Handler : Type : enabled -----------------------:------------:-------- ANONYMOUS : anonymous : false CRAM-MD5 : cram-md5 : true DIGEST-MD5 : digest-md5 : true EXTERNAL : external : true GSSAPI : gssapi : true PLAIN : plain : true
必要があれば、dsconfigを使用してディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラを無効にできます。
$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file \ set-sasl-mechanism-handler-prop \ --handler-name GSSAPI \ --set enabled:false
26.10.3.14 ディレクトリ・サーバーへのテスト・ユーザーの追加(ディレクトリ・サーバー・マシン)
Kerberosユーザーをディレクトリ・サーバーに対して認証するには、そのユーザーのKerberosプリンシパルに対応する、ユーザーのディレクトリ・エントリが必要です。
これまでのステップで、kerberos-test@EXAMPLE.COMというプリンシパルを持つテスト・ユーザーがKerberosデータベースに追加されました。ディレクトリに追加されたアイデンティティ・マッピング構成のために、そのユーザーに対応するディレクトリ・エントリには、uid=kerberos-test,ou=People,dc=example,dc=comというDNが必要です。
ユーザーをディレクトリに追加する前に、次の内容でファイルtestuser.ldifを作成する必要があります。
dn: uid=kerberos-test,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: kerberos-test givenName: Kerberos sn: Test cn: Kerberos Test description: An account for testing Kerberos authentication through GSSAPI
次に、ldapmodifyを使用して、このエントリをサーバーに追加します:
$ ldapmodify -D "cn=Directory Manager" -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$26.10.3.15 テスト・ユーザーとしてのKerberosチケットの取得(ディレクトリ・サーバー・マシン)
テスト・ユーザーは、Kerberosデータベース、ディレクトリ・サーバーおよびKDC内に存在します。このため、ディレクトリ・サーバーのテスト・ユーザーとしてGSSAPIを経由したKerberosによって認証できます。
まず、kinitコマンドを使用してユーザーのKerberosチケットを取得します。次の例を参照してください:
$kinit kerberos-testPassword for kerberos-test@EXAMPLE.COM:secret$
次に、klistコマンドを使用して、このチケットに関する情報を表示します:
$ klist
Kerberos 5 ticket cache: 'API:6'
Default principal: kerberos-test@EXAMPLE.COM
Valid Starting Expires Service Principal
03/23/09 12:35:05 03/23/09 20:35:05 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 03/30/09 12:34:15
$26.10.3.16 GSSAPIによるディレクトリ・サーバーに対する認証(クライアント・マシン)
最後のステップはGSSAPIを使用したディレクトリ・サーバーに対する認証です。ディレクトリ・サーバーの提供するldapsearchユーティリティは、GSSAPI、DIGEST-MD5およびEXTERNALメカニズムを含むSASL認証をサポートしています。しかし、GSSAPIを使用してバインドするために、SASLライブラリへのパスをクライアントに設定する必要があります。SASL_PATH環境変数をlib/saslディレクトリに設定してパスを提供します:
$SASL_PATH=SASL-library$export SASL_PATH$
ldapsearchを使用してディレクトリ・サーバーに対して実際にKerberosベースの認証を実行するには、-o mech=GSSAPI引数と-o authzid=principal引数を含める必要があります。
また、ここで-h directory.example.comと表示している完全修飾ホスト名も指定する必要があります。これは、サーバーに対するcn=config上のnsslapd-localhost属性の値と一致する必要があります。GSSAPI認証プロセスでは、クライアントから提供されたホスト名がサーバーから提供されたホスト名と一致する必要があるため、ここでは-hオプションを使用する必要があります。
次の例では、これまでに作成したKerberosテスト・ユーザー・アカウントとして認証を行って、dc=example,dc=comエントリを取得しています:
$ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \ -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)" version: 1 dn: dc=example,dc=com dc: example objectClass: top objectClass: domain $
正常に認証されたかどうかディレクトリ・サーバーのアクセス・ログを確認します:
$ tail -12 /local/ds/logs/access
[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP
connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97
nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1
etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$
この例は、バインドが3つのステップによるプロセスであることを示しています。最初の2つのステップでLDAP結果14 (SASLバインド実行中)を返し、3番目のステップはバインドが成功したことを示します。method=saslタグとmech=GSSAPIタグは、このバインドにGSSAPI SASLメカニズムが使用されたことを示しています。成功したバインド・レスポンスの最後のdn="uid=kerberos-test,ou=people,dc=example,dc=com"は、このバインドが適切なユーザーとして実行されたことを示しています。
26.10.4 dsconfigを使用したKerberosワークフロー要素の作成
dsconfig create-workflow-elementコマンドの実行によりKerberosワークフロー要素を作成できます
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element \ --type KerberosAuthProviderWorkflowElement \ --element-name Kerberos_Test_WE \
26.10.5 Kerberos構成のトラブルシューティング
Kerberos構成をトラブルシューティングするための条件をチェックできます。
Kerberosのインストールを期待どおりに実行できない場合は、次の条件を確認してください:
-
ディレクトリ・サーバー・マシンからのテスト・プリンシパルを使用して
kinitを実行し、ディレクトリ・サーバーがKerberos KDCで認証されることを確認します。 -
クライアント・マシンからのテスト・プリンシパルを使用して
kinitを実行し、クライアント・マシンがKerberos KDCで認証されることを確認します。 -
ディレクトリ・サーバーのキータブ・ファイルが存在し、ディレクトリ・サーバーによって読み取り可能なことを確認します。つまり、キータブ・ファイルの所有権と権限設定が正しいことを確認します。
-
キータブ・ファイル内のLDAPプリンシパル名が、構成時にディレクトリ・サーバーによって使用されたホスト名と一致することを確認します。次の例は失敗する構成を示します:
-
次のようにGSSAPIを構成します。
server-fqdn属性に指定された値bad.example.comが、キータブdirectory.example.comの作成時に使用された値と一致しません。$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file \ set-sasl-mechanism-handler-prop \ --handler-name GSSAPI \ --set enabled:true \ --set keytab:asinst_1/oud/config/oud.keytab \ --set server-fqdn:bad.example.com
-
クライアントからGSSAPIを使用してldapsearch認証を試みます。
$ ldapsearch -h directory.example.com \ -o mech=GSSAPI -o authid=kerberos-test@EXAMPLE.COM \ --searchScope base \ -b "uid=kerberos-test,ou=people,dc=example,dc=com" "(objectclass=*)" An error occurred while attempting to perform GSSAPI authentication to the Directory Server: \ PrivilegedActionException(AccessController.java:-2) Result Code: 82 (Local Error)
予想どおり、検索は失敗します。
-
検索が失敗した原因を確認するには、ディレクトリ・サーバーのアクセス・ログを調べます:
$ tail asinst_1/oud/logs/access [23/Mar/2009:13:12:59 -0500] CONNECT conn=14 from=129.150.33.77:65076 to=192.168.0.199:1389 protocol=LDAP [23/Mar/2009:13:13:00 -0500] BIND REQ conn=14 op=0 msgID=1 type=SASL mechanism=GSSAPI dn="" [23/Mar/2009:13:13:00 -0500] BIND RES conn=14 op=0 msgID=1 result=49 authFailureID=1310915 authFailureReason="An unexpected error occurred while trying to create an GSSAPI context: major code (13) No valid credentials provided, minor code (-1) Failed to find any Kerberos Key" etime=253 [23/Mar/2009:13:13:00 -0500] DISCONNECT conn=14 reason="Client Disconnect"
アクセス・ログの最後のレコードのマイナー・コードにあるメッセージに、ディレクトリ・サーバーがキータブ・ファイル内に一致するエントリを見つけられなかったことが示されています。
-
問題を解決するには、ハンドラを無効にしてから、次の例が示すように正しい情報を使用して再度有効にします。
$ dsconfig -X -n -p 4444 -h directory.example.com \ -D "cn=directory manager" -j pwd-file \ set-sasl-mechanism-handler-prop \ --handler-name GSSAPI \ --set enabled:false $ dsconfig -X -n -p 4444 -h directory.example.com -D "cn=directory manager" -j pwd-file \ set-sasl-mechanism-handler-prop \ --handler-name GSSAPI \ --set enabled:true \ --set keytab:asinst_1/oud/config/oud.keytab \ --set server-fqdn:directory.example.com $ ldapsearch -h directory.example.com \ -o mech=GSSAPI \ -o authid=kerberos-test@EXAMPLE.COM \ --searchScope base \ -b "uid=kerberos-test,ou=people,dc=example,dc=com" "(objectclass=*)" dn: uid=kerberos-test,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: kerberos-test givenName: Kerberos sn: Test cn: Kerberos Test description: An account for testing Kerberos authentication through GSSAPI
-
26.11 ldapsearchによるSSL、StartTLS、およびSASL認証のテスト
ディレクトリ・サーバーに用意されているldapsearchユーティリティは、サーバーがSSLおよびStartTLSをサポートするために正しく構成されていることをテストするときに便利です。
このユーティリティには、様々な状況下でのテストに適したオプションがいくつか含まれています。この項では、ldapsearchを使用してSSLおよびStartTLS通信、SASL EXTERNAL認証をテストする方法を説明します。ldapmodify、ldapcompareおよびldapdeleteなど、ディレクトリ・サーバーで提供されているその他の多数のクライアント・ツールで同一プロセスを使用できます。詳細情報は次の各項で説明します。
26.11.1 セキュリティに適用できるldapsearchコマンド行引数
ldapsearchツールを使用してSSLまたはStartTLSを介して通信するときに、コマンド行引数を使用できます。
表26-10 ldapsearchコマンド行引数
| 引数 | 説明 |
|---|---|
|
|
接続先のディレクトリ・サーバーのアドレスを指定します。値を省略すると、IPv4ループバック・アドレス( |
|
|
ディレクトリ・サーバーが接続をリスニングするポート番号を指定します。値を省略すると、標準の暗号化されていないLDAPポート( |
|
|
クライアントがSSLを使用してディレクトリ・サーバーとの通信を保護していることを示します。このオプションを使用する場合は、ポート引数に指定した値がSSLベースの接続をサーバーがリッスンするポートである必要があります。デフォルトのLDAPSポートは、 |
|
|
ディレクトリ・サーバーとの通信を保護するためにクライアントはStartTLS拡張操作を使用する必要があることを示します。このオプションを使用する場合は、ポート引数に指定した値がクリアテキストLDAP接続をサーバーがリッスンするポートである必要があります。 サーバーがデフォルトのLDAPポート( |
|
|
ディレクトリ・サーバーに対して認証するためにクライアントはSASL EXTERNAL認証を使用する必要があることを示します。このオプションを使用する場合は、キーストア・パスも指定する必要があります。 |
|
|
ディレクトリ・サーバーによって提出されるすべての証明書をクライアントが無差別に信頼することを示します。このオプションは、トラスト・ストア・パスの指定に使用される引数と一緒に使用しないでください。 |
|
|
クライアントがディレクトリ・サーバーに証明書を提出する場合に使用する必要があるキーストアへのパスを指定します(たとえば、SASL EXTERNAL認証を使用するときなど)。これはJKSキーストアへのパスです。 |
|
|
キーストアのコンテンツへのアクセスに必要なPINを指定します。このオプションは、キーストア・パスワード・ファイル引数と一緒に使用しないでください。 |
|
|
キーストアのコンテンツへのアクセスに必要なPINを含むファイルへのパスを指定します。このオプションは、キーストア・パスワード引数と一緒に使用しないでください。 |
|
|
クライアントがディレクトリ・サーバーに提出する必要がある証明書のニックネーム(または別名)を指定します。キーストア・パス引数も指定する必要があります。ニックネームを省略すると、クライアントはキーストア内で見つけた最初の受け入れ可能なクライアント証明書を使用します。 |
|
|
クライアントがディレクトリ・サーバーによって提出された証明書を信頼するかどうか判断するときに使用するJKSトラスト・ストア・ファイルへのパスを指定します。この引数と |
|
|
トラスト・ストアのコンテンツにアクセスするために必要なパスワードを指定します。通常、トラスト・ストア・パスワードは必要ありません。このオプションは、トラスト・ストア・パスワード・ファイル・オプションと一緒に使用しないでください。 |
|
|
トラスト・ストア・コンテンツへのアクセスに必要なパスワードを含むファイルへのパスを指定します。通常、トラスト・ストア・パスワードは必要ありません。このオプションは、トラスト・ストア・パスワード・オプションと一緒に使用しないでください。 |
|
|
ディレクトリ・サーバーがバインド・レスポンスに認証済ユーザーの認可アイデンティティを含める必要があることを示します。これはSASL認証を実行して、クライアント証明書(またはEXTERNAL以外のメカニズムが使用された場合は、その他の形式のSASL資格証明)がマッピングされるユーザーを判断するのに役立ちます。 |
26.11.2 SSLのテスト
ldapsearchを使用してLDAP over SSLを通してディレクトリ・サーバーと通信できます。
次に、ldapsearchの使用方法を示します。
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --baseDN "" --searchScope base "(objectClass=*)"
この場合、トラスト・ストアは指定されず、--trustAll引数も指定されません。このため、サーバーが証明書をクライアントに提出すると、その証明書を信頼すべきかどうかユーザーが尋ねられます。全シーケンスの例を以下に示します:
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --baseDN "" --searchScope base "(objectClass=*)" The server is using the following certificate: Subject DN: CN=directory.example.com, O=Example Corp, C=US Issuer DN: CN=directory.example.com, O=Example Corp, C=US Validity: Fri Mar 02 16:48:17 CST 2007 through Thu might 31 17:48:17 CDT 2007 Do you want to trust this certificate and continue connecting to the server? Please enter "yes" or "no": dn: objectClass: ds-rootDSE objectClass: top
ユーザーに確認せずに、サーバーによって提出されたすべての証明書をクライアントに信頼させるには、--trustAll引数を指定します。たとえば:
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --trustAll --baseDN "" --searchScope base \ "(objectClass=*)"
クライアントがトラスト・ストアを所有し、それを使用してサーバー証明書を信頼するかどうか判断する場合は、--trustStorePath引数も指定する必要があります。たとえば:
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --trustStorePath client.truststore --baseDN "" \ --searchScope base "(objectClass=*)"
26.11.3 StartTLSのテスト
ldapsearchユーティリティでStartTLSを使用するプロセスは、SSLを使用するプロセスとほとんど同じです。サーバーが暗号化されていないLDAPリクエストをリッスンするポートを使用し、SSLのかわりにStartTLSを使用する(つまり、--useSSLのかわりに--useStartTLSを使用する)ことを示す必要がある点のみ異なります。
次の例は通信を保護するためにStartTLSを使用することを除き、SSLとldapsearchを使用する最初の例と同じです:
$ ldapsearch -h directory.example.com --port 1389 \ --useStartTLS --baseDN "" --searchScope base "(objectClass=*)"
これはその他のすべての例に適用されます。単にLDAPSポートからLDAPポートにポート番号を変更し、--useSSLオプションを--useStartTLSで置き換えます。
26.11.4 SASL EXTERNAL認証のテスト
SASL EXTERNAL認証は、SSLまたはStartTLSとともに使用できます。主な相違点は、クライアント証明書を含むキーストア、そのキーストアのコンテンツにアクセスする必要があるPIN、およびクライアントがSASL EXTERNAL認証を使用する必要があることを示すフラグを指定する必要があることです。
ノート:
SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。
次の例では、このようなコマンドの使用例を示します:
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --keyStorePath /path/to/client.keystore \ --keyStorePasswordFile /path/to/client.keystore.pin \ --useSASLExternal --certNickName nickname \ --baseDN "" --searchScope base \ "(objectClass=*)"
SASL EXTERNAL認証を使用するときに、認証が正しいユーザーとして実行されていることを保証するためにサーバーに認可IDを返してもらうときにも便利です。以下に、このプロセスの例を示します。("#"で始まる行に報告された値に注意します。)
$ ldapsearch --hostname directory.example.com --port 1636 \ --useSSL --keyStorePath /path/to/client.keystore \ --keyStorePasswordFile /path/to/client.keystore.pin \ --useSASLExternal --reportAuthzID --certNickName nickname \ --baseDN "" --searchScope base "(objectClass=*)" # Bound with authorization ID dn:uid=test.user,dc=example,dc=com dn: objectClass: ds-rootDSE objectClass: top
26.12 OpenSSL s_clientテスト・ユーティリティを使用したSSLのデバッグ
OpenSSLは、SSLサーバーをデバッグするための有益で便利な診断ツールs_clientを提供します。
これらのトピックでは、OpenSSL s_clientテスト・ユーティリティおよび様々なシナリオをデバッグするための解決策について説明します。
26.12.1 OpenSSL s_clientテスト・ユーティリティについて
s_clientは、SSLサーバーをデバッグするために使用される診断ツールです。このコマンドは、SSL/TLSを使用してリモート・ホストに接続する汎用SSL/TLSクライアントを実装します。
この強力なコマンド行ユーティリティにより、SSL/TLSを使用するサーバーをテストまたはデバッグできます。Oracle Unified Directoryサーバーへのセキュアな接続をテストするには、コマンド・プロンプトに次のコマンドを入力します。
openssl s_client -connect <host>:<port> [options]
この場合、
s_client:は、セキュア・サーバーをテストするためのSSL/TLSテスト・クライアントです。テスト・クライアントは、セキュア・ポートに接続し、SSL/TLSハンドシェーク中に実行されたステップの詳細なログを提供します。
hostname:port: 接続先のホストとオプションのポートを指定します。省略すると、ポート443でローカル・ホストへの接続が試みられます。これは、httpsによりポート443が使用されるからです。
接続された場合、セキュア・サーバーに対してGET /やHEAD / HTTP/1.0など、いくつかのコマンドを手動で入力できます。ただし、ハンドシェークが失敗する場合には、いくつかの原因が考えられます。直面している問題がアプリケーション、ファイアウォール、証明書トラストなどに関連しているかどうか確認したい場合、この項では考えられる原因のリストからSSLを除外する方法を説明します。
26.12.2 シナリオ1- 接続が拒否された
割り当てられたSSLポートでSSLクライアントに接続しようとしても接続できません。
次に、このシナリオの例を示します:
openssl s_client -connect localhost:<ldaps_portnumber> connect: Connection refused connect:errno=146
解決策
解決策として、config.ldifファイルのLDAPS番号が正しい値かどうか確認してください。
26.12.3 シナリオ2 - リターン・コード: 18 (自己署名証明書)を確認する
エラー・コード18は、証明書チェーンの検証が失敗したためSSLクライアント・プログラムがサーバーとのセキュアな接続(https)を確立できなかったことを意味します。ユーザーが使用しているサーバーは自己署名証明書を使用しており、証明書チェーンを使用する必要があります。
次に、このシナリオの例を示します:
openssl s_client -connect localhost:<ldaps-port-number>
CONNECTED(00000004)
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDBjCCAsSgAwIBAgIETxRMvTALBgcqhkjOOAQDBQAwZjELMAkGA1UEBhMCY2Ex
EzARBgNVBAgTCkNhbGlmb3JuaWExCzAJBgNVBAcTAlNGMQ8wDQYDVQQKEwZPcmFj
bGUxDTALBgNVBAsTBGxkYXAxFTATBgNVBAMTDHNlcnZlciBhZG1pbjAeFw0xMjAx
MTYxNjEzNDlaFw0xMjA0MTUxNjEzNDlaMGYxCzAJBgNVBAYTAmNhMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xlMQ0wCwYD
VQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG4MIIBLAYHKoZIzjgE
ATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7
V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCP
FSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wL
PQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64e
K7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7
/s9JKgOBhQACgYEAw+2EIpmwy0rqtHbNb6gxbEtW0hplXXQdHEQp24brde1jt1qv
LDz/c8KR+fVxqvTxAmurGt1qbrhjXcUxi1KdaLnLnLXTCoD+ZLQU+F6B/TNmfrxb
AJmHtmoZsFtNCBTC++FClXtconKyXjEWnKMw7fEb+gNY3eTUrcyIpa/YEbYwCwYH
KoZIzjgEAwUAAy8AMCwCFEtf5+J77Q/5fI6bZ7k3D1rdbw6UAhQkWGmp8VOiMdUg
5K4wK7Y7cC0wSQ==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=user.41
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
SSL handshake has read 1594 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C3F27655013F71AE2120134A8D1AFE966A1D9233618507DEFE9C607417AA
Session-ID-ctx:
Master-Key: 57BDB7FCA9A293E65274AA7CDD0E7CC48AA227806FC2B54C9F9E36BB26D32943FC115CE4FF9A605B6B6BD237026F3D0E
Key-Arg : None
Start Time: 1326892018
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
解決策
署名済証明応答とCA証明書をサーバーのキーストアにインポートする必要があります。
26.12.4 シナリオ3 - リターン・コード: 0 (ok)を確認する
SSLサーバーとの接続が正常に確立されると、リターン・コード0を受け取ります。これは、サーバーから受信したデータがすべて表示され、押されたキーがすべてサーバーに送信されることを意味します。また、使用される証明書チェーンも表示されます。
次に、稼働中のセッションの例を示します:
openssl s_client -connect localhost:8636 -verify 250 \
-key $SERVER_SSL/config/keystore -CApath $CA_SSL -CAfile ca-cert.pem
-key is specifying the path to the server keystore
-CAPath/-CAfile allows to locate CA certificate (pem format)
verify depth is 250
CONNECTED(00000004)
depth=1 /C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
1 s:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
i:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYDCCAsmgAwIBAgIFAJbW4rkwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMC
RlIxDzANBgNVBAgTBkZyYW5jZTERMA8GA1UEBxMIR3Jlbm9ibGUxDzANBgNVBAoT
Bk9yYWNsZTEMMAoGA1UECxMDT1VEMRcwFQYDVQQDEw5DQSBDZXJ0aWZpY2F0ZTAe
Fw0xMjAxMTcxMDQ5MjdaFw0xMjA0MTcxMDQ5MjdaMGYxCzAJBgNVBAYTAmNhMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xl
MQ0wCwYDVQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG3MIIBLAYH
KoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX
/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccC
FQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o6
6oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8
jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7
VSVkAUw7/s9JKgOBhAACgYA8N/yzB5rrvNOPhOrea1RNCRePn0bMvXkDpfUs8dpH
z1qQog4soloAhojIYJYA3OGqKr3ryNnfB0B8lePQ1ZaJgkURqOjiVKF6xv5FmnuM
C1uwiTfr/9IKijiy8oCKKKSLTB5lY3Rk0o03D+LrqgLp27A41WvvhGo4djBqXse1
OTANBgkqhkiG9w0BAQUFAAOBgQBzTpgFc1YCpo8QKeoDBRag4tn2y8BzkeLeLMgy
gQAYCGNjJjrV0ChYKMJnqLPCrP9+/Otyj9ZByn9+T1Jx9/khuh9oNXCwF5FUE5VE
gkn3kPo1LdLBqKpfUSeFcYNJDQDhtThVwEq05Ifm+JuCCM4J3BbFuZpJM5xnbcIZ
mjcn5w==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
---Verify return code: 0 (ok)
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=fr/ST=Isere/L=Montbonnot/O=Oracle/OU=ldap/CN=server_8839
---
SSL handshake has read 2179 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C59B172D329E44AF199B4E49B14E54163AAF783A68FBD48556FCB06A9238
Session-ID-ctx:
Master-Key: 21CC1BBF638FFDAF16E5DBAB337728D029F0125D483636EF7590BE3005DDA96AEAF60DE88172DE925806F633EB09ACBE
Key-Arg : None
Start Time: 1326892443
Timeout : 300 (sec)
Verify return code: 0 (ok)
26.12.5 シナリオ4 - SSLHandshakeException
セキュアなサーバー接続を確立しようとすると、ldapsearchによりエラー・メッセージが発行されます。
エラー・メッセージは次のとおりです。
ldapsearch -p 7636 -D "cn=Directory Manager" -w secret12 -P config/truststore -Z -b dc=example,dc=com uid=user.0 Cannot send the simple bind request: SSLHandshakeException(sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)
サーバーの証明書が自己署名証明書であり、証明書チェーンでないため、このエラーが表示されます。エラー・コード18を受け取ります。
以下に、このプロセスの例を示します。
openssl s_client -connect localhost:7636
CONNECTED(00000004)
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDBjCCAsSgAwIBAgIETxRMvTALBgcqhkjOOAQDBQAwZjELMAkGA1UEBhMCY2Ex
EzARBgNVBAgTCkNhbGlmb3JuaWExCzAJBgNVBAcTAlNGMQ8wDQYDVQQKEwZPcmFj
bGUxDTALBgNVBAsTBGxkYXAxFTATBgNVBAMTDHNlcnZlciBhZG1pbjAeFw0xMjAx
MTYxNjEzNDlaFw0xMjA0MTUxNjEzNDlaMGYxCzAJBgNVBAYTAmNhMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xlMQ0wCwYD
VQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG4MIIBLAYHKoZIzjgE
ATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7
V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCP
FSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wL
PQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64e
K7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7
/s9JKgOBhQACgYEAw+2EIpmwy0rqtHbNb6gxbEtW0hplXXQdHEQp24brde1jt1qv
LDz/c8KR+fVxqvTxAmurGt1qbrhjXcUxi1KdaLnLnLXTCoD+ZLQU+F6B/TNmfrxb
AJmHtmoZsFtNCBTC++FClXtconKyXjEWnKMw7fEb+gNY3eTUrcyIpa/YEbYwCwYH
KoZIzjgEAwUAAy8AMCwCFEtf5+J77Q/5fI6bZ7k3D1rdbw6UAhQkWGmp8VOiMdUg
5K4wK7Y7cC0wSQ==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=user.41
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
SSL handshake has read 1594 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C3F27655013F71AE2120134A8D1AFE966A1D9233618507DEFE9C607417AA
Session-ID-ctx:
Master-Key: 57BDB7FCA9A293E65274AA7CDD0E7CC48AA227806FC2B54C9F9E36BB26D32943FC115CE4FF9A605B6B6BD237026F3D0E
Key-Arg : None
Start Time: 1326892018
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
解決策
この問題を修正するには:
26.12.6 シナリオ5 - SASL EXTERNALバインド・リクエストを処理できない
SSL上でOUD SASLクライアントの外部認証を実行すると、エラー・メッセージが表示されます。
以下のエラー・メッセージが表示されます。
ldapsearch -p 7636 -Z -K /export/home/oud/security/client/config/keystore -W secret12 -P /export/home/oud/security/client/config/truststore --trustStorePassword secret12 -N user.41-cert --useSASLExternal -b dc=example,dc=com uid=user.0 The SASL EXTERNAL bind attempt failed Result Code: 49 (Invalid Credentials)
アクセス・ログを表示すると、次のメッセージが示されます:
CONNECT conn=2 from=127.0.0.1:46763 to=127.0.0.1:7636 protocol=LDAPS [18/Jan/2012:17:48:44 +0100] BIND REQ conn=2 op=0 msgID=1 type=SASL mechanism=EXTERNAL dn="" [18/Jan/2012:17:48:44 +0100] BIND RES conn=2 op=0 msgID=1 result=49 authFailureID=1245310 authFailureReason="The SASL EXTERNAL bind request could not be processed because the client did not present a certificate chain during SSL/TLS negotiation" etime=6 [18/Jan/2012:17:48:44 +0100] DISCONNECT conn=2 reason="Client Disconnect"
クライアント証明書が有効な証明書チェーンでない場合に、このエラーが表示されます。
解決策
この問題を修正するには:
26.13 Javaデバッグ情報を使用したSSLまたはTLSのデバッグ
Javaデバッグ情報を使用してSSLまたはTLS接続のネットワーク・トラフィックをトラブルシューティングできます。
SSLを解析する方法がネットワーク・アクセスの追跡しかないことがあります。Oracle Unified Directoryでは、config/java.propertiesファイルで-Djavax.net.debug=allオプションをサーバーに追加することによりSSLをデバッグできます。
サンプルのデバッグ出力は次のとおりです:
server.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted,
alert ID 458887): The Directory Server has started successfully
***
found key for : server-cert
chain [0] = [
[
Version: V3
Subject: CN=server admin, OU=ldap, O=mycompany, L=City1, ST=Country1, C=ca
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: SunPKCS11-Solaris DSA public key, 1024 bits (id 22714576, session object)
y: 13758517829882967277399226271740078303525267606775373025890213388747276573
7596162865068864757751081632128325087288240737049199605991868092341784810001823
8935577641022820073567301050114620394591914372932977255128638534681835198625775
05401958362086546885405080570540575677103845462467633475547155894544465662390
p: 17801190547854226652823756245015999014523215636912067427327445031444286578873
70207706126952521234630795671567847784664499706507709207278570500096683881440
341297452211718185060472311500393010799593580673953487170663198022620197149665
24135060945913707594956514672855690606794135837542707371727429551343320695239
q: 864205495604807476120572616017955259175325408501
g: 17406820753240209518581198012352343653860449079456135097849583104059995
348845582314785159740894095072530779709491575949236830057425243876103708447
3467180148876118103083043754985190983472601550494691329488083395492313850000
3616464826446084923040787218189599990564960977693680177492737089620066891879
56744210730
Validity: [From: Mon Jan 16 17:15:45 MET 2012,
To: Mon Apr 16 18:15:45 MEST 2012]
Issuer: CN=CA Certificate, OU=OUD, O=mycompany, L=City2, ST=Country2, C=FR
SerialNumber: [96d4f0dc]
]
Algorithm: [SHA1withRSA]
Signature:
0000: 72 F6 7E 93 2B 87 B9 C7 39 51 4C D2 A7 B0 AA 36 r...+...9QL....6
0010: B8 0F BA C4 6E 43 70 72 81 50 09 7A 88 05 16 A2 ....nCpr.P.z....
0020: 1C 96 C2 49 B3 0A F9 AB 2B 4B 8D 59 4C BA 58 C9 ...I....+K.YL.X.
0030: EF B9 48 58 A7 C5 BB B5 0E 64 51 CF BC 58 DA 71 ..HX.....dQ..X.q
0040: E1 F7 2E A4 1D 1B FC D5 4F B2 70 B0 78 F4 FB E6 ........O.p.x...
0050: C4 6A 6A E0 DE B0 F5 98 7B 09 A9 A4 9D 17 4C F5 .jj...........L.
0060: 9F 06 07 E1 09 81 77 9E 41 3C 02 4C FB D8 94 ED ......w.A<.L....
0070: 36 6A 65 5A 96 2C AE A4 86 83 66 63 BC 3C 8C 47 6jeZ.,....fc.<.G
]
Oracle Unified Directoryデバッグ・ログ・テキストに加えて、前記の情報が提供されます。
次の各トピックでは、SSLデバッグ記録の使用方法を説明します。
26.13.1 SSLデバッグ記録の有効化
start-ds.java-argsプロパティを更新して、SSLデバッグ記録を有効化できます。
次のステップを実行して、SSLデバッグ記録を有効化します:
ノート:
SSLデバッグ情報は、logs/server.outファイルにログされます。
26.14 許可および拒否ルールを使用した接続アクセスの制御
サーバーへの接続の受入れに責任を持つ接続ハンドラを制御できます。
これらのトピックでは、接続ハンドラのタイプとそのプロパティおよび構文について説明します。
26.14.1 接続ハンドラについて
接続ハンドラの許可または拒否されたクライアント・ルールを使用して、どのホストがサーバーへのTCP接続を確立できるか管理します。接続ハンドラは、サーバーへの接続の受け入れに責任を持ちます。
この項に示された異なる種類の接続ハンドラとその構成プロパティは次のとおりです:
-
allowed-client。この接続ハンドラへの接続の確立を許可されているクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。 -
denied-client。この接続ハンドラへの接続の確立を許可されていないクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。許可と拒否の両方のクライアント・マスクが定義され、クライアント接続が両方のリストの中の1つ以上のマスクと一致すると、接続は拒否されます。拒否リストのみ指定された場合、そのリストの中のマスクと一致しないクライアントはすべて許可されます。
ノート:
IPv4とIPv6の両方のアドレスがサポートされています。
26.14.2 許可および拒否クライアント・ルールのプロパティ構文
allowed-clientプロパティとdenied-clientプロパティは、同一構文を使用して、IP (IPv4またはIPv6)アドレスおよびホスト名に対してパターン・マッチングを実行します。
次の構文がサポートされています:
-
IPアドレス - 許可または拒否されるクライアントのIPアドレスはルールの中に指定できます。たとえば:
ds-cfg-denied-client: 192.168.5.6 ds-cfg-allowed-client: 2001:fecd:ba23:cd1f:dcb1:1010:9234:4088
-
CIDR表記のIPアドレス - CIDR表記を使用するIPアドレスを指定することにより特定範囲のIPアドレスを許可または拒否できます。たとえば:
ds-cfg-denied-client: 192.168.5.6/28 ds-cfg-allowed-client: 2001:0db8:1234::/48
まず、
192.168.5.0 - 192.168.5.15の範囲のクライアントが拒否され、第2に2001:0db8:1234:0000:0000:0000:0000:0000 - 2001:0db8:1234:ffff:ffff:ffff:ffff:ffffの範囲のクライアントが許可されます。 -
'*'表記を持つIPアドレス - IPアドレスに'*'を指定してIPアドレスの部分と一致させることにより、特定範囲のIPアドレス(IPv4のみ)を許可または拒否できます。たとえば:
ds-cfg-denied-client: 192.168.5.* ds-cfg-allowed-client: 129.45.*.*
最初の例は192.168.5で始まるIPアドレスを持つクライアントを拒否し、2番目の例は129.45で始まるIPアドレスを持つクライアントを許可します。2番目の例では複数の一致文字が使用されていることに注意してください。すべてのIPアドレスを一致させるには、次のようなルールを使用します:
ds-cfg-denied-client: *.*.*.*
-
DNS名 - クライアントはDNS名によって制限できます。たとえば、ホスト名
foo.example.comでクライアントを制限するには、次のように入力します:ds-cfg-denied-client: foo.example.com
-
パターン一致を使用するDNS名 - これはIPアドレスのパターン一致と類似しています。プロパティに'*'を指定してDN名の部分と一致させます:
ds-cfg-allowed-client: foo.*.test.com
このプロパティにより、
foo.bar.test.comまたはfoo.foobar.test.comなどのDN名を持つクライアントが許可されます。接尾辞で終了するDNS名のみと一致させる場合、プロパティは次のとおりです:ds-cfg-allowed-client: .example.com
このプロパティにより、
test.example.comまたはtest.me.example.comなどのDNS名を持つクライアントが許可されます。ノート:
ホスト名の変換はサーバー名サービスの構成により異なるため、DNSプロパティを使用するときには注意してください。
26.14.3 許可および拒否クライアント・ルールの構成
接続ハンドラは、それぞれに独自のルール・セットを持つ必要があります。dsconfigコマンドを使用して、各接続ハンドラの許可および拒否プロパティを管理できます
次の例は、ルール・セットのリストです。
dn: cn=LDAP Connection Handler,cn=Connection Handlers,cn=config objectClass: top objectClass: ds-cfg-connection-handler objectClass: ds-cfg-ldap-connection-handler cn: LDAP Connection Handler ds-cfg-java-class: org.opends.server.protocols.ldap.LDAPConnectionHandler ds-cfg-enabled: true ds-cfg-listen-address: 0.0.0.0 ds-cfg-listen-port: 389 ds-cfg-accept-backlog: 128 ds-cfg-allow-ldap-v2: true ds-cfg-keep-stats: true ds-cfg-use-tcp-keep-alive: true ds-cfg-use-tcp-no-delay: true ds-cfg-allow-tcp-reuse-address: true ds-cfg-send-rejection-notice: true ds-cfg-max-request-size: 5 megabytes ds-cfg-max-blocked-write-time-limit: 2 minutes ds-cfg-num-request-handlers: 2 ds-cfg-allow-start-tls: false ds-cfg-use-ssl: false ds-cfg-ssl-client-auth-policy: optional ds-cfg-ssl-cert-nickname: server-cert ds-cfg-denied-client: *.example.com ds-cfg-denied-client: 129.45.*.* ds-cfg-denied-client: 192.168.5.6 dn: cn=LDAPS Connection Handler,cn=Connection Handlers,cn=config objectClass: top objectClass: ds-cfg-connection-handler objectClass: ds-cfg-ldap-connection-handler cn: LDAPS Connection Handler ds-cfg-java-class: org.opends.server.protocols.ldap.LDAPConnectionHandler ds-cfg-enabled: true ds-cfg-listen-address: 0.0.0.0 ds-cfg-listen-port: 636 ds-cfg-accept-backlog: 128 ds-cfg-allow-ldap-v2: true ds-cfg-keep-stats: true ds-cfg-use-tcp-keep-alive: true ds-cfg-use-tcp-no-delay: true ds-cfg-allow-tcp-reuse-address: true ds-cfg-send-rejection-notice: true ds-cfg-max-request-size: 5 megabytes ds-cfg-max-blocked-write-time-limit: 2 minutes ds-cfg-num-request-handlers: 2 ds-cfg-allow-start-tls: false ds-cfg-use-ssl: true ds-cfg-ssl-client-auth-policy: optional ds-cfg-ssl-cert-nickname: server-cert ds-cfg-key-manager-provider: cn=JKS,cn=Key Manager Providers,cn=config ds-cfg-trust-manager-provider: cn=JKS,cn=Trust Manager Providers,cn=config ds-cfg-allowed-client: .example.com ds-cfg-allowed-client: foo.*.test.com ds-cfg-allowed-client: 192.168.6.7/22
dsconfigコマンドを使用して、各接続ハンドラの許可および拒否プロパティを管理します。たとえば:
$ dsconfig -n -X -p 4444 -D "cn=directory manager" -j pwd-file \ set-connection-handler-prop --handler-name "LDAPS Connection Handler" \ --set denied-client:.example.com \ --set allowed-client:192.168.1.6/17
ノート:
拒否ルールは許可ルールの前に適用されます。
26.15 強度無制限の暗号の構成
Java Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルをダウンロードして暗号化サポートを追加し、強度無制限の暗号を構成する必要があります。
強度無制限の暗号を構成するためにポリシー・ファイルをダウンロードおよびインストールするには:
26.16 OUD通信へのOUDSMのTLSプロトコルおよび暗号スイートの構成
Oracle Unified Directoryサーバーがシステム・デフォルト・プロトコルおよび暗号スイートを使用していない場合、OUDSMを構成して、Oracle Unified Directoryサーバーがサポートするプロトコルおよび暗号スイートを使用する必要があります。
安全な通信に使用されるシステム・デフォルト値について学習するには、「Oracle Unified DirectoryがサポートしているTLSプロトコルおよび暗号スイート」を参照してください。