ものいわぬOpenLDAPサーバのログ管理・その2：OpenLDAPによるディレクトリサーバ運用（4）（3/3 ページ）
ユーザー情報や組織情報などを一元的に管理するディレクトリサーバは、企業システムの中で重要な役割を果たしています。オープンソースの「OpenLDAP」によるディレクトリサーバの構築方法を解説した前連載に続き、その運用方法を紹介していきます。（編集部）
3行目の「RESULT」は、認証処理の結果を示しています。認証処理が成功した場合は、「err=0 text=」という表示となります。認証が失敗していれば、「err=49 text=」のように0以外のエラー番号が表示されます。このエラー番号にはRFCで定められた特定の意味があり、ldapsearchなどのOpenLDAPクライアントは、LDAPサーバから受けたエラー番号に対応するエラーメッセージを添えて表示しています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
認証がうまくいかない場合は、このエラー番号とメッセージを基に原因を追及できます。認証時に特に起きやすいエラーは、エラー番号49の「Invalid credentials」ではないでしょうか。このエラーは、
- 認証に利用しているDNが異なる
- 認証に利用しているパスワードが異なる
- 認証に利用しているパスワードへのアクセス権がない
といった原因によって起きるものです。このエラー番号が表示された場合は、上記の部分を再確認してみるといいでしょう。
また3行目の「tag」は、どのオペレーションの結果であるかを示します。複数のコネクションとオペレーションが入り乱れて複雑に見える場合でも、認証処理の結果であれば「97」、検索処理の結果であれば「101」というように識別できます。
| 処理 | 結果タグの値 |
|---|---|
| BIND（認証） | 97 |
| SEARCH RESULT（検索） | 101 |
| MOD（変更） | 103 |
| ADD（追加） | 105 |
| DEL（削除） | 107 |
| 表2 代表的な処理結果タグ | |
SEARCH処理
認証処理の次は、SRCH（検索）処理です。以下は、検索処理と検索結果に関する部分を抜き出したものです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「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」ファイルに指定された値が利用されている場合があります。このような場合にはサーバ側のログを確認し、実際にサーバ側で実行されている検索範囲を明確にすることで、問題の切り分けがスムーズになります。
続く「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サーバ側のログを確認し、どのような検索処理がサーバ側で行われているかを再確認するとよいでしょう。
UNBIND処理
目的の処理が終了した後は、LDAPのプロトコルレベルでのセッション終了を意味するUNBIND処理が実行されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ここまでに説明した内容を先ほどのシーケンス図に当てはめると次のようになります。ldapsearch実行後、OpenLDAPサーバ側で行われた処理の詳細が浮かび上がってきます。
ここまで、検索処理が行われたログから読み取れる内容を説明してきました。変更、追加、削除といった検索以外の処理においても、認証処理が先行するフローは変わりません。管理者は、syslogが記録したログファイルを確認することで、OpenLDAPサーバがどのような処理を行っているかを把握できます。
うまく処理が完了していない場合、管理者は、該当する処理のエラー番号やスムーズに処理が行われていない旨のメッセージ（注3）を確認することで、OpenLDAPサーバが抱える問題に気付き、対処方法を検討できるようになるでしょう。
◆注3：英語になりますが、OpenLDAPコミュニティでは次のような情報が公開されています。
http://www.openldap.org/doc/admin24/appendix-common-errors.html
http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html
まとめ
第3回と第4回では、OpenLDAPサーバのログ管理について説明しました。特に今回は、運用状況を把握するうえで大切なsyslogが記録するログに注力し、説明してきました。
次回からは、OpenLDAPサーバのパフォーマンスチューニングの勘所を説明していきます。
Copyright © ITmedia, Inc. All Rights Reserved.