test

Sun Directory Services 3.1 管理ガイド

第 1 章 ディレクトリの概念

この章では、次の項目について説明します。

ディレクトリ情報

ディレクトリの情報は、基本的な情報となるエントリと別名エントリ、およびこの基本的な情報の構造を決めるインフラ情報からなります。

ディレクトリエントリ

「ディレクトリエントリ」は、一連の「属性」とその「値」からなります。各エントリは「オブジェクトクラス」という属性を持ち、これがそのエントリに記述されているオブジェクトの種類を指定し、そこに含まれる属性のセットを定義します。オブジェクトクラスの属性には、必須のものと任意のものがあります。たとえば、オブジェクトクラス country は、必須属性 countryName と任意属性 description および searchGuide で記述します。

スキーマは、オブジェクトクラスエントリの必須属性と任意属性を定義します。スキーマは継承階層も定義します。すべてのオブジェクトクラスは、自分より上のオブジェクトクラスの特性を継承します。たとえば、オブジェクトクラス organizationalPerson はオブジェクトクラス Person のサブクラスなので、必須属性と任意属性をオブジェクトクラス Person から継承します。

すべてのオブジェクトクラスは、オブジェクトクラス top から属性を継承します。オブジェクトクラス top には必須属性 objectClass があるため、すべてのエントリには少なくとも 1 つのオブジェクトクラス属性があります。

オブジェクトクラスの種類として「構造」と「補助」があります。構造オブジェクトクラスは、エントリの種類を定義します。1 つのエントリには、1 つの構造オブジェクトクラスしか指定できません。補助オブジェクトクラスは、それだけではエントリの種類を定義できませんが、構造オブジェクトクラスを指定すれば定義できます。たとえば、補助オブジェクトクラス uidObject を使えば、ディレクトリの任意のエントリに uid を割り当てることができます。

識別名と相対識別名

ディレクトリ情報は、エントリがツリー構造に編成された階層になっています。各エントリには必ず親エントリがあり、子エントリがある場合とない場合があります。階層の一番上は「ルートエントリ」といいます。

エントリは、その「識別名」(DN) で識別されます。識別名は一連の属性と値からなります。最初の属性とその値がエントリの「相対識別名」(RDN) で、残りの部分が親エントリの識別名です。識別名は、ディレクトリサービス全体で固有の値です。

図 1-1 に、ディレクトリ情報の構造例を示します。黒く塗ったエントリの識別名と相対識別名を示します。

図 1-1 ディレクトリ情報の構造

Graphic

識別名の一部となることができる属性を「名前付き属性」と呼びます。Sun Directory Services で提供するデフォルトのスキーマでは、名前付き属性は次のようになります。

別名

別名リストを定義できます。別名リストのエントリは識別名 (DN) で識別され、エントリが表すディレクトリエントリ名 (別名のオブジェクト名) を持っています。別名リストとそのエントリは、同じルートエントリの下になければなりません。別名オブジェクトクラスの定義については、「オブジェクトクラスのリファレンス」を参照してください。

バインドと検索の操作では、ディレクトリが別名識別名を実際のエントリの識別名に変換するように指定できます。これを別名の「参照」と呼びます。これ以外の操作では、別名エントリを通常のエントリとして扱う必要があります。たとえば、別名のオブジェクトではなく、別名エントリそのものの相対識別名を変更する場合には、別名の参照は行いません。

別名エントリと検索

別名エントリを伴う検索や読み取り操作の結果は、別名の参照を行うかどうかによって異なります。別名の参照は LDAP クライアントが指定します。別名の参照フラグには、次の 4 つの設定が可能です。

たとえば、ディレクトリに次の対のエントリがあるとします。

cn=Stan Smith, role=Personnel Administrator, ou=Personnel, o=XYZ, c=US 

次の属性を持つ 

objectclass=orgPerson 

 

cn=Stan Smith 

 

telephoneNumber=123 456 7890 

 

mail=dtmail 

cn=personnel, o=XYZ, c=US 

次の属性を持つ 

objectclass=alias 

objectclass=aliasObject 

 

cn=personnel 

aliasedObjectName="cn=Stan Smith, role=Personnel Administrator, ou=Personnel, o=XYZ, c=US" 

検索時に別名の参照を行う場合、サブツリー o=XYZ、c=US で cn=personnel の電話番号を検索すると、Stan Smith の電話番号が得られます。別名の参照を行わない場合、電話番号は得られません。

役割に対し別名を定義すると、役割の担当者がしばしば変わるような場合 (たとえば、時間外に呼び出される当直のネットワークマネージャのような場合)、特に便利です。ユーザーはいつも同じ名前で照会できるからです。aliasedObjectName の値はスクリプトで変更できます。このスクリプトは、スケジュールに従って実行され、ldapmodify を呼び出して変更を行います。

ldapsearch で別名の参照の使い方を指定する方法については、ldapsearch(1) のマニュアルぺージを参照してください。

別名エントリと認証

ディレクトリに対してある種の操作を行うには、ユーザーの認証が必要です。たとえば、ディレクトリ内容の変更やエントリの userPassword 属性の読み取りが行われるようなときです。許されるアクセスレベルは、バインドプロセスで確立されます。詳細は、「ディレクトリとのバインド」を参照してください。

バインド要求に指定された識別名が別名エントリの識別名であることがあります。別名の参照を使用する場合には、別名エントリの ailiasedObjectName に指定されている識別名とユーザーはバインドされ、その識別名を持つエントリに定義されているアクセス権が与えられます。

バインド操作での別名の参照は、LDAP サーバーに対して行う必要がある構成選択の 1 つです。別名の参照を使用せずに別名エントリの識別名でバインドすると、パスワード属性がないため、アクセスは拒否されます。これは、別名の参照を許可すると、ユーザーはパスワードなしにバインドできることを意味します。

Sun Directory Services に対し別名の参照を指定する方法については、「LDAP パラメータの構成」を参照してください。

ディレクトリ構造

汎用ディレクトリの場合は、どのような情報を格納し、情報をどのように編成するか決めなければなりません。広域ディレクトリの情報は物理的にはいくつものサーバーに分かれることがありますが、全体的には 1 つのツリー構造になります。

ディレクトリ情報ツリー

ディレクトリの情報は、「ディレクトリ情報ツリー (DIT)」と呼ぶツリー構造に編成されます。ディレクトリ情報ツリーの構造は、通常、そこに含まれる情報の構造を密接に反映しています。たとえば、会社の従業員のエントリを持つディレクトリは、部門や場所別に編成されます。一般に、ディレクトリ情報ツリーの構造は、組織や地理に基づいて編成したり、組織と地理の要素を加味して編成したりします。もう 1 つの方法として、ディレクトリ情報ツリーの構造をインターネットドメインに従って編成することがあります。ディレクトリ情報ツリーを名前付きコンテキストに論理的に編成する方法については、第 3 章「ディレクトリサービスの計画」で説明します。

データ格納と名前付きコンテキスト

ディレクトリ情報は名前付きコンテキストに分割されます。「名前付きコンテキスト」とはディレクトリのサブツリーであり、サブツリーの一番上にあるエントリの識別名で識別されます。名前付きコンテキストは物理的な「データ格納」に格納されます。データ格納には複数の名前付きコンテキストを持つことができ、ディレクトリサーバーには複数のデータ格納を持つことができます。

同じデータ格納を指定する名前付きコンテキストを Sun Directory Services 管理コンソールではデータ格納接尾辞と呼びます。

ディレクトリ情報ツリーを名前付きコンテキストとデータ格納に分割して個別のサーバーに入れるときには、次の点を考慮する必要があります。

Sun Directory Services のデータ格納には、最高 4 つのデータ格納接尾辞と 100 万のエントリを収容できます。これ以上のエントリを格納する必要がある場合には、いくつかのデータ格納を 1 つまたは複数のサーバーにインストールし、それらの間に照会を作成します。Sun Directory Services で 100 万以上のエントリを格納する場合は、「照会」を参照してください。

インフラ情報

インフラ情報によって、ディレクトリサービスの構成要素の動作方法や、ディレクトリエントリの情報の解釈方法が決まります。インフラ情報には、ディレクトリスキーマ、知識情報、および構成要素の構成情報があります。

スキーマ

ディレクトリスキーマは、ディレクトリに格納するデータを記述する規則の集まりです。この規則は、許されるエントリの種類、その属性構造、および属性の構文を定義します。Sun Directory Services には定義済みのスキーマがあります。このスキーマは修正できますが、一定の制約があります。スキーマの変更方法については、「スキーマの変更」を参照してください。

知識情報と照会

ディレクトリサーバーは、知識情報を使って情報に対する要求を他のサーバーへ渡します。ディレクトリサーバーが持つ知識情報は、他の名前付きコンテキストを持つディレクトリサーバーへの参照となります。サーバーは、情報の要求を受け取ると、自身のローカルデータ格納の情報を使って要求に対応できるかどうかを調べます。対応できない場合は、定義されているそのデータ格納の照会を調べ、代替ディレクトリサーバーの詳細をディレクトリクライアントに返します。したがって、クライアントは、この要求を他のディレクトリサーバーへ送信できます。クライアントによっては、要求を代替サーバーに自動的に送信するものがあります。その場合、ユーザーは照会機構を意識する必要はありません。それ以外のクライアントは照会情報をユーザーに返します。

照会の使用例については、「例: XYZ Corporation の名前付きコンテキスト」を参照してください。

アクセス制御

ディレクトリ情報のアクセスは一連の規則によって制御されます。この規則によって、ユーザーが特定のエントリや属性に対しどのような操作ができるかが決まります。ユーザーに与えられるアクセス権のレベルは、ユーザーが指定する認証情報によって異なります。さらに、このレベルは、特定のエントリや属性に対してディレクトリ管理者が定義する特定の規則によっても異なります。

アクセス権のレベル

ディレクトリ情報のアクセス権には 5 つのレベルがあります。このレベルは、特権の低い順に次のようになります。

注 -

あるレベルの操作に対するアクセス権が与えられた場合、それより下のレベルのすべてのアクセス権がデフォルトで与えられます。たとえば、読み取りアクセス権は、デフォルトでは検索と比較のアクセス権を含みます。

エントリと属性の定義規則

アクセス制御規則は、あるエントリと属性群に対しどのユーザーにどのアクセス権を与えるかを定義するものです。たとえば、すべてのエントリにおけるパスワードを除くすべての属性の読み取りアクセス権と、パスワード属性に対する比較アクセス権をユーザーに与えることができます。

アクセス制御規則を適用するエントリまたは属性のセットは、次の機能を使用して定義できます。

たとえば、次のアクセス制御規則を定義できます。

アクセス制御規則は順番に適用されるので、それらをリストする順序が重要になります。つまり、特定の規則を前に記述し、一般的な規則をそれより後に記述する必要があります。構成ツールを使ってアクセス制御規則をどのように定義し、それらの順序をどのように指定するかについては、「アクセス制御の構成」を参照してください。

ディレクトリとのバインド

ディレクトリに対して定義されているアクセス制御規則によっては、一定の操作の際にディレクトリに「バインドする」必要があります。「バインド」とは、識別名とパスワードを指定することによって認証を受けることです。この処理によって、接続されている間のアクセス権のレベルが決まります。

たとえば、デフォルトのアクセス制御規則では、自身のディレクトリエントリのパスワードに対し書き込みアクセス権があります。エントリの識別名とパスワードを使ってバインドすると、そのユーザーは、そのエントリのキーワード「ユーザー自身 (self)」で識別されます。匿名のバインドでは、パスワード属性を除くすべてのエントリと属性に対し検索と読み取りのアクセス権があります。パスワード属性に対しては、比較アクセス権が与えられます。キーワード「全ユーザー (everyone)」または * が指定されているユーザーには、これらのアクセス権が与えられます。

デフォルトのアクセス制御規則

デフォルトのアクセス制御は、インストール時に次のように定義されます。

これらの規則は、特定のものから一般的なものへ順番に適用されます。

例 1-1 は、ディレクトリサーバー構成ファイル /etc/opt/SUNWconn/ldap/current/dsserv.acl.conf に定義されているデフォルトのアクセス制御です。

例 1-1 デフォルトのアクセス制御

access to attrs=userPassword	by self write
	by * compare

# Radius ACLs
access to attrs=chapPassword, radiusLoginPasswd, radiusPppPasswD,
radiusSlipPasswd
	by self write
	by * compare

access to attrs=sharedKey
	by self write
	by * compare

# dsyppasswdd ACLs
access to attrs=userPassword
	by self write
	by * compare

access to attrs=gecos,loginShell
	by self write

# SIMS ACLs
access to attrs=cn, dataSource, homeDirectory, mail, mailHost,
mailQuota, objectStatus, preferredRfc822Recipient, rfc822Mailbox,
uid
	by self read
	by * read

# Default ACLs
access to filter="joinable=TRUE" attrs=member,entry
	by dnattr=member selfwrite

access to * by self read

Sun Directory Services のアクセス制御規則の構成方法については、「アクセス制御の構成」を参照してください。

複製

同じ情報を複数のディレクトリサービスクライアントが要求した場合、その負荷をいくつかのディレクトリサーバーに分散できます。分散するには、複製（またはスレーブ）サーバーを定義して、ディレクトリサービスへの代替アクセス点をクライアントに提供する必要があります。マスター名前付きコンテキストは、複数の複製名前付きコンテキストを持つことができます。図 1-2 では、1 つのマスターサーバーに 2 つの複製サーバーがあります。「複製」の処理では、マスターデータ格納の変更がすべての複製名前付きコンテキストに反映されます。複製は、名前付きコンテキスト全体、サブツリー、または特定のエントリの単位で実行できます。さらに、エントリの内容全体または属性の一部を複製できます。

図 1-2 マスタサーバーと複製サーバー

Graphic

複製の機能には、次の利点があります。

注 -

同じディレクトリ情報の一部に、ユーザーごとに異なるアクセス制御を設定することもできます。ただし、専用のマシン上に部分的な複製を作成すれば、ネットワーク全体にアクセスされることはありません。さらにセキュリティを強化するには、複製の更新の間だけ複製サーバーをネットワークに接続することもできます。

複製を使用する場合、次の問題点があります。