この章では、Directory Server および Directory Proxy Server のデータ管理に関する問題のトラブルシューティングに役立つ情報を示します。
この章の内容は次のとおりです。
ここでは、LDAP 操作エラーのトラブルシューティング方法を示します。操作エラーの考えられる原因、トラブルシューティングのために収集する情報、この情報を分析する方法について説明します。
操作は次の理由で失敗することがあります。
ACI が、操作が許可されていない場所にある
リフェラルが別のサーバーを参照している
データベースが更新時にリフェラルに設定されたため、更新を続行できない
データベースが再インポートされている
オンライン設定が許可されていない
ACI が問題の原因であるかどうかを確認するには、サフィックスレベルから、アクセスしようとしているエントリまでの、すべての ACI に関する情報を収集します。このデータは、次のように、ldapsearch 操作を使用して収集します。
# ldapsearch -D cn=Directory Manager -b base-suffix dn aci |
操作が含まれるアクセスログファイルとエラーログファイルを収集します。必ず ACI ログレベルを有効にしてください。次のように入力して、エラーログファイルの ACI ログレベルを有効にします。
# dsconf set-log-prop errors level:err-acl |
次のように入力して、アクセスログファイルの ACI ログレベルを有効にします。
# dsconf set-log-prop access level:acc-internal |
エラーログの内容を表示するには、dsadm コマンドを次のように実行します。
dsadm show-error-log -A duration [-L last-lines] install-path |
-A オプションは、ログから返される行の最長有効期間を指定します。たとえば、24 時間未満のすべてのエントリを検索するには、-A 24h と指定します。-L オプションは、ログから返される最大行数を指定します。たとえば、最後の 50 行を返すには、-L 50 と指定します。デフォルトでは 20 行返されます。
アクセスログの内容を表示するには、dsadm コマンドを次のように使用します。
dsadm show-access-log -A duration [-L last-lines] install-path |
ログファイル自体は次のディレクトリ内にあります。
instance-path/logs/errors* instance-path/logs/access* |
問題を自分でトラブルシューティングできない場合は、データベースにアクセスできなかった期間のエラーログファイルとアクセスログファイルを収集し、分析のためにそれらのファイルを Sun サポートに送信してください。デフォルトでは、ログファイルは instance-path/logs ディレクトリ内にあります。エラーログとアクセスログへのパスを見つけるには、次のコマンドを使用します。
# dsconf get-log-prop ERROR path |
または、
# dsconf get-log-prop ACCESS path |
この節は、SSL 接続が失敗したときのトラブルシューティングに役立ちます。この章は、次の各節で構成されています。
この章の内容は次のとおりです。
Identity Synchronization for Windows での SSL の問題のトラブルシューティングについては、「SSL を介した Identity Synchronization for Windows に関する問題のトラブルシューティング」を参照してください。
ここでは、Directory Server マルチマスターレプリケーションでの SSL の使用に関する問題のトラブルシューティングに役立つ概念について説明します。SSL の問題は、常にサプライヤ側で発生します。エラーログにセキュリティー関連のメッセージが記録されます。たとえば、「SSL init failed. (SSL の初期化に失敗しました)」や「Certificate not accepted. (証明書が受け入れられません)」などです。
SSL 接続には常に次の二者が関与します。
SSL クライアント。LDAP 要求を送信する LDAP クライアント、またはレプリケーション更新を送信する Directory Server (サプライヤ)。
SSL サーバー。LDAP 要求を受け入れる Directory Server (コンシューマ)。
SSL クライアントは要求を開始し、SSL サーバーは常に要求を受信します。この交換の際、SSL サーバーが資格を提供する必要があります。SSL サーバーは、SSL クライアントから送信される資格を検証する必要があります。この検証を行うためには、ピアの証明書データベースに、他方のピアから送信された証明書の CA 証明書が含まれている必要があります。
レプリケーションでは、SSL 以外の操作のみを受け入れるマスターレプリカも含むすべてのレプリカで、SSL が有効である必要があります。たとえば、マスターサーバーは、SSL を使用してハブサーバーと通信します。ハブは SSL ポート上で待機する必要があります。マスターは SSL クライアントであるため、SSL ポート上で待機する必要はありません。ただし、その場合でも SSL ポートを定義する必要があります。定義しないと、Directory Server は、ホストサーバーとの通信で SSL 証明書の交換を開始することができません。
デフォルトでは、SSL はすべての Directory Server 6.x インスタンス上で有効になります。SSL の機能の詳しい説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Secure Sockets Layer (SSL)」を参照してください。
SSL 接続の障害は、次のいずれかの状況の結果として生じる可能性があります。
適用されたセキュリティーライブラリのパッチファミリが誤っている
サーバーが SSL を受け入れるように設定されていない
SSL ポートが開いていない
CA 証明書が見つからない
CA 証明書が適切でないか、または期限切れである
要求されたときに SSL クライアントが証明書を送信しない
SSL サーバー証明書がインポートされていない
ここでは、SSL によるレプリケーションの問題など、SSL に関する問題のトラブルシューティングに役立つデータの収集と分析に関する情報を示します。
Mozilla の Web サイトで、SSL の問題のデバッグとトラブルシューティングに役立つ NSS セキュリティーツールを提供しています。これらのツールのソースコードは、http://www.mozilla.org/projects/security/pki/nss/tools で入手できます。このツールボックスには、certutil および ssltap という 2 つのツールが含まれています。
certutil ツールでは、証明書データベースに格納されたすべての証明書を表示したり、単一の証明書の詳細を表示したりできます。このプログラムを使用しているときに証明書データベースのデータが変更または削除される可能性があるため、元の証明書データベースのコピーで certutil ツールを実行することをお勧めします。
certutil ツールを使用するには、パスワードを入力する必要があります。ただし、dsadm create コマンドでは、取得することができないデフォルトの証明書データベースパスワードが生成されます。certutil ツールを使用するには、dsadm set-flags instance-path cert-pwd-prompt=on コマンドを使用して、証明書データベースパスワードを変更します。
ssltap ツールでは、2 つのシステム間の SSL 通信を取得できます。ssltap プログラムは、Directory Server からの接続と LDAP クライアントの間に配置する必要があります。このプログラムは、LDAP クライアントと通信しているときは Directory Server のように動作し、Directory Server と通信しているときは LDAP クライアントのように動作します。
証明書データベースは instance-path/alias ディレクトリ内にあります。問題に関係のあるサーバーごとに、このディレクトリの内容を取得します。
たとえば、ns-slapd 証明書 (u,, という信頼フラグの付いた証明書) として使用できる証明書の一覧を表示するには、dsadm コマンドを次のように実行します。
dsadm list-certs instance-path |
このコマンドでは、defaultCert などの証明書、それが有効になる日付、期限切れになる日付、自己署名付きかどうか、発行者、発行先の一覧が表示されます。
有効で信頼できる CA 証明書 (CT,, という信頼フラグの付いた証明書) に関する情報を表示するには、dsadm コマンドを次のように実行します。
dsadm list-certs --ca instance-path |
このコマンドで、証明書エイリアス、それが有効になる日付と期限切れの日付、組み込まれているかどうか、発行者、発行先が表示されます。SSL サーバーおよびクライアントの証明書が、このコマンドの出力に含まれる認証局によって生成されていることを確認します。
特定の証明書に関する詳細情報については、dsadm コマンドを次のように実行します。
dsadm show-cert instance-path certificate-alias |
たとえば、このコマンドの出力は次のようになります。
server1 [/var/dsee/instances]> dsadm show-cert ds1 defaultCert Certificate: Data: Version: 3 (0x2) Serial Number: 00:85:8b:13:ef Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=server1,CN=Directory Server,O=example.com" Validity: Not Before: Fri Mar 23 14:10:51 2007 Not After : Sat Jun 23 14:10:51 2007 Subject: "CN=server1,CN=Directory Server,O=example.com" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: 9a:c9:52:bd:ec:32:43:1a:39:96:90:02:f5:7e:18:45: 78:37:ca:8d:8f:c4:cc:6f:d1:7e:6c:38:d1:a1:53:41: 96:67:07:c7:c8:56:78:d1:f2:24:df:1f:eb:b2:07:5d: 6e:1f:58:fa:7a:f2:00:e4:95:d1:57:97:37:9d:22:31: 1c:b7:99:29:df:a3:8a:2a:87:e1:8b:54:ea:1f:7c:b7: 28:23:ce:be:7e:73:b3:87:f5:32:88:56:4e:58:68:f6: f6:01:2c:51:ca:07:00:40:ca:b3:9e:33:40:e8:f2:18: bc:16:d4:ac:ae:69:a7:c9:d7:g5:34:d4:87:11:2c:b1 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 29:76:4f:9f:ca:00:09:7b:05:ac:0f:26:6f:d1:93:aa: a8:c0:eb:a9:2a:39:e2:6e:08:0a:90:41:e5:7f:18:4a: 17:05:03:04:9b:ee:0a:dc:3c:ef:ee:aa:fc:ea:85:bf: f9:05:32:65:35:2c:e8:1f:32:9d:d6:a7:aa:68:a4:7a: e8:d9:4a:a0:a6:bc:fd:36:ba:d3:80:8a:1b:d3:81:8a: 68:1a:73:cc:36:7a:92:dc:eb:ec:af:02:6b:14:c7:77: e3:7d:95:19:e7:17:9d:d2:35:67:60:6b:9f:9b:d9:af: 01:f2:55:7f:5f:ce:23:a0:49:67:01:cd:30:38:8b:d2 Fingerprint (MD5): B8:34:27:AA:02:F6:07:FC:8F:D1:4A:AD:38:29:09 Fingerprint (SHA1): 3C:3B:BD:15:E8:1F:68:2E::E8:EJ:02:63:CD:8F:39:BE:DD:70 Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: User |
証明書の有効性を確認します。また、証明書の発行者が有効で信頼できる認証局であることも確認します。
Directory Server の移行済み 5.x インスタンスを使用している場合は、証明書データベースツールである certutil を使用して、証明書データベースの内容を確認できます。certutil ツールは、証明書および鍵データベースファイルの内容を表示します。このツールの詳細については、http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html を参照してください。
certutil ツールは、上級ユーザーが証明書データベースを生成する際に使用できます。
たとえば、certutil ツールを次のように実行します。
# ./certutil -L -d /opt/SUNWdsee/alias -P slapd- Test (SUBCA1) Internal CA CT,C,C Test (CMSENG) Internal CA CT,C,C ESD SubCA1 Certificate u,, |
このツールにより、証明書 (Test (SUBCA2) Internal CA など) および各証明書に関連付けられた信頼フラグ (CT,C,C など) の一覧が表示されます。SSL サーバー証明書が、C,, フラグの付いた認証局によって生成されていることを確認します。SSL クライアント証明書が、T,, フラグの付いた認証局によって生成されていることを確認します。
たとえば、SSL クライアントとしてしか機能しない証明書を持っているのに、それを SSL サーバーとして使用しようとしても、適切に機能しません。レプリケーションでは、すべての Directory Server レプリカはサプライヤおよびコンシューマとしての役割を果たすため、その証明書は CT,, によって署名されている必要があります。次のように指定して、証明書信頼フラグを CT,, に変更します。
# ./certutil -M -n cert-name -t CT,, -d /opt/SUNWdsee/alias -P slapd- |
また、次のオプションを使用して certutil ツールを実行すると、証明書を発行した認証局を確認することもできます。
# ./certutil -L -n server-cert -d /opt/SUNWdsee/alias -P slapd- |
この情報を使用して、証明書が証明書データベース内に存在することを確認します。証明書の有効期限を調べ、期限切れになっていないか確認することもできます。
クライアント認証を必要とする、または許可するように設定できます。DSCC を使用するか、または dsconf get-server-prop ssl-client-auth-mode コマンドを使用して、クライアント認証設定を確認します。
ユーザーの Directory Server の移行済み 5.x インスタンスでは、dse.ldif ファイル内の nsSSLClientAuth プロパティーを調べることで、クライアント認証設定を確認できます。
DSCC の「ディレクトリサーバー」タブに移動し、表からサーバーを選択します。
「セキュリティー」タブをクリックし、次に「一般」タブをクリックします。
「クライアント認証」セクションで「LDAP 設定」に移動します。
SSL サーバーのみが証明書を必要とするようにする場合は、「証明書ベースのクライアント認証を許可する」を選択します。
SSL サーバーと SSL クライアントの両方が証明書を必要とするようにする場合は、「証明書ベースのクライアント認証を必須にする」を選択します。
動的に読み込まれるすべてのライブラリの一覧を取得して、読み込まれる NSS/SSL ライブラリと NSPR ライブラリを確認します。Solaris Intel、Linux、または Windows の動的に読み込まれるライブラリの一覧を取得するには、次のコマンドを実行します。
# cd install-path /ds6/lib; ldd ns-slapd |
Solaris SPARC、Solaris AMD64、または HPUX の動的に読み込まれるライブラリの一覧を取得するには、次のコマンドを実行します。
# cd install-path/ds6/lib/64; ldd ns-slapd |
動的に読み込まれたライブラリは、次のディレクトリに置かれます。
install-path/dsee6/private/lib |
JES を使用して Directory Server をインストールした場合は、pkginfo コマンドの出力に正しいライブラリが含まれていることを確認します。
ssltap ツールを使用すると、システムでハンドシェークが動作しているかどうかを確認できます。このツールは SSL プロキシのように機能し、LDAP クライアントと Directory Server の間の通信と、交換されるパッケージを表示します。たとえば、このツールを使用して、サーバーが証明書を要求してもクライアントが証明書を送信しない場所や、サーバーがサポートしていない暗号化方式群をクライアントが提案している場所を確認できる場合があります。
SSL ポート 636 はクライアント側でハードコードされているため、ssltap ツールは Directory Server 上で実行し、ポート 636 で受信クライアント要求を待機する必要があります。Directory Server の SSL ポートは、ssltap ツールを実行している間は 636 以外の番号に変更する必要があります。
たとえば、ssltap を次のように実行します。
ssltap -vhfsxl -p 636 localhost:637 > output.html |
クライアント上で ldaplist のような単純な LDAP 要求を実行したあと、ツールによって SSL パケットが取得されているはずです。Ctrl キー + C キーを押してツールを停止し、ブラウザウィンドウに出力ファイルを表示します。出力データはカラーコード化されるため、クライアントから送信されたデータは青色で表示され、サーバーから送信されたデータは赤色で表示されます。