test

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

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

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

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

LDAP の計画の概要

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 は補助オブジェクトクラスであるため、これらのデータをディレクトリ内のエントリに追加できます。このため、注意深い計画、設定、および管理が必要になります。

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

適切なディレクトリ接尾辞の選択方法については、Sun Java System Directory Server (以前の名称は Sun ONE Directory Server) のマニュアルを参照してください。

LDAP と複製サーバー

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

「単一マスター」

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

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

「浮動マスター」

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

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

「複数マスター」

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

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

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

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

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

注 –

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に Directory Server への認証を実行せずに、アカウントの管理およびユーザーのアカウント状態の取得を実行できるようになりました。Directory Server 上でこの機能を制御するのは、1.3.6.1.4.1.42.2.27.9.5.8 です。これは、デフォルトで有効になっています。

この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
注 –

企業全体のシングルサインオンソリューションとして pam_krb5 および Kerberos を有効にする場合、セッション開始時にのみログインパスワードを必要とするシステムを設計できます。詳細については、『Solaris のシステム管理 (セキュリティサービス)』を参照してください。一般に、Kerberos を有効にする場合には、DNS も有効にする必要があります。詳細については、このマニュアルの DNS に関する章を参照してください。

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

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

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

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

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

LDAP データ生成の計画

データを使用して 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 クライアントから抽出されることを想定しています。

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

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

  2. クライアントマシンで、スーパーユーザーになるか、同等の役割になります。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

  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 は、プロファイル「new」で設定されている認証方式を使用します。「simple」を選択した場合、パスワードは平文で送信されます。詳細については、ldapaddent(1M) のマニュアルページを参照してください。