test

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

第 14 章 LDAP ネームサービスの計画要件 (手順)

この章では、サーバーとクライアントの設定およびインストール処理を開始する前に実行する必要のある上流工程の計画について説明します。

この章の内容は次のとおりです。

計画の概要

LDAP クライアントプロファイルは、LDAP クライアントが使用する構成情報の集合体です。 LDAP クライアントは、このプロファイルを使用して、サポートする LDAP サーバーについての LDAP ネームサービス情報にアクセスします。 この章では、LDAP ネームサービスのさまざまな分野での計画方法を説明します。 その中には、ネットワークモデル、ディレクトリ情報ツリー、セキュリティモデル、さまざまなプロファイル属性のデフォルト値、およびデータ生成の準備が含まれます。

ネットワークモデルの計画

可用性およびパフォーマンスを考慮すると、企業規模のネットワークの各サブネットが LDAP サーバーを独自に保持して、サブネット内のすべてのLDAP クライアントにサービスを提供する方法が最善です。 これらのサーバーの 1 つだけをマスター LDAP サーバーにする必要があります。 残りはすべてマスターサーバーの複製にできます。

ネットワーク構成を計画する前に、使用可能なサーバーの数、クライアントがサーバーにアクセスする方法、複数のサーバーへのアクセス順序について考慮する必要があります。 サブネットごとに 1 つのサーバーが存在する場合、defaultServerList 属性を使用してすべてのサーバーのリストを作成し、LDAP クライアントからアクセス順序をソートおよび操作できます。 速度またはデータ管理上の理由から、特定の順序でサーバーにアクセスする必要がある場合は、preferredServerList 属性を使用してサーバーへの固定されたアクセス順序を定義します。 マスターサーバーをこれらのリストに配置しないことで、マスターサーバーへの負荷を軽減できます。

さらに、サーバーおよびネットワーク構成を計画する際に考慮するに値する 3 つの属性があります。 bindTimeLimit 属性は TCP 接続要求のタイムアウト値の設定に使用されます。 searchTimeLimit 属性は LDAP 検索操作のタイムアウト値の設定に、 profileTTL 属性は LDAP クライアントによるサーバーからのプロファイルのダウンロード頻度の制御に、それぞれ使用できます。 速度が遅いか不安定なネットワークの場合、bindTimeLimit および searchTimeLimit 属性にデフォルト値より大きい値を設定することが必要な場合があります。 配備の初期テスト段階で、profileTTL 属性値を引き下げて、頻繁に行われる LDAP サーバー内のプロファイルの変更をクライアントが取得するようにしてもよいでしょう。

ディレクトリ情報ツリー (DIT) の計画

LDAP ネームサービスは、デフォルトのディレクトリ情報ツリー (DIT) および関連するデフォルトスキーマを保持します。 たとえば、ou=people コンテナには、ユーザーアカウント、パスワード、およびシャドウ情報が含まれます。 ou=hosts コンテナには、ネットワーク内のシステムに関する情報が含まれます。 ou=people コンテナ内の各エントリは、 objectclass の posixAccount および shadowAccount のエントリになります。

デフォルト DIT は、巧みに設計されたディレクトリ構造であり、オープンな標準に基づいています。 これは、ほとんどのネームサービスのニーズに応えるもので、変更せずに使用することが推奨されています。 デフォルト DIT の使用を選択する場合、決定する必要があるのは、ディレクトリツリー内のどのノード (起点識別名) から、指定されたドメインのネームサービス情報を検索するかという点だけです。 このノードは、defaultSearchBase 属性を使用して指定されます。 さらに、defaultSearchScope 属性を設定して、ネームサービスが実行する検索範囲をクライアントに指定することもできます。 検索範囲には、識別名 (DN) 内の 1 レベルだけを検索するか (one)、DN内のサブツリー全体を選択するか (sub) を指定できます。

ただし、既存の DIT を利用する場合でも、ディレクトリツリー内に散在するネームサービスデータを使用してより複雑な DIT を処理する場合でも、LDAP ネームサービスにより高度な柔軟性が求められる場合があります。 たとえば、ユーザーアカウントエントリがツリーの別の場所に存在する場合があります。 クライアントプロファイル内で serviceSearchDescriptor、attributeMap、および objectclassMap 属性を設定して、これらの状況に対応します。

サービス検索記述子を使用して、特定のサービスのデフォルト検索ベース、検索範囲、および検索フィルタを置き換えることができます。 詳細については、サービス検索記述子 (SSD) とスキーママッピングを参照してください。

AttributeMap および ObjectclassMap 属性を使用して、スキーママッピングを行うことができます。 これらの属性を使用すると、既存の DIT で LDAP ネームサービスを動作させることができます。 たとえば、posixAccount オブジェクトクラスを既存のオブジェクトクラス myAccount へマップできます。 posixAccount オブジェクトクラス内の属性を myAccount オブジェクトクラス内の属性へマップできます。

複数のディレクトリサーバー

複数の LDAP サーバーで 1 つの DIT を構成することも可能です。 たとえば、DIT のいくつかのサブツリーを、他の LDAP サーバー上に配置できます。 この場合、LDAP サーバーは、既知ではあるが自身のデータベース内に存在しないネームデータを求める LDAP クライアントを、別のサーバーに委ねることができます。 この種の DIT 構成を計画する場合、LDAP ネームサービスがサーバー参照に従ってネームサービス検索を続行することを示すように、クライアントのプロファイル属性 followReferrals を設定する必要があります。 ただし可能であれば、指定されたドメインのネームデータすべてを単独のディレクトリサーバー上に配置するのが最善です。

クライアントが通常は読み取り専用の複製にアクセスし、必要な場合にのみ読み取り/書き込み可能なマスターサーバーへの参照を利用する場合、参照が役に立ちます。 この方法では、要求が複製により処理されるため、マスターサーバーに過度の負荷がかかることはありません。

他のアプリケーションとのデータ共有

LDAP を最大限に活用するには、論理エントリごとに 1 つの LDAP エントリが存在する必要があります。 たとえば、ユーザーは、企業白書に関する情報だけでなく、 Solaris アカウント情報やアプリケーション固有のデータも保持できます。 posixAccount および shadowAccount は補助オブジェクトクラスであるため、これらのデータをディレクトリ内のエントリに追加できます。 このため、注意深い計画、設定、および管理が必要になります。

ディレクトリ接尾辞の選択

適切なディレクトリ接尾辞の選択方法については、第 11 章「Sun ONE Directory Server の構成」を参照してください。

複製サーバー

複製サーバーを設定する場合、次の 3 つの方法が存在します。

「単一マスター」

単一マスター複製では、指定されたパーティションまたはパーティション化されていないネットワークに対して、1 つのマスターサーバーだけが、ディレクトリエントリの書き込み可能なコピーを保持します。 複製サーバーは、ディレクトリエントリの読み込み専用コピーを保持します。 複製とマスターの両方が検索、比較、およびバインド操作を実行できますが、書き込み操作を実行できるのはマスターサーバーだけです。

単一マスター複製の不利な点は、マスターサーバーでシングルポイント障害が発生した場合です。 マスターサーバーがダウンした場合、どの複製サーバーからも書き込み操作を実行できません。

「浮動マスター」

浮動マスターは、指定されたパーティション化されたネットワークまたはパーティション化されていないネットワークに対し、書き込み権限を保持するマスターサーバーは常に 1 つだけである点で、単一マスターを使用する場合と似ています。 ただし浮動マスターを使用すると、マスターサーバーがダウンした場合、アルゴリズムにより複製が自動的にマスターサーバーに変化します。

浮動マスター複製の不利な点は、ネットワークがパーティション化され、どちらの側のパーティション上の複製もマスターになった場合、ネットワークを再結合する際、新規マスター間の調整が非常に複雑になり得ることです。

「複数マスター」

複数マスター複製では、ディレクトリエントリデータの独自の読み取り/書き込み複製を保持する、複数のマスターサーバーが存在します。 複数マスターを使用すると、シングルポイント障害を防ぐことができますが、サーバー間で更新による競合が発生する可能性があります。 つまり、2 つのマスター上でエントリの属性が同時に変更される場合、競合による障害の解決ポリシー (最後の書き込みを優先するなど) の適用が必要になります。

複製サーバーの設定方法については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。

セキュリティモデルの計画

セキュリティモデルを計画する場合、最初に、LDAP クライアントが LDAP サーバーとの通信に使用する識別情報を考慮する必要があります。 たとえば、強力な認証を使用してネットワーク上を流れるユーザーパスワードを保護するかどうか、また LDAP クライアントと LDAP サーバー間のセッションを暗号化して送信される LDAP データを保護する必要があるかなどを決定する必要があります。

セキュリティモデルの計画には、プロファイル内の credentialLevel および authenticationMethod 属性が使用されます。 credentialLevel には、 匿名、プロキシ、および匿名プロキシの 3 つの資格レベルのうちの 1 つを指定できます。 LDAP ネームサービスのセキュリティ概念については、LDAP ネームサービスのセキュリティモデルを参照してください。

セキュリティモデルを計画する際の主要な決定事項を次に示します。

クライアントプロファイルおよびデフォルト属性値の計画

前述の計画手順 (ネットワークモデル、DIT、およびセキュリティモデル) を理解することにより、次のプロファイル属性の値についてアイデアを得ることができるでしょう。

上記の属性の中で、必須属性は cn、defaultServerList、および defaultSearchBase だけです。 これらの属性には、デフォルト値は存在しません。 残りの属性はオプションであり、デフォルト値がないオプションも存在します。

LDAP クライアントの設定の詳細については、第 16 章「クライアントの設定 (手順)」を参照してください。

データ生成の計画

データを使用して LDAP サーバーを生成する場合、 適切な DIT およびスキーマを使用して LDAP サーバーを構成した後で、 新しい ldapaddent ツールを使用します。 このツールは、対応する /etc ファイルから LDAP コンテナ内にエントリを作成します。 このツールを使用して、次のデータタイプ用のコンテナ内にデータを生成することができます。 aliases、auto_*、bootparams、ethers、group、hosts (IPv6 アドレスを含む)、netgroup、netmasks、networks、passwd、shadow、protocols、publickey、rpc、および services。

デフォルトでは、ldapaddent は標準入力からこのデータを読み取って、コマンド行で指定されたデータベースに関連付けられた LDAP コンテナに追加します。 ただし、データを読み取る入力ファイルは、-f オプションを使用して指定できます。

エントリはクライアントの構成に基づき、ディレクトリ内に格納されるため、LDAP ネームサービスを使用するようにクライアントを構成する必要があります。

パフォーマンスを向上させるため、次の順序でデータベースをロードしてください。

  1. passwd データベースの次に shadow データベース

  2. networks データベースの次に netmasks データベース

  3. bootparams データベースの次に ethers データベース

オートマウントエントリを追加する場合、データベース名は auto_* (たとえば auto_home) の形式で指定します。

別のホストの /etc ファイルを LDAP サーバーに追加する場合、それらすべてを 1 つの /etc ファイルにマージして、1 台のホスト上で ldapaddent を使用して追加できます。 あるいは、各ホストが LDAP クライアントとして構成済みであることを想定して各ホストで ldapaddent を実行することもできます。

使用するネームサービスデータが NIS サーバー上にすでに存在し、データを LDAP ネームサービス用の LDAP サーバーに移動する場合、ypcat (または niscat) コマンドを使用して NIS マップをファイル内にダンプします。 続いて、これらのファイルに対して ldapaddent を実行してデータを LDAP サーバーに追加します。

注 –

ldapaddent は LDAP クライアント上でしか実行できません。

以下の作業は、テーブルが yp クライアントから抽出されることを想定しています。

ldapaddent を使用して host エントリを持つサーバーを生成する方法

  1. idsconfig を使用し、Sun ONE Directory Server が設定されていることを確認します。

  2. クライアントマシン上でスーパーユーザーになります。

  3. そのマシンを LDAP クライアントに設定します。

    # ldapclient init -a profileName=new \

    -a domainName=west.example.com 192.168.0.1

  4. データを指定してサーバーを生成します。

    # ldapaddent -D “cn=directory manager” -f /etc/hosts hosts

この例では、現在 ldapaddent が simple 認証方式を使用してバインドしているように、平文で directory_manager パスワードが送られます。