Oracle Unified Directoryには、クライアント/サーバー間の通信を保護するためのメカニズムが複数用意されています。この項のトピックでは、これらのメカニズムの概要と構成方法について説明します。
この章では、次のトピックを取り扱います:
ディレクトリ・データへのアクセスを保護する方法は、第28章「データへのアクセス制御」を参照してください。
プロキシ/ディレクトリ・サーバーまたはデータ・ソース間のセキュリティ構成は、第27章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
Oracle Unified Directoryには、SSLおよびStartTLSを構成し、使用するためのいくつかのオプションが用意されています。構成オプションが豊富だと、テクノロジに不慣れな人やテスト目的で迅速に起動と実行を試したい人は厄介に感じるかもしれません。
この項では、Oracle Unified Directoryが自己署名証明書を使用するSSLベースの接続を受け入れるために実行する必要があるステップをリストします。
この項の手順では、信頼されるキーストアの知識が前提となります。
キーストアの詳細は、第26.2項「キー・マネージャ・プロバイダの構成」を参照してください。
トラスト・ストアの詳細は、第26.3項「信頼マネージャ・プロバイダの構成」を参照してください。
openssl
コマンド行ツールで生成したセキュリティ証明書がすでにある場合、Oracle Unified Directoryで使用するにはキーストアを作成し、証明書を更新する必要があります。
次の例では、次の証明書ファイルがすでに存在します。
ca.crt
認証局公開キー(証明書)
mycert.key
以前に生成した証明書の秘密キー
mycert.crt
以前に生成した証明書の公開キー
既存のセキュリティ証明書を更新するには、次のようにします。
公開キーおよび秘密キーの両方を含むPKCS12キーストアを作成します。
この例では、keystore.p12
が作成するPKCS12キーストアです。
$ openssl pkcs12 -export -out keystore.p12 -inkey mycert.key -in mycert.crt -chain -CAfile ca.crt -password file:<FILE CONTAINING THE PASSWORD FOR THE PKCS12 KEYSTORE>
生成したPKCS12キーストアは、第26.2.3項「PKCS #12キー・マネージャ・プロバイダの使用」に記載されているように使用できます。
または、ステップ2およびステップ3を実行し、証明書をJKSキーストアにインポートして証明書別名を更新します。
PKCS12キーストアから証明書をインポートしてJKSキーストアを作成します。
この例では、keystore.jks
が作成するJKSキーストアです。別名として1
を指定する必要があります。別名はステップ3で必要です。
証明書の別名を更新するが、PKCS12キーストアに証明書を格納し続ける場合、次のkeytool
コマンドを起動する際引数-storetype PKCS12
を追加します。
$ keytool -importkeystore -deststorepass <PASSWORD OF THE JKS KEYSTORE> -destkeypass <PASSWORD OF THE JKS KEY> -destkeystore keystore.jks -srckeystore keystore.p12 -srcstoretype PKCS12 -srcstorepass <PASSWORD OF THE PKCS12 KEYSTORE> -alias 1
証明書の別名を1
からmy-server-cert
に更新します。
証明書の別名を更新するが、PKCS12キーストアに証明書を格納し続ける場合、次のkeytool
コマンドを起動する際引数-storetype PKCS12
を追加します。
$ keytool -changealias -keystore keystore.jks -alias 1 -destalias my-server-cert -storepass <PASSWORD OF THE JKS KEYSTORE>
これでJKSキーストアkeystore.jks
とこれに含まれる証明を使用してキー・マネージャ・プロバイダを構成できます。第26.2.2.4項「JKSキー・マネージャ・プロバイダの構成」を参照してください。
このステップは、インストール時に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
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。サーバーが使用するデフォルト名はserver-cert
です。
-keyalg
アルゴリズム。秘密キーを生成するために使用するアルゴリズムを指定します。これは通常、rsa
です。
-dname
サブジェクト。証明書に使用するサブジェクトを指定します。
環境に合せて、-dname
引数の値を変更します:
CN
属性の値は、証明書がインストールされているシステムの完全修飾名です。
O
属性の値は、社名または組織名です。
C
属性の値は、2文字の国名の省略形です。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。サーバーによって使用されるデフォルトのキーストア・パスは、config/keystore
です。
-keypass
パスワード。キーストア内の秘密キーを保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。たとえば、JKSキーストアの場合、値は常にJKS
です。
キーストアの内容を保護するパスワードと秘密キーを保護するパスワードの入力が要求されます。
キーのための自己署名証明書を生成します。
例:
$ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore -storetype JKS
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypair
オプションを使用して秘密キーを生成したときに指定した値と同一である必要があります。
-validity
日間。証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。
-keypass
パスワード。キーストア内の秘密キーを保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。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
キーストアおよびトラスト・ストアの詳細は、第26.2項「キー・マネージャ・プロバイダの構成」および第26.3項「信頼マネージャ・プロバイダの構成」をそれぞれ参照してください。
これでサーバーはSSLベースのクライアント接続を受け入れる第2のリスナーを持つことになります。ldapsearch
コマンドで、以下のように構成をテストします:
$ ldapsearch --port 1636 --useSSL --baseDN "" --searchScope base "(objectClass=*)"
サーバーの証明書を信頼するかどうか尋ねられます。yes
と入力すると、ルートDSEエントリが戻されます。
キー・マネージャ・プロバイダは、SSLまたはStartTLSネゴシエーションを実行するときにディレクトリ・サーバーによって使用される証明書へのアクセスを提供します。
この項の内容は次のとおりです:
詳細は、Oracle Unified Directoryの構成リファレンスのキー・マネージャ・プロバイダの構成に関する項を参照してください。
Oracle Unified Directoryは、次のキー・マネージャ・プロバイダのキーストア・フォーマットをサポートします:
JKSキーストア、Java Secure Socket Extension (JSSE)によって使用されるデフォルトのキーストア・フォーマット
PKCS #12ファイル
ハードウェア・ベースのデバイス(ハードウェア・セキュリティ・モジュール(HSM)または暗号アクセラレータなど)
PKCS #11デバイス(特定のハードウェア・ベースのキー・マネージャ・プロバイダ)
注意: PKCS #11は、プロキシ・サーバー・インスタンスとの使用がサポートされていません。 |
後続の項で、これらのキー・マネージャ・プロバイダを使用するためのOracle Unified Directoryの構成プロセスについて説明します。
管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様に、管理コネクタにはキー・マネージャが必要です。Oracle Unified Directoryは、管理コネクタ専用のキー・マネージャを提供します。これはデフォルトで有効になっています。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
JKSキーストアは、大半のJSSEの実装で使用されるデフォルトのキーストアであり、多くの環境で優先されるキーストア・タイプです。このキーストア・タイプを使用するようにサーバーを構成するには、まず有効な証明書を含むJKSキーストアを取得する必要があります。これを行うには、自己署名証明書を生成するか、既存の認証局(CA)に証明書署名リクエストを発行して署名された証明書をインポートします。
ここで述べたすべてのステップでkeytool
ユーティリティを使用する必要があります。このユーティリティはJavaランタイム環境に用意されています。このユーティリティは通常、Javaインストール・ディレクトリのルート下のbin
ディレクトリにあります。keytool
ユーティリティの使用法は、Java公式ドキュメント(http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html
)を参照してください。
JKSキー・マネージャ・プロバイダを使用する手順は次のとおりです:
秘密キーを生成します。
証明書に自己署名するか、外部認証局を使用して証明書に署名します。
JKSキー・マネージャ・プロバイダを構成します。
自己署名証明書を使用する場合でも、また証明書署名リクエストを生成する場合でも、まず秘密キーを生成する必要があります。これは、-genkeypair
オプションを指定してkeytool
ユーティリティによって実行できます。このオプションには次の引数を指定できます:
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。サーバーによって使用されるデフォルト名はserver-cert
です。
-keyalg
アルゴリズム。秘密キーを生成するために使用するアルゴリズムを指定します。これは通常、rsa
です。
-dname
サブジェクト。証明書に使用するサブジェクトを指定します。サブジェクトには通常、最低でもCN
属性、O
属性およびC
属性が含まれます。CN属性は証明書がインストールされるシステムの完全修飾名です。O属性は社名または組織名を指定します。Cは証明書が使用される国を指定します。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。ディレクトリ・サーバーによって使用されるデフォルトのキーストア・パスは、config/keystore
です。
-keypass
パスワード。キーストア内の秘密キーを保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKS
です。
以下のように、keytool -genkeypair
コマンドを使用して秘密キーを生成します:
$ keytool -genkeypair -alias server-cert -keyalg rsa \ -dname "CN=server.example.com,O=example.com,C=US" \ -keystore config/keystore -keypass password \ -storetype JKS -storepass password
自己署名証明書の場合は、-selfcert
オプションを使用します。このオプションに使用される最も重要な引数は、次のとおりです:
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypair
オプションを使用して秘密キーを生成したときに指定した値と同一である必要があります。
-validity
日間。証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。
-keypass
パスワード。キーストア内の秘密キーを保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKS
です。
次のように、keytool -selfcert
コマンドを使用して自己署名証明書を生成します:
$ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore -keypass password -storetype JKS \ -storepass password
外部認証局を使用して証明書に署名する場合は、-certreq
オプションを使用して証明書署名リクエスト(CSR)を生成します。認証局にCSRを提出して署名してもらいます。この方法と、署名済証明書を取得する方法は、認証局によって異なる場合があります。
認証局から署名済の証明書を受け取ったら、-importcert
オプションを使用して、それをキーストアにインポートします。
-certreq
オプションを使用して、証明書署名リクエストを取得します。
$ keytool -certreq -alias server-cert -file /tmp/server-cert.csr \ -keystore config/keystore -keypass password -storetype JKS \ -storepass password
このコマンドで使用できる引数は次のとおりです:
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypair
オプションを使用して秘密キーを生成したときに指定した値と同一である必要があります。
-file
パス。CSRを書き込むファイルへのパスを指定します。これを省略すると、リクエストは標準出力に書き込まれます。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。
-keypass
パスワード。キーストア内の秘密キーを保護するためのパスワードを指定します。これを省略すると、入力が求められます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力が求められます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKS
です。
証明書リクエストを外部認証局に送信します。認証局は署名済証明書ファイルを返送します。/tmp/server-cert.txt
にファイルを保存します。
-importcert
を使用して、署名済の証明書をインポートします。
$ keytool -importcert -alias server-cert -file /tmp/server-cert.cert \ -keystore config/keystore -storetype JKS -storepass password
このコマンドで使用できる引数は次のとおりです:
-alias
別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypair
オプションを使用して秘密キーを生成したときに指定した値と同一である必要があります。
-file
パス。署名済証明書を含むファイルへのパスを指定します。ファイルは、DERでエンコードされたバイナリ形式かBase64でエンコードされたASCII形式(RFC 1421 (http://www.ietf.org/rfc/rfc1421.txt
)の記述どおり)である必要があります。
-keystore
パス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。
-storepass
パスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。
-storetype
タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常に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" \ --set "key-store-pin-file:key-store-pwd-file"
第26.2.2.1項「秘密キーの生成」のステップ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の名前および証明書の別名は同じにする必要があります。
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フォーマットの証明書を新規作成するには、第26.2.2項「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 -keypass password \ -storetype PKCS12 -storepass password $ keytool -selfcert -alias server-cert -validity 1825 \ -keystore config/keystore.p12 -keypass password \ -storetype PKCS12 -storepass password
サーバーは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" \ --set "key-store-pin:secret"
構成可能なプロパティの完全なリストは、Oracle Unified Directory構成リファレンスのファイル・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。
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 -storepass password $ keytool -selfcert -alias server-cert -validity 1825 \ -keystore NONE -storetype PKCS11 -storepass password
証明書が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キー・マネージャ・プロバイダの構成に関する項を参照してください。
ハードウェア・ベース・タイプのキー・マネージャ・プロバイダを作成できます。ハードウェア・ベースのキー・マネージャ・プロバイダを使用すると、サーバーでハードウェア・ベースの一般キー・ストアから秘密キー情報にアクセスできます。この標準インタフェースは、暗号アクセラレータおよびハードウェア・セキュリティ・モジュールによって使用されます。
暗号アクセラレータは、このインタフェースを使用して製品による暗号処理を外部ボード(または場合によっては、システムの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.2項「JKSキー・マネージャ・プロバイダの使用」、第26.2.3項「PKCS #12キー・マネージャ・プロバイダの使用」または第26.2.4項「PKCS #11キー・マネージャ・プロバイダの使用」を参照してください。
SSLベースの接続ハンドラ(デフォルト名はLDAPS)のkey-manager-provider
プロパティは、セキュリティに使用すべきキーストア・マネージャを指定します。key-manager-provider
プロパティのデフォルト値は"JKS"で、SSL接続ハンドラがデフォルトでJKSキー・マネージャ・プロバイダを使用することを意味します。別のキー・マネージャ・プロバイダを使用する場合は、SSL接続ハンドラのこのプロパティを適宜変更します。
新しい証明書をインストール後、サーバーを再起動する必要があります。
ODSMの使用により、次のようにキー・マネージャ構成を管理できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」の下の「キー・マネージャ」項目を開きます。
構成するキー・マネージャを選択します。
キー・マネージャの構成可能なプロパティは右側のペインに表示されます。
必要に応じてキー・マネージャの構成を編集し、「適用」をクリックして変更を保存します。
Oracle Unified Directoryは、信頼マネージャ・プロバイダを使用して提出された証明書を信頼するかどうかを決定します。信頼マネージャは、システム全体のセキュリティ上重要な役割を担っています。これはクライアントからのインバウンド接続や別のサーバーへのアウトバウンド接続の相手側システムが申告どおりの本人であることを保障します。
この項の内容は次のとおりです:
信頼マネージャ・プロバイダは、偽造証明書を使用した攻撃や介入者攻撃を防ぐために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は、管理コネクタ専用の信頼マネージャを提供します。これはデフォルトで有効になっています。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
ブラインド信頼マネージャ・プロバイダは、提示されたすべての証明書を信頼する単純なプロバイダです。これは有効期限、証明書の署名者、件名、別名などの条件を確認しません。
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を使用して証明書を認証し、サーバーがクライアントによって提出されるすべての証明書を盲目的に受け入れてしまうと、ユーザーは自己署名証明書を作成して、ディレクトリ内のあらゆるユーザーになりすますことができます。 |
JKSキーストアを使用してキー・マネージャ・プロバイダ用にキー情報を提供できるのと同様に、信頼マネージャ・プロバイダによって使用される情報を提供するために使用することもできます。通常、JKSファイルをトラスト・ストアとして使用するのは、それをキーストアとして使用するのと似ています。ただし、ファイルをトラスト・ストアとして使用するときには秘密キー情報にアクセスしないため、コンテンツにアクセスするときに通常はPINは必要ありません。
JKS信頼マネージャ・プロバイダが、ピアの証明書チェーンを信頼するかどうか判断するときに、2つの要因を検討します:
ピアの証明書が有効期限内かどうか。
チェーン内の証明書が1つ以上トラスト・ストアに含まれているかどうか。
ピアの証明書の有効期限が切れていたり、証明書チェーン内の証明書が1つもトラスト・ストアに含まれていない場合、JKS信頼マネージャによってピアの証明書が拒否されます。
keytool -importcert
ユーティリティを使用して、証明書をJKSトラスト・ストアにインポートします。-importcert
オプションは以下の引数を使用します:
-alias alias
。トラスト・ストア内の証明書に名前を指定します。証明書ごとに一意の名前を指定します。ニックネームは主にトラスト・ストア内の証明書の管理用であり、証明書が信頼されているかどうかに影響を与えません。
-file path
。インポートする証明書を含むファイルへのパスを指定します。ファイルは、DER形式かBase64でエンコードされたASCII形式(RFC 1421 (http://www.ietf.org/rfc/rfc1421.txt
)の記述どおり)である必要があります。
-keystore path
。JKSトラスト・ストアとして使用されるファイルへのパスを指定します。このパスは通常、config/truststore
です。
-storetype type
。トラスト・ストア・ファイルの形式を指定します。JKS信頼マネージャの場合、これはJKS
とする必要があります。
-storepass password
。トラスト・ストアのコンテンツを保護するために使用するパスワードを指定します。トラスト・ストア・ファイルがない場合、この値はトラスト・ストアに割り当てられるパスワードです。これ以降は、このパスワードを使用して、トラスト・ストアと対話する必要があります。このオプションを省略すると、パスワードはユーザーからインタラクティブに要求されます。
証明書をJKSトラスト・ストアにインポートするためのコマンドの例を以下に示します。トラスト・ストアがない場合、このコマンドは証明書をインポートする前にトラスト・ストアを作成します。
$ keytool -importcert -alias server-cert -file /tmp/cert.txt \ -keystore config/truststore -storetype JKS -storepass password
Oracle Unified Directoryには、JKS信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfig
を使用してJKS信頼マネージャ・プロバイダの次のプロパティを構成します:
enabled
。JKS信頼マネージャ・プロバイダが有効かどうかを示します。JKS信頼マネージャ・プロバイダは、このプロパティの値がtrue
の場合を除き、他のサーバー・コンポーネントによって使用されることはありません。
trust-store-file
。トラスト・ストア・ファイルへのパスは通常、config/truststore
ですが、必要に応じて別のファイルを使用することもできます。このプロパティの値は絶対パスかINSTANCE_DIRに対する相対パスです。
trust-store-type
。トラスト・ストアの形式。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'
構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。
PKCS #12信頼マネージャ・プロバイダは主に、PKCS #12ファイルで使用されるピアまたは発行者の証明書をすでに持っている場合に便利です。この形式の証明書を持っていない場合は、かわりにJKS信頼マネージャ・プロバイダを使用します。Java keytool
ユーティリティは現在、信頼された(公開キーのみで秘密キーを持たない)証明書のPKCS #12ファイルへのインポートをサポートしていません。
Oracle Unified Directoryには、PKCS #12信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfig
を使用してPKCS #12信頼マネージャ・プロバイダの次のプロパティを構成します:
enabled
。PKCS #12信頼マネージャ・プロバイダが有効かどうかを示します。信頼マネージャ・プロバイダは、このプロパティの値がtrue
の場合を除き、他のサーバー・コンポーネントによって使用されることはありません。
trust-store-type
。トラスト・ストアの形式を指定します。PKCS #12信頼マネージャ・プロバイダの場合、値はPKCS12
です。
trust-store-file
。トラスト・ストア・ファイルへのパスを指定します。これは通常、config/truststore.p12
ですが、必要に応じて別のファイルを使用することもできます。このプロパティの値は絶対パスかINSTANCE_DIRに対する相対パスです。
PKCS #12ファイルのコンテンツにアクセスするにはPINが必要です。この場合、次の構成属性の1つを使用してパスワードを指定する必要があります。(現在、パスワードはクリア・テキストで指定する必要があります。)
trust-store-pin
。トラスト・ストアに直接アクセスするために必要なPINを指定します。
trust-store-pin-file
。トラスト・ストアにアクセスするために必要なPINを含むファイルへのパスを指定します。このプロパティの値は絶対パスかサーバー・ルートに対する相対パスです。
trust-store-pin-property
。トラスト・ストアへのアクセスに必要なPINが格納されたJavaプロパティの名前を指定します。
trust-store-pin-environment-variable
。トラスト・ストアへのアクセスに必要な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構成リファレンスのファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。
次のようにODSMを使用して、信頼マネージャの構成を管理できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」の下の「信頼マネージャ」項目を開きます。
構成する信頼マネージャを選択します。
信頼マネージャの構成可能なプロパティが右側のペインに表示されます。
必要に応じて、信頼マネージャの構成を編集し、変更を保存するために「適用」をクリックします。
証明書マッパーは、クライアントによって提出された証明書を検査し、その証明書と関連づけられるディレクトリ内のユーザーにそれをマップします。
証明書マッパーは、ディレクトリ・サーバー・インスタンスのみに構成されます。プロキシ・インスタンスやゲートウェイ・インスタンスには構成されません。
証明書マッパーは、主にSASL EXTERNAL認証を処理するために使用されます。クライアントはSASL EXTERNAL認証で、パスワードやその他の形式の資格証明より、SSL証明書を使用してサーバーの認証を受けようとします。
Oracle Unified Directoryはデフォルトで次の証明書マッパーを提供します:
Subject Equals DN
サブジェクト属性からユーザー属性への証明書マッパー
サブジェクトDNからユーザー属性への証明書マッパー
フィンガープリント・マッパー
ユーザーのデプロイ要件に合せて、カスタムの証明書マッパーを作成することもできます。
証明書マッパーは、グローバル・サーバー構成レベルかネットワーク・グループ・レベルかのいずれかで定義されます。証明書マッパーがネットワーク・グループで定義されると、それによってグローバル・サーバー構成で定義された証明書マッパーが置き換えられます。ネットワーク・グループで定義された証明書マッパーがない場合は、グローバル証明書マッパーが使用されます。使用すべき証明書マッパーを定義するには、グローバル構成またはネットワーク・グループのcertificate-mapper
プロパティを設定します。
この項の例では、dsconfig
コマンドを使用して証明書マッパーを変更します。dsconfig
コマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。詳細は、第17.1項「dsconfig
を使用したサーバー構成の管理」を参照してください。
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証明書マッパーは無効にできません。マッパーを無効にするには、前述のとおりデフォルトの証明書マッパーを変更する必要があります。
サブジェクト属性からユーザー属性証明書マッパーは、それらが共通に持つ属性セットに基づいてクライアント証明書をユーザー・エントリにマップします。具体的には、証明書サブジェクトから指定の属性セットの値を取得し、対応する属性セットに同一値を持つユーザー・エントリを検索します。
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人のユーザーと正確に一致させる必要があります。生成された条件と一致するユーザーがいないか、複数のユーザーが一致すると、マッピングは失敗します。
サブジェクト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人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。
フィンガープリント証明書マッパーは、ユーザー・エントリ内の指定された属性で、提出された証明書のMD5またはSHA1フィンガープリントを検索することによってマッピングを確立しようとします。この場合、ユーザー・エントリに、証明書フィンガープリントが移入されるようにする必要があります。フィンガープリントは標準の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人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。
1つ以上の有効なキー・マネージャ・プロバイダとともにOracle Unified Directoryを構成したときに、接続ハンドラにSSLおよびStartTLSを有効にできます。
この項の例では、dsconfig
コマンドを使用してサーバー構成を変更します。dsconfig
コマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。SSL証明書を信頼する方法を含めて、適切な接続オプションを指定する必要があります。これらの例では、-X
オプションを使用してすべての証明書を信頼します。
このセクションには次のトピックが含まれます:
LDAP接続ハンドラは、LDAPを使用したクライアントとのすべての通信の管理に責任を持ちます。デフォルトでは、LDAPプロトコルは通信を保護するためのどのような形のセキュリティも指定しませんが、SSLを使用するか、TLS起動拡張操作の使用を許可するように構成できます。
サーバーは、このために使用できる2つの接続ハンドラを構成します。LDAP接続ハンドラ・エントリがデフォルトで有効にされており、暗号化されていないLDAP通信に使用される場合、StartTLSをサポートするように構成することもできます。詳細は、第26.5.1.7項「StartTLSサポートの有効化」を参照してください。
LDAPS接続ハンドラ・エントリは無効になりますが、SSLベースの通信を有効にするデフォルト構成が設定されます。詳細は、第26.5.1.8項「SSLベースの通信の有効化」を参照してください。
この項では、dsconfig
を使用してLDAPおよびLDAPS接続ハンドラ・パラメータを構成する方法について説明します:
接続ハンドラの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
接続ハンドラのlisten-port
プロパティを設定します。
listen-port
プロパティは、この接続ハンドラを通してサーバーと通信するときに使用するポート番号を指定します。暗号化されていないLDAP通信(またはStartTLSを使用するLDAP)に使用する標準ポートは389
です。SSL暗号化LDAP用の標準ポートは636
です。ただし、環境によっては、これを変更したほうがいい場合や変更する必要がある場合もあります(たとえば、標準ポートがすでに使用されていたり、1024
以下のポートをブラインドできる十分な権限のないユーザーとしてUNIXシステムで実行する場合など)。
この例では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
接続ハンドラの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
接続ハンドラの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
接続ハンドラの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
接続ハンドラの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
StartTLSサポートを有効化するには、次のようにします。
key-manager-provider
およびtrust-manager-provider
プロパティに適切な値を設定します。
allow-start-tls
プロパティを次のようにtrue
に設定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAP Connection Handler" \ --set allow-start-tls:true
注意: SSLが有効だと、allow-start-tls プロパティを設定できません。
StartTLSは、プロキシ・サーバーとリモートLDAPサーバー間の接続ではサポートされません。リモートLDAPサーバーのSSLポリシーの設定によっては、StartTLSクライアント接続がプロキシからリモートLDAPサーバーへのSSL接続または安全でない接続として渡されることがあります。詳細は、第23.7.1.1項「グローバル索引が含まれるグローバル索引カタログの作成」を参照してください。 |
SSLベースの通信を有効化するには、次のようにします。
接続ハンドラのプロパティを表示して、構成されたキー・マネージャ・プロバイダおよび信頼マネージャ・プロバイダの値が正しいことを確認できます。
次の例では、LDAPS接続ハンドラのプロパティを表示します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-connection-handler-prop --handler-name "LDAPS Connection Handler"
enabled
プロパティを次のようにtrue
に設定します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "LDAPS Connection Handler" \ --set enabled:true
注意: SSLが有効だと、接続ハンドラ・インスタンスはSSL以外の通信を使用できません。 |
JMX接続ハンドラは、JMX (Java Management Extensions)プロトコルを使用してクライアントと通信できます。このプロトコルでは、StartTLSを使用して同一ポート上で暗号化通信と非暗号化通信の両方を許可できませんが、暗号化されないJMX通信、またはSSL暗号化JMX通信のいずれか一方を許可するように構成できます。
JMX接続ハンドラは、JMX上の通信のためのサーバーのデフォルト構成を提供します。この接続ハンドラでSSLを有効化するには、dsconfig
を使用して次の構成属性を設定します:
key-manager-provider
。接続ハンドラがSSLネゴシエーションのためのキー情報を取得するために使用するキー・マネージャ・プロバイダの構成エントリのDNを指定します。
ssl-cert-nickname
。クライアントに提出される証明書のニックネーム(または別名)を指定します。
use-ssl
。接続ハンドラが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接続ハンドラの構成に関する項を参照してください。
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メカニズムがサポートされています:
注意: プロキシ・サーバーで現在サポートされている唯一のSASLメカニズムはANONYMOUSです。 |
このメカニズムは実際にはクライアントを認証しませんが、デバッグ用のサーバー・ログにトレース情報を含めるメカニズムを提供します。
このメカニズムは後方互換背のために提供されています。本番環境では、CRAM-MD5を構成しないでください。かわりに、より安全なDIGEST-MD5メカニズムを使用します。
このメカニズムにより、クライアントはサーバーにパスワードを送信せずにパスワードベースの認証を使用できます。そのかわりに、クライアントは単にパスワードを知っているという情報を提供するだけです。このメカニズムはCRAM-MD5より多くのオプションとセキュリティを提供します。
このメカニズムにより、クライアントはLDAP通信の直接のフローの外部で提供される情報に基づき自身を識別できます。Oracle Unified Directoryでは、これはSSLクライアント証明書を使用して可能です。
このメカニズムにより、クライアントはKerberos V5環境への参加を通してサーバーから認証を受けることができます。
このメカニズムはパスワードベースの認証を使用しますが、DNでなくユーザー名を使用できます。
追加のSASLメカニズムのサポートは、サーバーにカスタムのSASLメカニズム・ハンドラを実装することにより追加できます。
SASLメカニズムは非常に拡張性が高いため、認証を実行するためにクライアントがサーバーに提供する必要がある情報はメカニズムごとに異なります。そのため、Oracle Unified Directoryクライアントはユーザー用の汎用インタフェースを使用してこの情報を提供します。これは、-o
または--saslOption
引数を通して公開されます。この引数の値は、名前と値のペアである必要があります。mech
オプションを使用して、使用するSASLメカニズムを選択します。例:
--saslOption mech=DIGEST-MD5
使用可能なその他のオプションは、選択されたSASLメカニズムによって異なります。これについては以下の項で説明します。
以下の多数の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マッピング構成に基づきます。
ANONYMOUSメカニズムは、実際には認証の実行には使用されません。これに追加の必須オプションはありません。ただし、次のオプションを指定できます:
trace
サーバーのアクセス・ログに書き込まれるトレース文字列を指定するために使用します。これはデバッグやクライアントの識別に便利です。ただし、認証せずにこの値の妥当性を信頼することはできません。
次のコマンドはSASL匿名認証の使用例を示します:
$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=ANONYMOUS \ --saslOption "trace=Example Trace String" --baseDN "" \ --searchScope base "(objectClass=*)"
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=*)"
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=*)"
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=*)"
詳細は、第26.7.1項「SASL External認証の構成」を参照してください。
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=*)"
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=*)"
この項では、多様なSASL認証メカニズムを使用するためにディレクトリ・サーバーを構成するための要件について説明します。
注意: SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。 |
SASL EXTERNALメカニズムは、厳密なLDAP通信の外部で提供される情報を使用して、クライアントがサーバーに認証してもらうために使用できます。現在、LDAP通信にかぎり、SSLまたはStartTLSネゴシエーション中にサーバーに提示されたクライアント証明書を使用する認証がサポートされます。
ディレクト・サーバーがクライアント証明書をユーザー・エントリにマッピングするには、クライアント証明書を処理できるように接続ハンドラを構成する必要があります。dsconfig
を使用して次のLDAP接続ハンドラのプロパティを構成します:
ssl-client-auth-policySSLまたは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接続ハンドラの構成に関する項を参照してください。
SASL EXTERNALバインド・リクエストは、SASLメカニズム・ハンドラによって処理されます。dsconfig
コマンドを使用して、次のSASLメカニズム・ハンドラのプロパティを設定します:
java-classSASLメカニズム・ハンドラのロジックを提供する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メカニズム・ハンドラの構成に関する項を参照してください。
この項では、認可IDキーワード(authzid
)を使用するユーザーに対するアクセス制御および権限の制約について説明します。ユーザーがauthzid
キーワードを使用しない場合は、これらの制約は適用されません。DIGEST-MD5およびauthzid
キーワードを使用してバインドするユーザーは、次の要件を満たす必要があります:
認証ID (authid
) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。
認証ID (authid
)エントリには、proxied-auth
権限を含める必要があります。次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。
次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。
次のエントリをディレクトリにインポートします。これらのエントリはACIと3人のユーザーを定義します:
エントリuid=user.0,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ちませんが、ACIによってプロキシ・アクセスが許可されます。
エントリuid=user.1,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ちますが、ACIによってプロキシ・アクセスが許可されません。
エントリuid=user.2,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ち、ACIによってプロキシ・アクセスが許可されます。
dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: posixGroup ou: People aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \ (targetattr="*") (version 3.0; acl "allow SASL Example"; \ allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com || ldap:///uid=user.2,ou=People,dc=example,dc=com";) dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.0 dn: uid=user.1,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for proxy user dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson ... description: This is the description for user.2 ds-privilege-name: proxied-auth
DIGEST-MD5を使用してuid=user.1,ou=People,dc=example,dc=com
としてバインドします:
$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.1,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
uid=user.1,ou=People,dc=example,dc=com
はACIによってプロキシ権限が許可されないため、検索は失敗します。
uid=user.0,ou=People,dc=example,dc=com
としてDIGEST-MD5を使用してバインドします:
$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.0,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
uid=user.0,ou=People,dc=example,dc=com
がproxied-auth
プロパティを持たないため、検索は失敗します。
アクセス制御アクセスとproxied-auth
権限の両方を持つuid=user.2,ou=People,dc=example,dc=com
authidとしてDIGEST-MD5を使用してバインドします:
$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \ --saslOption authid=dn:uid=user.2,ou=People,dc=example,dc=com --saslOption \ authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \ --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top
uid=user.2,ou=People,dc=example,dc=com
はproxied-auth
権限を持ち、ACIによってアクセスが許可されるため、検索は成功します。
この項では、認可IDキーワード(authzid
)を使用するユーザーに対するアクセス制御および権限の制約について説明します。ユーザーがauthzid
キーワードを使用しない場合は、制約は適用されません。
GSSAPIを使用してバインドを実行するユーザーは、次の要件を満たす必要があります:
認証ID (authid
) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。
認証ID (authid
)エントリには、proxied-auth
権限を含める必要があります。
次の例では3つのサンプル・エントリを含むテスト環境を作成し、GSSAPI SASLメカニズムを使用したユーザー認証の要件を示します。これらの例では、有効なキータブ・ファイルを含めて完全に構成されたKerberos環境が必要です。
レルムTESTLOCAL.NET
内に3つのKerberosプリンシパルを作成します:
user.0@TESTLOCAL.NET
user.1@TESTLOCAL.NET
user.2@TESTLOCAL.NET
GSSAPI SASLハンドラを構成して有効にし、正規表現アイデンティティ・マッパーを使用し、有効なTESTLOCAL.NETキータブ・ファイルを使用できるようにします。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-sasl-mechanism-handler-prop --handler-name "GSSAPI" \ --set enabled:true --set identity-mapper:"Regular Expression" \ --set keytab:keytabPath
GSSAPIのenabled
プロパティのデフォルト値はfalse
です。これをtrue
に設定する必要があります。identity-mapper
のデフォルト値はRegular Expressionです。keytab
プロパティのデフォルト値は/etc/krb5/krb5.keytab
です。
次のエントリをディレクトリにインポートします。これらのエントリはACIと3人のユーザーを定義します:
エントリuid=user.0,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ちませんが、ACIによってプロキシ・アクセスが許可されます。
エントリuid=user.1,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ちますが、ACIによってプロキシ・アクセスが許可されません。
エントリuid=user.2,ou=People,dc=example,dc=com
は、proxied-auth
権限を持ち、ACIによってプロキシ・アクセスが許可されます。
dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: posixGroup ou: People aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \ (targetattr="*") (version 3.0; acl "allow SASL Example"; \ allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com" || "ldap:///uid=user.2,ou=People,dc=example,dc=com";) dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.0 ... description: This is the description for user.0 dn: uid=user.1,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.1 ... description: This is the description for user.1 ds-privilege-name: proxied-auth dn: uid=user.2,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=user.2 ... description: This is the description for user.2 ds-privilege-name: proxied-auth dn: uid=proxy user,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson uid=proxy user ... description: This is the description for proxy user
このコマンドを実行すると、Kerberosプリンシパルuser.0@TESTLOCAL.NET
を使用するGSSAPI SASLバインドが失敗します:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.0@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
user.0@TESTLOCAL.NET
がuid=user.0,ou=People,dc=example,dc=com
にマッピングされますが、これにはuid=proxy user,ou=People,dc=example,dc=com
へのアクセス制御権限はあっても、proxied-auth
権限がないため、この検索は失敗します。
このコマンドを実行すると、Kerberosプリンシパルuser.1@TESTLOCAL.NET
を使用するGSSAPI SASLバインドが失敗します。
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.1@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)
user.1@TESTLOCAL.NET
がuid=user.1,ou=People,dc=example,dc=com
にマッピングされますが、これにはproxied-auth
権限はあってもuid=proxy user,ou=People,dc=example,dc=com
へのアクセス制御権限がないため検索は失敗します。
このコマンドを実行すると、Kerberosプリンシパルuser.2@TESTLOCAL.NET
を使用するGSSAPI SASLバインドが成功します:
$ ldapsearch --port 1389 \ --saslOption mech=GSSAPI \ --saslOption authid=user.2@TESTLOCAL.NET \ --saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \ --baseDN "" --searchScope base "(objectClass=*)" dn: objectClass: ds-root-dse objectClass: top }}} \\ \\
user.2@TESTLOCAL.NET
がuid=user.2,ou=People,dc=example,dc=com
にマッピングされますが、これにはproxied-auth
権限とid=proxy user,ou=People,dc=example,dc=com
へのアクセス制御権限の両方があるため検索は成功します。
次の項ではGSSAPI SASL認証のためのKerberos Version 5の構成について説明します。
LDAPクライアントを実行するホスト・マシンでKerberos V5を構成する必要があります。
インストール手順に従ってKerberos V5をインストールします。
注意: 以前はSun Enterprise Authentication Mechanism 1.0.1クライアント・ソフトウェアをインストールすることが推奨されていました。Oracle Solarisリリース10から、必要なSun Enterprise Authentication Mechanism 1.0.1クライアント・ソフトウェア・コンポーネントがSolarisに組み込まれました。Oracle Solarisリリース10以上を使用する場合、クライアント・ソフトウェアのインストールは必要なくなりました。 |
Kerberosソフトウェアを構成します。
Solarisの場合: Sun Enterprise Authentication Mechanismソフトウェアを使用して、/etc/krb5
の下のファイルを構成します。この構成は、kdc
サーバーを設定し、デフォルト・レルムとKerberosシステムが必要とするその他の構成を定義します。
リストされた最初の値がkerberos_v5
となるように/etc/gss/mech
ファイルを変更します。
Kerberosのインストール時には適切なSASLオプションを指定する必要があります。
GSSAPIメカニズムで有効にするクライアント・アプリケーションを使用する前に、ユーザーのプリンシパルでKerberosセキュリティ・システムを初期化します。
$ kinit user-principal
ここで、user-principalは、ご使用のSASLアイデンティティです。たとえば、bjensen@example.com
となります。
Kerberosの使用を設定するSASLオプションを指定します。
UNIX環境では、SASL_PATH
環境変数をSASLライブラリの正しいパスに設定する必要があります。Kornシェルでの設定例は次のようになります:
$ export SASL_PATH=SASL-library
このパスは、LDAPツールが起動されたホストと同じホストにOracle Unified Directoryソフトウェアがインストールされていることを前提としています。
次に示すldapsearch
ツールの例は、-o
(小文字のo)オプションを使用してKerberosの使用を設定するSASLオプションを指定する方法を示しています:
$ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \ -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"
authid
は、kinit
コマンドによって初期化されたKerberosキャッシュに含まれるので、省略できます。authid
を指定する場合、プロキシ操作を対象とするauthzid
は使用されませんが、authid
とauthzid
にはどちらにも同じ値を指定する必要があります。authid
の値は、アイデンティティ・マッピングで使用されるプリンシパルです。レルムを含み、プリンシパルはすべて完全なプリンシパルである必要があります。
Oracle Unified Directoryディレクトリ・サーバー用のKerberosの構成は複雑な場合があります。最初にKerberosのマニュアルを参照してください。
さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合せて手順を変更してください。
Solaris OSでのKerberosの構成と使用の詳細は、システム管理ガイド: セキュリティ・サービスを参照してください。このマニュアルはSolarisマニュアル・セットの一部です。マニュアル・ページを参照することもできます。
この例についての情報と使用するステップは、次のとおりです:
この手順例では、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アイデンティティ・マッピングを使用する必要があります。
/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-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 }
/etc/krb5/kadm5.acl
構成ファイル内の"___default_realm___"
を"EXAMPLE.COM"
に置き換えます。更新されたファイルは、次の例のようになります。
/etc/krb5/kdc.conf
ファイルを編集して、"___default_realm___"
を"EXAMPLE.COM"
に置き換えます。更新されたファイルは、次の例のようになります。
例26-3 編集後の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 }
$/usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing 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:password
Re-enter KDC database master key to verify:password
$
次のコマンドを使用して、kws/admin@EXAMPLE.COM
というプリンシパルの管理ユーザーと、管理デーモンによって使用されるサービス・キーを作成します。
$/usr/sbin/kadmin.local
kadmin.local:add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM":secret
Re-enter password for principal "kws/admin@EXAMPLE.COM":secret
Principal "kws/admin@EXAMPLE.COM" created. kadmin.local:ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry 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.com
Entry 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/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:quit
$
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
と表示されます。
KDCのKerberosデータベースとディレクトリ・サーバー・マシンにホスト・プリンシパルを追加するには、次の一連のコマンドを使用します。ホスト・プリンシパルは、klist
などの特定のKerberosユーティリティによって使用されます。
$ /usr/sbin/kadmin -p kws/admin
Enter Password:secret
kadmin:add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created. kadmin:ktadd host/kdc.example.com
Entry 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.com
Principal "host/directory.example.com@EXAMPLE.COM" created. kadmin:ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin:quit
$
ディレクトリ・サーバーで認証中のユーザーが保持する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/admin
Enter Password:secret
kadmin:add_principal -randkey ldap/directory.example.com
Principal "ldap/directory.example.com@EXAMPLE.COM" created. kadmin:quit
$
Kerberos認証を実行するには、Kerberosデータベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名をkerberos-test
にします。つまりKerberosプリンシパルがkerberos-test@EXAMPLE.COM
になります。
この例の一連のコマンドを使用してユーザーを作成します:
$/usr/sbin/kadmin -p kws/admin
Enter Password:secret
kadmin:add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM":secret
Re-enter password for principal "kerberos-test@EXAMPLE.COM":secret
Principal "kerberos-test@EXAMPLE.COM" created. kadmin:quit
$
Oracle Unified Directoryをインストールします。次の表に、この項の例で使用するインストール設定を示します。
変数タイプ | サンプル値 |
---|---|
ディレクトリ・サーバーの完全修飾DNS名 | directory.example.com |
サーバー・ポート | 389 |
接尾辞 | dc=example,dc=com |
インストール・ディレクトリ | /asinst_1/oud |
Oracle Unified Directoryサーバー・ユーザー | oud |
Oracle Unified Directoryサーバー・グループ | oud |
Kerberosテスト・プリンシパル | kerberos-test |
Oracle Unified Directoryキータブ・パス | /asinst_1/oud/config/oud.keytab |
注意: ディレクトリ・サーバーの完全修飾DNS名は、すべてのサーバー(Oracle Unified Directoryサーバー、Kerberos Key Distribution Center (KDC)、およびGSSAPI SASLを使用してサーバーにバインドする予定のクライアント・マシン)上で同一IPアドレスに変換される必要があります。 |
これまでに説明したように、GSSAPIによってKerberosユーザーを認証するには、Oracle Unified DirectoryはKDC内に独自のプリンシパルを持つ必要があります。プリンシパル情報は、ディレクトリ・サーバー・マシン上のKerberosキータブ内に格納されている必要があります。この情報は、ディレクトリ・サーバーが動作するユーザー・アカウントが参照できるファイル内にある必要があります。
注意: このステップは、GSSAPI SASL mechanism handler を構成する前に実行する必要があります。ハンドラは初期化する前にキータブ・ファイルが存在することを確認します。 |
正しいプロパティを持つキータブ・ファイルを作成するには、次の一連のコマンドを使用します:
$kadmin -p kws/admin@EXAMPLE.COM
kadmin: 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.com
Entry 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
これらの変更を有効にするには、ディレクトリ・サーバーを停止し、再起動する必要があります。
このステップでは、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
Kerberosユーザーをディレクトリ・サーバーに対して認証するには、そのユーザーのKerberosプリンシパルに対応する、ユーザーのディレクトリ・エントリが必要です。
これまでのステップで、kerberos-test@EXAMPLE.COM
というプリンシパルを持つテスト・ユーザーがKerberosデータベースに追加されました。ディレクトリに追加されたアイデンティティ・マッピング構成のために、そのユーザーに対応するディレクトリ・エントリには、uid=kerberos-test,ou=People,dc=example,dc=com
というDNが必要です。
ユーザーをディレクトリに追加する前に、次の内容でファイルtestuser.ldif
を作成する必要があります。
例26-4 新しい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
$
テスト・ユーザーは、Kerberosデータベース、ディレクトリ・サーバーおよびKDC内に存在します。このため、ディレクトリ・サーバーのテスト・ユーザーとしてGSSAPIを経由したKerberosによって認証できます。
まず、kinit
コマンドを使用してユーザーのKerberosチケットを取得します。次の例を参照してください:
$kinit kerberos-test
Password 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
$
最後のステップは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"
は、このバインドが適切なユーザーとして実行されたことを示しています。
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 \
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
ldapsearch
によるSSL、StartTLS、およびSASL認証のテストディレクトリ・サーバーに用意されているldapsearch
ユーティリティは、サーバーがSSLおよびStartTLSをサポートするために正しく構成されていることをテストするときに便利です。このユーティリティには、様々な状況下でのテストに適したオプションがいくつか含まれています。この項では、ldapsearch
を使用してSSLおよびStartTLS通信、SASL EXTERNAL認証をテストする方法を説明します。ldapmodify
、ldapcompare
およびldapdelete
など、ディレクトリ・サーバーで提供されているその他の多数のクライアント・ツールで同一プロセスを使用できます。
次のコマンド行引数は、特にldapsearch
ツールを使用してSSLまたはStartTLSを介して通信するときに重要です。
-h address
または--hostname address
は、接続先のディレクトリ・サーバーのアドレスを指定します。値を省略すると、IPv4ループバック・アドレス(127.0.0.1
)が使用されます。
-p port
または--port port
は、ディレクトリ・サーバーが接続のためにリッスンするポート番号を指定します。値を省略すると、標準の暗号化されていないLDAPポート(389
)が使用されます。
-Z
または--useSSL
は、ディレクトリ・サーバーとの安全な通信のためにクライアントはSSLを使用する必要があることを示します。このオプションを使用する場合は、ポート引数に指定した値がSSLベースの接続をサーバーがリッスンするポートである必要があります。デフォルトのLDAPSポートは、636
です。
-q
または--startTLS
は、ディレクトリ・サーバーとの通信を保護するためにクライアントはStartTLS拡張操作を使用する必要があることを示します。このオプションを使用する場合は、ポート引数に指定した値がクリアテキストLDAP接続をサーバーがリッスンするポートである必要があります。
サーバーがデフォルトのLDAPポート(389
)をリッスンする場合、ポート引数は必要ありません。
-r
または--useSASLExternal
は、ディレクトリ・サーバーとの安全な通信のためにクライアントはSASL EXTERNAL認証を使用する必要があることを示します。このオプションを使用する場合は、キーストア・パスも指定する必要があります。
-X
または--trustAll
は、クライアントがディレクトリ・サーバーによって提出されるすべての証明書を盲目的に信頼する必要があることを示します。このオプションは、トラスト・ストア・パスの指定に使用される引数と一緒に使用しないでください。
-K path
または--keyStorePath path
は、クライアントがディレクトリ・サーバーに証明書を提出する場合に使用する必要があるキーストアへのパスを指定します(たとえば、SASL EXTERNAL認証を使用するときなど)。これはJKSキーストアへのパスです。
-W password
または--keyStorePassword password
は、キーストアのコンテンツへのアクセスに必要なPINを指定します。このオプションは、キーストア・パスワード・ファイル引数と一緒に使用しないでください。
--keyStorePasswordFile path
は、キーストアのコンテンツへのアクセスに必要なPINを含むファイルへのパスを指定します。このオプションは、キーストア・パスワード引数と一緒に使用しないでください。
-N nickname
または--certNickname nickname
は、クライアントがディレクトリ・サーバーに提出する必要がある証明書のニックネームまたは別名を指定します。キーストア・パス引数も指定する必要があります。ニックネームを省略すると、クライアントはキーストア内で見つけた最初の受け入れ可能なクライアント証明書を使用します。
-P path
または--trustStorePath path
は、クライアントがディレクトリ・サーバーによって提出された証明書を信頼するかどうか判断するときに使用するJKSトラスト・ストア・ファイルへのパスを指定します。この引数とtrustAll
オプションが省略されると、クライアントに提出されるすべての証明書が表示され、それを信頼するかどうかユーザーが尋ねられます。
--trustStorePassword password
は、トラスト・ストアのコンテンツにアクセスするためのパスワードを指定します。通常、トラスト・ストア・パスワードは必要ありません。このオプションは、トラスト・ストア・パスワード・ファイル・オプションと一緒に使用しないでください。
--trustStorePasswordFile path
は、トラスト・ストア・コンテンツへのアクセスに必要なパスワードを含むファイルへのパスを指定します。通常、トラスト・ストア・パスワードは必要ありません。このオプションは、トラスト・ストア・パスワード・オプションと一緒に使用しないでください。
-E
または--reportAuthzID
は、ディレクトリ・サーバーがバインド・レスポンスの中の認証済ユーザーの認可IDを含む必要があることを示します。これはSASL認証を実行して、クライアント証明書(またはEXTERNAL以外のメカニズムが使用された場合は、その他の形式のSASL資格証明)がマッピングされるユーザーを判断するのに役立ちます。
ldapsearch
を使用してLDAP over SSLを通してディレクトリ・サーバーと通信する例を以下に示します:
$ 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=*)"
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
で置き換えます。
注意: SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。 |
SASL EXTERNAL認証は、SSLまたはStartTLSとともに使用できます。主な相違点は、クライアント証明書を含むキーストア、そのキーストアのコンテンツにアクセスする必要があるPIN、およびクライアントがSASL EXTERNAL認証を使用する必要があることを示すフラグを指定する必要があることです。次の例では、このようなコマンドの使用例を示します:
$ 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
s_client
テスト・ユーティリティを使用したSSLのデバッグOpenSSLは、SSLサーバーをデバッグするための有益で便利な診断ツールs_client
を提供します。このコマンドは、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を除外する方法を説明します。
このセクションには次のトピックが含まれます:
割り当てられたSSLポートでSSLクライアントに接続しようとしても接続できません。次に、このシナリオの例を示します:
openssl s_client -connect localhost:<ldaps_portnumber> connect: Connection refused connect:errno=146
解決策
解決策として、config.ldifファイルのLDAPS番号が正しい値かどうか確認してください。
エラー・コード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証明書をサーバーのキーストアにインポートする必要があります。
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)
セキュアなサーバー接続を確立しようとすると、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)
解決策
問題解決のために次のステップを実行します:
CA証明書をサーバーのキーストアにインポートします。
keytool -importcert -alias ca-cert -keystore config/keystore -storetype JKS -file $CA_SSL/ca-cert.pem Enter keystore password: Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Serial number: 96b69e65 Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428 Certificate fingerprints: MD5: D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4 SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03 Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore
署名済のサーバー証明書応答をサーバーのキーストアにインポートします。
keytool -importcert -trustcacerts -alias server-cert -keystore config/keystore -storetype JKS -file server-cert.pem Enter keystore password: Certificate reply was installed in keystore
LDAPサーバー・キーストア内の証明書をリストします。
keytool -list -keystore config/keystore -storepass secret12 -v Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Alias name: ca-cert Creation date: Jan 18, 2012 Entry type: trustedCertEntry Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Serial number: 96b69e65 Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428 Certificate fingerprints: MD5: D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4 SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03 Signature algorithm name: SHA1withRSA Version: 3
SSL上でldapsearch
リクエストを使用して接続を検証します。
ldapsearch -p 7636 -D "cn=Directory Manager" -w secret12 -P config/truststore -Z -b dc=example,dc=com uid=user.0 dn: uid=user.0,ou=People,dc=example,dc=com postalAddress: Aaccf Amar$01251 Chestnut Street$Panama City, DE 50369 postalCode: 50369 uid: user.0 description: This is the description for Aaccf Amar. userPassword: {SSHA}vVIy4fjEUyt0L8GSVzX+VrJKEgGASLkeCvL1ng== employeeNumber: 0 initials: ASA givenName: Aaccf objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top pager: +1 779 041 6341 mobile: +1 010 154 3228 cn: Aaccf Amar telephoneNumber: +1 685 622 6202 sn: Amar street: 01251 Chestnut Street homePhone: +1 225 216 5900 mail: user.0@maildomain.net l: Panama City st: DE
ログにアクセスします。
[18/Jan/2012:16:39:24 +0100] CONNECT conn=1 from=127.0.0.1:46726 to=127.0.0.1:7636 protocol=LDAPS [18/Jan/2012:16:39:24 +0100] BIND REQ conn=1 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager" [18/Jan/2012:16:39:24 +0100] BIND RES conn=1 op=0 msgID=1 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=31 [18/Jan/2012:16:39:24 +0100] SEARCH REQ conn=1 op=1 msgID=2 base="dc=example,dc=com" scope=wholeSubtree filter="(uid=user.0)" attrs="ALL" [18/Jan/2012:16:39:24 +0100] SEARCH RES conn=1 op=1 msgID=2 result=0 nentries=1 etime=18 [18/Jan/2012:16:39:24 +0100] UNBIND REQ conn=1 op=2 msgID=3 [18/Jan/2012:16:39:24 +0100] DISCONNECT conn=1 reason="Client Disconnect"
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"
クライアント証明書が有効な証明書チェーンでない場合に、このエラーが表示されます。
解決策
この問題を解決するには、次のステップを実行します:
CA証明書をクライアントのキーストアにインポートします。
keytool -importcert -alias ca-cert -keystore config/keystore \ -storetype JKS -file $CA_SSL/ca-cert.pem Enter keystore password: Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR Serial number: 96b69e65 Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428 Certificate fingerprints: MD5: D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4 SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03 Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore
ユーザー署名済の応答証明書をクライアントのキーストアにインポートします。
keytool -importcert -trustcacerts -alias user.41-cert -keystore config/keystore -storetype JKS -file user.41-cert.pem -storepass secret12 Certificate reply was installed in keystore
ldap
コマンドを実行します。
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 dn: uid=user.0,ou=People,dc=example,dc=com postalAddress: Aaccf Amar$01251 Chestnut Street$Panama City, DE 50369 postalCode: 50369 uid: user.0 description: This is the description for Aaccf Amar. employeeNumber: 0 initials: ASA givenName: Aaccf objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top pager: +1 779 041 6341 mobile: +1 010 154 3228 cn: Aaccf Amar telephoneNumber: +1 685 622 6202 sn: Amar street: 01251 Chestnut Street homePhone: +1 225 216 5900 mail: user.0@maildomain.net l: Panama City st: DE
ログを検証します。
[18/Jan/2012:18:04:49 +0100] CONNECT conn=3 from=127.0.0.1:46777 to=127.0.0.1:7636 protocol=LDAPS [18/Jan/2012:18:04:49 +0100] BIND REQ conn=3 op=0 msgID=1 type=SASL mechanism=EXTERNAL dn="" [18/Jan/2012:18:04:49 +0100] BIND RES conn=3 op=0 msgID=1 result=0 authDN="uid=user.41,ou=People,dc=example,dc=com" etime=37 [18/Jan/2012:18:04:49 +0100] SEARCH REQ conn=3 op=1 msgID=2 base="dc=example,dc=com" scope=wholeSubtree filter="(uid=user.0)" attrs="ALL" [18/Jan/2012:18:04:49 +0100] SEARCH RES conn=3 op=1 msgID=2 result=0 nentries=1 etime=15 [18/Jan/2012:18:04:49 +0100] UNBIND REQ conn=3 op=2 msgID=3 [18/Jan/2012:18:04:49 +0100] DISCONNECT conn=3 reason="Client Disconnect"
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デバッグ記録の使用法について説明します。この項の内容は次のとおりです:
次のステップを実行して、SSLデバッグ記録を有効化します:
config/java.properties
ファイルのstart-ds.java-argsプロパティを次の情報で更新します:
start-ds.java-args=-server -Djavax.net.debug=all
第A.2.5項「dsjavaproperties」
の手順に従ってdsjavapropertiesコマンドを実行します。
stop-ds
コマンドを使用してサーバー・インスタンスを停止します。
start-ds
コマンドを使用してサーバー・インスタンスを再起動します。
注意: SSLデバッグ情報は、logs/server.outファイルにログされます。 |
次のステップを実行して、SSLデバッグ記録を無効化します:
java.propertiesファイルから-Djavax.net.debug=all
プロパティを削除します。
start-ds.java-args=-server
第A.2.5項「dsjavaproperties」
の手順に従ってdsjavapropertiesコマンドを実行します。
stop-ds
コマンドを使用してサーバー・インスタンスを停止します。
start-ds
コマンドを使用してサーバー・インスタンスを再起動します。
接続ハンドラの許可または拒否されたクライアント・ルールを使用して、どのホストがサーバーへのTCP接続を確立できるか管理します。接続ハンドラは、サーバーへの接続の受け入れに責任を持ちます。
この項に示された異なる種類の接続ハンドラとその構成プロパティは次のとおりです:
allowed-client
。この接続ハンドラへの接続の確立を許可されているクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。
denied-client
。この接続ハンドラへの接続の確立を許可されていないクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。許可と拒否の両方のクライアント・マスクが定義され、クライアント接続が両方のリストの中の1つ以上のマスクと一致すると、接続は拒否されます。拒否リストのみ指定された場合、そのリストの中のマスクと一致しないクライアントはすべて許可されます。
注意: IPv4とIPv6の両方のアドレスがサポートされています。 |
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プロパティを使用するときには注意してください。 |
接続ハンドラは、それぞれに独自のルール・セットを持つ必要があります。例:
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
注意: 拒否ルールは許可ルールの前に適用されます。 |
強度無制限の暗号を構成するには、Java Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルをダウンロードして、暗号化サポートを追加する必要があります。次のステップに従って、ポリシー・ファイルのダウンロードとインストールを実行し、強度無制限の暗号を構成します:
次のWebページからJava Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルをダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html
ダウンロードされたzipファイルに含まれるREADME.txtファイルの説明に従ってインストールを実行します。
Java Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルがインストールされます。
Oracle Unified Directoryサーバーを停止した後、再起動します。