ものいわぬOpenLDAPサーバのログ管理・その2：OpenLDAPによるディレクトリサーバ運用（4）（3/3 ページ）

» 2010年04月15日 00時00分公開

[菊池研自，伊藤忠テクノソリューションズ株式会社]

　3行目の「RESULT」は、認証処理の結果を示しています。認証処理が成功した場合は、「err=0 text=」という表示となります。認証が失敗していれば、「err=49 text=」のように0以外のエラー番号が表示されます。このエラー番号にはRFCで定められた特定の意味があり、ldapsearchなどのOpenLDAPクライアントは、LDAPサーバから受けたエラー番号に対応するエラーメッセージを添えて表示しています。

# cd /usr/local/openldap-2.4.21

  # ./bin/ldapsearch -x -D cn=Manager,dc=my-domain,dc=com -w wrong_password -b dc=my-domain,dc=com

  ldap_bind: Invalid credentials (49)

　認証がうまくいかない場合は、このエラー番号とメッセージを基に原因を追及できます。認証時に特に起きやすいエラーは、エラー番号49の「Invalid credentials」ではないでしょうか。このエラーは、

認証に利用しているDNが異なる
認証に利用しているパスワードが異なる
認証に利用しているパスワードへのアクセス権がない

といった原因によって起きるものです。このエラー番号が表示された場合は、上記の部分を再確認してみるといいでしょう。

　また3行目の「tag」は、どのオペレーションの結果であるかを示します。複数のコネクションとオペレーションが入り乱れて複雑に見える場合でも、認証処理の結果であれば「97」、検索処理の結果であれば「101」というように識別できます。


処理	結果タグの値
BIND（認証）	97
SEARCH RESULT（検索）	101
MOD（変更）	103
ADD（追加）	105
DEL（削除）	107
表2　代表的な処理結果タグ

SEARCH処理

　認証処理の次は、SRCH（検索）処理です。以下は、検索処理と検索結果に関する部分を抜き出したものです。

... conn=1000 op=1 SRCH base="dc=my-domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"

  ... conn=1000 op=1 SRCH attr=1.1

  ... conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=4 text=

　「base」と出力された個所は、DIT（Directory Information Tree）上で検索処理の出発点となるベースDNを示し、「scope」と表示された個所は、ベースDNからの検索範囲を示しています。「scope」の値は、以下の意味を持ちます。


「scope」フィールドの値	検索範囲
0	base（検索ベースのみ）
1	one（検索ベース以下1レベルのみ）
2	sub（検索ベース以下すべて）
3	children（検索ベースを除き以下すべて）
表3　「scope」フィールドの値と検索範囲

　このため「base」と「scope」の値を確認すれば、実行された検索処理が対象としている検索範囲が明確になります。

　例えば、コマンドラインでldapsearchコマンドの検索オプションを指定していなくても、クライアント側の「ldap.conf」ファイルに指定された値が利用されている場合があります。このような場合にはサーバ側のログを確認し、実際にサーバ側で実行されている検索範囲を明確にすることで、問題の切り分けがスムーズになります。

図2　検索範囲の明確化

　続く「deref」は、エイリアスエントリをどう扱うかを示しています。上記のログでは、ldapsearchコマンドがデフォルトで採用する「deref=0」が利用され、エイリアスエントリが指し示す先のエントリを参照しない検索が行われています。「deref」の値は、以下の意味を持ちます。


「deref」フィールドの値	エイリアス参照
0	never（常に、エイリアス参照を行わない）
1	search（検索スコープがベース以外の場合に、エイリアス参照を行う）
2	find（検索ベースに指定されたエントリに対し、エイリアス参照を行う）
3	always（常に、エイリアス参照を行う）
表4　「deref」フィールドの値とエイリアス参照

　次の「filter」は、検索フィルタを示しています。上記のログにはデフォルトの検索フィルタである「filter="(objectClass=*)"」が表示されていますので、実質的なフィルタとしての働きがない検索が行われていることが分かります。

　2行目の「attr」には、検索処理でリクエストされた属性がリストされます。「attr」行がない場合、または「attr=*」と表示されている場合はすべてのユーザー属性がリクエストされたことを意味し、「attr=+」のように「+」記号がある場合は、運用属性がリクエストされたことを意味します。また今回のように「attr=1.1」の場合は、エントリが持つ属性は必要ない旨がリクエストされていることを意味します。

　最後の「SEARCH RESULT」を含む行は、前述のBIND処理の結果と同様に「tag」の値を持ちます。検索処理の結果を示しますので、「tag=101」となります。また、「err」は検索処理が成功していれば「err=0」となり、クライアントに検索結果として返したエントリ数が「nentries」に表示されます。上記のログでは「nentries=4」と出力されていますので、この検索処理の結果には4エントリが返されたと判断できます。

　検索処理に失敗する場合や、検索そのものは成功していても期待するエントリが取得できない場合は、ここまでに説明した内容を踏まえてOpenLDAPサーバ側のログを確認し、どのような検索処理がサーバ側で行われているかを再確認するとよいでしょう。