この章では、LDAP の構成で発生する問題とその解決方法を示します。
LDAP サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。LDAP でこの機能を使用する場合の詳細については、「LDAP とサービス管理機能」を参照してください。この機能の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
以降の節では、LDAP クライアント環境の状態判定に使用するさまざまなコマンドを紹介します。使用可能なオプションの詳細については、マニュアルページも参照してください。
サービス管理機能の概要は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
ldap_cachemgr デーモンは、常に実行中で適切に機能している必要があります。このデーモンが機能していない場合、システムは動作しません。LDAP クライアントを起動すると、ldap_cachemgr デーモンが自動的に起動します。したがって、ldap_cachemgr が実行されていない場合は、LDAP クライアントが使用不能になります。LDAP クライアントがオンラインであるかどうかを確認する 2 つの方法を次に示します。
svcs コマンドを使用します。
# svcs \*ldap\* STATE STIME FMRI disabled Aug_24 svc:/network/ldap/client:default |
または
# svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online) |
-g オプションを ldap_cachemgr に渡します。
このオプションによって、問題の診断に役立つより広範な状態情報がダンプされます。
# /usr/lib/ldap/ldap_cachemgr -g cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2 |
ldap_cachemgr デーモンの詳細については、ldap_cachemgr(1M) のマニュアルページを参照してください。
スーパーユーザーになるか、同等の役割になり、ldapclient を list オプションで実行します。
# ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.1, 192.168.0.10 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= TRUE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_SERVER_PREF= 192.168.0.1 NS_LDAP_PROFILE= pit1 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one NS_LDAP_BIND_TIME= 5 |
/var/ldap ファイルは現在 ASCII 形式ですが、バイナリに変更される可能性があるため、このファイルを連結すると問題が発生する可能性があります。この情報へのアクセスにサポートされている方式は、ldapclient list です。詳細については、ldapclient(1M) のマニュアルページを参照してください。
クライアントが LDAP サーバーに対して通信を行なっていることを確認する最善の方法は、ldaplist コマンドを使用することです。引数を付けずに ldaplist だけを指定して実行すると、サーバー上のすべてのコンテナがダンプされます。この方法はコンテナが存在している限り可能で、コンテナを生成する必要がありません。詳細については、ldaplist(1) のマニュアルページを参照してください。
最初の手順が成功したら、ldaplist passwd username または ldaplist hosts hostname を実行できますが、大量のデータが含まれている場合には、生成量の少ないサービスを選ぶか、head や more コマンドを使用してデータをパイプ処理することもできます。
前述のコマンドの大半は、LDAP クライアントを作成済みであることが前提です。クライアントを作成していない状態でサーバー上のデータをチェックする場合は、ldapsearch コマンドを使用します。次の例では、すべてのコンテナをリスト表示します。
# ldapsearch -h server1 -b "dc=west,dc=example,dc=com" -s one "objectclass=*" |
Solaris 9 およびそれ以前のリリースでは、ldapsearch コマンドはデフォルトで、非標準のテキスト表現で出力を生成していました。それより後の Solaris リリースの ldapsearch のデフォルト出力は、RFC-2849 で定義されている業界標準の LDIF フォーマットです。ldapsearch のすべてのバージョンで、-L オプションを使用することによって LDIF フォーマットを出力できます。
以降の節では、LDAP の構成で発生する問題とそれらの解決方法について説明します。
Solaris プラットフォームの LDAP クライアントバックエンドは、ホストの検索で、gethostbyname() や getaddrinfo() で返されるホスト名のような、完全指定ホスト名を返します。格納済みの名前が指定されている (1 つ以上のドットが含まれている) 場合、クライアントはその名前をそのまま返します。たとえば、格納されている名前が hostB.eng であれば、返される名前も hostB.eng です。
LDAP ディレクトリに格納された名前が指定されていない (ドットが含まれない) 場合、クライアントのバックエンドは、その名前にドメイン部分を追加します。たとえば、格納されている名前が hostA であれば、返される名前は hostA.domainname となります。
DNS ドメイン名が LDAP ドメイン名とは異なる場合、格納されたホスト名が完全指定でない限り LDAP ネームサービスをホスト名に対して使用することはできません。
LDAP クライアントは、ログイン時に PAMモジュールを使用してユーザーを認証します。UNIX 標準の PAM モジュールでは、パスワードをサーバーから読み込みクライアント側で検査します。この動作は、次のいずれかの理由で失敗する場合があります。
/etc/nsswitch.conf ファイル内の passwd サービスが ldap を使用しない
プロキシエージェントが、サーバーリスト上のユーザーの userPassword 属性を読み取ることができない。プロキシエージェントが比較のためにパスワードをクライアントに返すので、少なくともプロキシエージェントはパスワードを読めなければならない。pam_ldap に関しては、パスワードへの読み取りアクセスを必要としない
プロキシエージェントが適切なパスワードを保持していない
該当するエントリに shadowAccount オブジェクトクラスが定義されていない
パスワードが定義されていない
ldapaddent を使用する場合、-p オプションを使用してパスワードをユーザーエントリに確実に追加する必要があります。ldapaddent を -p オプションなしで実行した場合、ldapaddent を使用して /etc/shadow ファイルを追加しない限り、ユーザーのパスワードはディレクトリに格納されません。
LDAP サーバーに到達することができない
サーバーの状態を確認します。
# /usr/lib/ldap/ldap_cachemgr -g |
pam.conf の構成が不正である
LDAP 名前空間でユーザーが定義されていない
pam_unix で NS_LDAP_CREDENTIAL_LEVEL が anonymous に設定されており、匿名ユーザーが userPassword を使用できない
パスワードが crypt 形式で格納されていない
アカウント管理をサポートするように pam_ldap が構成されている場合は、次のいずれかの原因でログインに失敗します。
ユーザーのパスワード期限が切れている
ログインを何回も行ったために、ユーザーアカウントがロックされる
管理者がユーザーアカウントを非アクティブにした
rsh、rlogin、ssh、sftp などのパスワードを使用しないプログラムによってユーザーがログインしようとした
ユーザー別の認証および sasl/GSSAPI を使用している場合、一部の Kerberos コンポーネントまたは pam_krb5 構成が正しく設定されません。この問題を解決する方法については、『Solaris のシステム管理 (セキュリティサービス)』を参照してください。
LDAP データベースは、検索パフォーマンス向上にインデックスを使用します。インデックスが正しく作成されていない場合、大幅にパフォーマンスが低下することがあります。このマニュアルには、インデックスを作成する必要のある共通の属性セットを記述しています。また、独自のインデックスを追加して、パフォーマンスの向上を図ることができます。
profileName 属性を指定して init オプションを使用すると、ldapclient がクライアントの初期化に失敗することがあります。考えられる失敗の原因は次のとおりです。
コマンド行で不正なドメイン名が指定された
指定されたクライアントドメインのエントリポイントを表す nisDomain 属性が DIT (ディレクトリ情報ツリー) 内に設定されていない
アクセス制御情報がサーバー上で適正に設定されていないため、LDAP データベース内の匿名検索が許可されない
ldapclient コマンドに渡されたサーバーアドレスが間違っている。ldapsearch を使用してサーバーのアドレスを確認する
ldapclient コマンドに渡されたプロファイル名が間違っている。ldapsearch を使用して、DIT 内のプロファイル名を確認する
クライアントのネットワークインタフェースに対して snoop を実行して外向きのトラフィックを検査して、どのサーバーにアクセスしているかを確認する
ldap_cachemgr を -g オプションを付けて使用すると、現在のクライアント構成および統計を表示できるため、デバッグするのに便利です。たとえば、次のように指定します。
# ldap_cachemgr -g |
この結果、すでに説明したように、すべての LDAP サーバーの状態を含む現在のクライアント構成および統計が標準出力に出力されます。このコマンドを実行するのに、スーパーユーザーになる必要はありません。
ldapclient コマンドがハングアップした場合、Ctrl-C キーを押すと以前の環境を復元したあとで終了します。この状況が発生する場合、サーバーが動作していることをサーバー管理者に確認してください。
プロファイルまたはコマンド行に指定されたサーバーリスト属性で、サーバー情報が適正であることを確認してください。