JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Oracle Solaris 11.1 でのネームサービスおよびディレクトリサービスの作業     Oracle Solaris 11.1 Information Library (日本語)
このドキュメントの評価
search filter icon
search icon

ドキュメントの情報

はじめに

パート I ネームサービスとディレクトリサービスについて

1.  ネームサービスとディレクトリサービス (概要)

2.  ネームサービススイッチ (概要)

3.  DNS の管理 (タスク)

4.  Oracle Solaris Active Directory クライアントの設定 (タスク)

パート II NIS の設定と管理

5.  ネットワーク情報サービス (概要)

6.  NIS の設定と構成 (タスク)

7.  NIS の管理 (タスク)

8.  NIS のトラブルシューティング

パート III LDAP ネームサービス

9.  LDAP ネームサービスの紹介 (概要)

10.  LDAP ネームサービスの計画要件 (タスク)

LDAP の計画の概要

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

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

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

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

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

LDAP と複製サーバー

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

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

LDAP データ生成の計画

ldapaddent コマンドを使用してサーバーに host エントリを生成する方法

11.  LDAP クライアントと Oracle Directory Server Enterprise Edition の設定 (タスク)

12.  LDAP クライアントの設定 (タスク)

13.  LDAP のトラブルシューティング (リファレンス)

14.  LDAP ネームサービス (リファレンス)

15.  NIS から LDAP への移行 (タスク)

用語集

索引

ドキュメントの品質向上のためのご意見をください
簡潔すぎた
読みづらかった、または難し過ぎた
重要な情報が欠けていた
内容が間違っていた
翻訳版が必要
その他
Your rating has been updated
貴重なご意見を有り難うございました!

あなたの貴重なご意見はより良いドキュメント作成の手助けとなります 内容の品質向上と追加コメントのためのアンケートに参加されますか?

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

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

デフォルト DIT は適切に設計されたディレクトリ構造であり、オープンな標準に基づいています。詳細は、RFC 2307bis および RFC 4876 を参照してください。デフォルト DIT は、ほとんどのネームサービスニーズにとって十分であり、変更なしで使用することが推奨されます。デフォルト DIT を使用することを選択した場合は、特定のドメインに関して、ディレクトリツリー内のどのノード (ベース DN) からネームサービス情報を検索するかを決定するだけで済みます。このノードは、defaultSearchBase 属性を使用して指定されます。さらに、defaultSearchScope 属性を設定して、ネームサービスが実行する検索範囲をクライアントに指定することもできます。検索範囲には、識別名 (DN) 内の 1 レベルだけを検索するか (one)、DN 内のサブツリー全体を選択するか (sub) を指定できます。

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

サービス検索記述子を使用して、特定のサービスのデフォルト検索ベース、検索範囲、および検索フィルタをオーバーライドできます。「サービス検索記述子とスキーママッピング」を参照してください。

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

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

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

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

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

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

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

適切なディレクトリ接尾辞を選択する方法については、Oracle Directory Server Enterprise Edition のドキュメントを参照してください。