Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

ディレクトリサーバー (NIS+ から LDAP への移行)

rpc.nisd デーモンに含まれる LDAP マッピングでは、LDAP プロトコルバージョン 3 を使用して LDAP サーバーと対話します。デフォルトのマッピング構成 (/var/nis/NIS+LDAPmapping.template) では、LDAP サーバーが RFC 2307 の拡張版に準拠していることを前提としています。RFC は、http://www.ietf.org/rfc.html から入手できます。NIS+ データと LDAP データとのマッピングは、NIS+LDAPmapping(4) を使用して変更できます。ただし、LDAP のデータ編成が RFC 2307 の規定に準拠していることを、基本的な前提としています。

たとえば、LDAP クライアントと NIS+ クライアントとの間でアカウント情報を共有するには、UNIX crypt 書式のアカウント (ユーザー) パスワードを LDAP サーバーに格納できるようにする必要があります。LDAP サーバーをこのように構成できない場合でも、アカウントを含む NIS+ データを LDAP に格納することはできます。その場合、NIS+ ユーザーと LDAP bindDN との間でアカウント情報を完全に共有することはできません。

Sun Java System Directory Server の構成

Sun Java System Directory Server のインストール、設定、および管理の詳細については、Sun Java System Directory Server collection を参照してください。

Sun Java System Directory Server を構成して、LDAP クライアントが LDAP をネームサービスとして使用できるようにするには、idsconfig(1M) を使用します。idsconfig(1M) を使用して設定した構成は、NIS+ で LDAP データリポジトリを使用する場合にも適しています。


注 –

Sun Java System Directory Server 以外の LDAP サーバーを使用している場合は、RFC 2307 に準拠するように、サーバーを手動で構成する必要があります。


サーバーアドレスとポート番号の割り当て

/etc/default/rpc.nisd ファイルは、ローカル LDAP サーバーをポート 389 で使用するように設定されています。この設定が現在の構成に適していない場合は、preferredServerList 属性に新しい値を設定します。たとえば、LDAP サーバーを IP アドレス 192.0.0.1 とポート 65535 で使用するには、次のように指定します。


preferredServerList=192.0.0.1:65535

セキュリティーと認証

NIS+ クライアントおよび NIS+ サーバー間の認証は、NIS+ サーバーが LDAP からデータを取得する場合でも、影響することはありません。ただし、NIS+ データを LDAP に格納するときの整合性を保持するには、rpc.nisd デーモンおよび LDAP サーバー間の認証を必要に応じて設定する必要があります。LDAP サーバーの機能に応じて、さまざまなタイプの認証を利用できます。

rpc.nisd デーモンでは、次の LDAP 認証を利用できます。

この認証方式を利用するときに一定のセキュリティーを保証するには、多くの場合、共有された機密情報 (パスワードまたは鍵) と LDAP の DN を関連付ける必要があります。rpc.nisd デーモンで使用する DN は一意なものであり、ほかの目的で使用することもできます。予測される LDAP トラフィックに対応するために、DN には適切な権限を割り当てる必要があります。たとえば、rpc.nisd デーモンが LDAP にデータを書き込む場合は、NIS+ データに使用されるコンテナ内で LDAP データを追加、更新、および削除する権限を、選択した DN に割り当てる必要があります。また、LDAP サーバーでは、リソースの使用方法がデフォルトで制限されている場合があります (検索時間制限、検索結果のサイズ制限など) 。この制限がある場合は、必要な数の NIS+ データコンテナをサポートできるように、選択した DN に対して必要な設定をする必要があります。

SSL の使用

rpc.nisd デーモンは、SSL を使用した LDAP トラフィックのトランスポート層の暗号化にも対応しています。LDAP サーバー認証用の SSL 証明書の生成については、LDAP サーバーのマニュアルを参照してください。SSL 証明書は、NIS+ サーバー上のファイル (/var/nis/cert7.db など) に格納します。/etc/default/rpc.nisd は、次のように変更します。


nisplusLDAPTLS=ssl
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db

SSL 証明書は、承認されていないアクセスから確実に保護する必要があります。この例では、セッションの暗号化と LDAP サーバーの認証が rpc.nisd に提供されます。SSL 証明書では、LDAP サーバーに対する rpc.nisd の認証は提供されません。この証明書には、この LDAP クライアント (rpc.nisd) の識別情報が含まれていないためです。ただし、rpc.nisd と LDAP サーバーが相互に認証するには、SSL と別の認証方式 (simplesasl/digest-md5) を組み合わせることができます。

パフォーマンスとインデックス処理

niscat(1) などを使用して、LDAP に対応づけられた NIS+ テーブルの列挙を rpc.nisd デーモンに要求すると、テーブル内のエントリの TTL が 1 つでも期限切れになっている場合は、対応する LDAP コンテナが列挙されます。コンテナの列挙はバックグラウンドで実行されるため、LDAP のパフォーマンスはそれほど重要ではありません。ただし、LDAP にインデックスを設定すれば、コンテナが大きい場合でもすばやく列挙することができます。

特定のコンテナの列挙に必要な時間を見積もるには、次のようなコマンドを使用します。

% /bin/time ldapsearch -h server-address -D bind-DN -w password \

-b container , search-base 'cn=*' /dev/null

次に、各引数について説明します。

/bin/time から出力される実際の値は、経過時間です。この値が、対応するテーブルエントリの TTL を 25 パーセント以上占めている場合は (「認証とセキュリティー」 を参照)、LDAP コンテナにインデックスを設定すると有効です。

rpc.nisd では、simple page と VLV インデックス方式がサポートされます。ご使用の LDAP サーバーでサポートされているインデックス方式、およびそのインデックスの作成方法については、LDAP サーバーのマニュアルを参照してください。