第 1 章   スキーマについて


この章では、ディレクトリスキーマの基本的な概念について説明し、スキーマの記述されたファイルを示します。オブジェクトクラス、属性、およびオブジェクト識別子 (OID) について説明し、サーバスキーマの拡張とスキーマ検査について簡単に説明します。

スキーマ定義

---

ディレクトリスキーマは、ディクトリ内にデータを格納する方法を定義したルールのセットです。データは、ディレクトリエントリの形式で格納されます。各エントリは、属性およびその値のセットです。各エントリは、オブジェクトクラスを保持する必要があります。オブジェクトクラスは、エントリに記述するオブジェクトの種類を指定し、内部に含まれる属性セットを定義します。スキーマは、許可するエントリのタイプ、属性構造、および属性の構文を定義します。スキーマが自分のニーズに合わない場合には、スキーマの変更および拡張が可能です。

オブジェクトクラス、属性、および Directory Server によるスキーマの使用方法に関する詳細は、『iPlanet Directory Server 導入ガイド』を参照してください。

オブジェクトクラス

LDAP では、オブジェクトクラスはエントリの定義に使用可能な属性セットを定義します。LDAP 標準は、次の基本的なオブジェクトクラスを提供します。

• Groups (各オブジェクトまたは各オブジェクトグループの順不同のリストを含む)

• Locations (国名や説明など)

• Organizations

• People

• Devices

オブジェクトクラスは、次の 3 つの部分に細分化できます。

• Structural: エントリが保持可能な属性で、各エントリが DIT 内で出現する場所を示します。このオブジェクトクラスは、実際に存在するオブジェクトを表します。エントリは structural オブジェクトクラスに所属する必要があります。このため、オブジェクトクラスのほとんどが structural オブジェクトクラスです。

• Auxiliary: エントリが保持可能な属性を示します。これは、実際に存在するオブジェクトを表すのではなく、いくつかの structural オブジェクトクラスに関連付けることにより、仕様を補完する追加属性です。各エントリが所属する structural オブジェクトクラスは 1 つだけですが、ゼロ個または複数個の auxiliary オブジェクトクラスに所属することが可能です。

• Abstract: 他の (structural) オブジェクトクラスのスーパークラスまたはテンプレートだけに使用する目的で定義します。これは、structural オブジェクトクラスセットに共通な既知の属性セットを収集する便利な方法です。これらのクラスを、ゼロから定義するのではなく、 abstract クラスのサブクラスから派生させることができるからです。エントリが abstract オブジェクトクラスに所属していない場合があることに留意してください。

現在のところ、Directory Server は structural オブジェクトクラスと auxiliary オブジェクトクラスを区別しません。

必須の属性および許可された属性

各オブジェクトクラスには、多数の必須の属性および許可された属性が含まれます。必須の属性とは、オブジェクトクラスを使用するエントリ内に存在する必要のある属性です。すべてのエントリには、objectClass 属性が必須です。この属性により、エントリに割り当てるオブジェクトクラスが定義されます。

許可される属性には、オブジェクトクラスを使用するエントリ内に存在可能な属性が含まれます。

例 : Object Class = person

必須の属性

objectClass
cn (common name)
sn (surname)

許可された属性

description
seeAlso
telephoneNumber
userPassword

オブジェクトクラスの継承

各エントリは、1 つの structural オブジェクトクラスに割り当てる必要があります。すべてのクラスは、top を継承します。他のオブジェクトクラスからも継承可能です。サーバのオブジェクトクラス構造により、特定のエントリの必須および許可された属性のリストが決定されます。たとえば、person エントリは、通常、次のオブジェクトクラス構造で定義されます。

objectClass: top
objectClass:person
objectClass: organizationalPerson
objectClass: inetOrgperson

この構造では、inetOrgperson は organizationalPerson および person オブジェクトクラスから継承します。このため、inetOrgperson オブジェクトクラスをエントリに割り当てる場合、このオブジェクトクラスは必須および許可された属性を自動的に上位オブジェクトクラスから継承します。

---

注	オブジェクトクラスの継承は、.ldif ファイル内に出現するオブジェクトクラスの順序に依存します。オブジェクトクラスが .ldif ファイルに出現する順序は、オブジェクトクラス階層と一致している必要があります。そうでなければ、サーバが起動しません。このため、別のオブジェクトクラスから継承したオブジェクトクラスは、.ldif ファイル内でこのオブジェクトクラスの後に配置してください。

---

属性

ディレクトリデータは、属性と値のペアで表現されます。ディレクトリ内の情報はすべて、記述属性と関連付けられます。

たとえば、ユーザの名前の格納には、commonName または cn 属性が使用されます。Barbara (Babs) Jensen という名前のユーザは、ディレクトリ内で次のように表現されます。

cn: Babs Jensen

ディレクトリ内に入力された各ユーザは、inetorgperson オブジェクトクラス内の属性集合により定義可能です。このエントリの定義には、次の属性も使用可能です。

givenname: Barbara
surname: Jensen
mail: bjensen@siroe.com

属性構文

各属性は、属性が提供する情報のタイプを示す構文定義を保持します。

Directory Server は、属性構文を使用して、ソートおよびパターンマッチングを実行します。

表 1-1 に、属性に適用可能なさまざまな構文メソッド、および各構文メソッドの OID と定義を示します。

表 1-1 属性構文

構文および OID	定義
Binary 1.3.6.1.4.1.1466.115.121.1.5	属性値がバイナリ形式であることを示す
Boolean 1.3.6.1.4.1.1466.115.121.1.7	属性値が True または False のいずれかであることを示す
Country String 1.3.6.1.4.1.1466.115.121.1.11	属性値が、出力可能な 2 文字に限定されることを示す (例、fr)
DN 1.3.6.1.4.1.1466.115.121.1.12	属性値が DN (識別名) であることを示す
DirectoryString 1.3.6.1.4.1.1466.115.121.1.15	属性値が大文字と小文字を区別しないことを示す
GeneralizedTime 1.3.6.1.4.1.1466.115.121.1.24	属性値が出力可能な文字列として符号化されることを示す。タイムゾーンを指定する必要がある。GMT の使用を強く推奨
IA5String 1.3.6.1.4.1.1466.115.121.1.26	属性値が大文字と小文字を区別することを示す
INTEGER 1.3.6.1.4.1.1466.115.121.1.27	有効な属性値が数字であることを示す
OctetString 1.3.6.1.4.1.1466.115.121.1.40	Binary と同じ
Postal Address 1.3.6.1.4.1.1466.115.121.1.41	属性値が次の形式で符号化されることを示す dstring[$ dstring]* ここで、各 dstring コンポーネントは、DirectoryString 構文の値として符号化される。dstring 内のバックスラッシュとドル記号は、区切り文字との混同を避けるため、引用符で囲む。多くのサーバで、postal address は最大 30 文字までの 6 行に制限されている。次に例を示す 1234 Main St.$Anytown, TX 12345$USA
TelephoneNumber 1.3.6.1.4.1.1466.115.121.1.50	属性値が電話番号の形式であることを示す。国際電話番号形式の使用を推奨
URI 1.3.6.1.4.1.250.1.57	属性値が、http://、https://、ftp、LDAP などの文字列で始まる URL 形式であることを示す。URI の動作は、IA5String と同じになる。RFC 2396 を参照

単一値属性および複数値属性

デフォルトでは、属性のほとんどが複数値です。これは、エントリが複数の値を持つ属性を含めることができるということです。たとえば、cn、 tel、および objectClass はすべて、複数値の保持が可能な属性です。単一値属性では、指定可能な属性のインスタンスは 1 つだけです。たとえば、uidNumber が取ることのできる値は 1 つだけです。

Directory Server 5.1 がサポートするスキーマ

---

iPlanet Directory Server 5.1 に同梱されたスキーマは、次のディレクトリに格納されたファイルセットに記述されています。

• /var/ds5/slapd-serverID/config/schema

新規オブジェクトクラスおよび属性を作成することにより、スキーマを変更できます。これらの変更は、99user.ldif という名前の別のファイルに保存されます。Directory Server に同梱の標準ファイルを変更しないでください。標準ファイルを変更すると、他の iPlanet 製品との互換性維持や、iPlanet 以外のベンダーのディレクトリサーバとの相互運用で問題が発生する可能性があります。

Directory Server による情報の格納方法、およびディレクトリスキーマの設計に関する情報については、『iPlanet Directory Server 導入ガイド』を参照してください。

次の表に、iPlanet Directory Server に同梱されたスキーマファイルを示します。表 1-2 には、Directory Server の使用するスキーマファイルを示します。表 1-3 には、他の iPlanet 製品が使用するスキーマファイルを示します。

表 1-2 Directory Server の使用するスキーマファイル

スキーマファイル名	目的
00core.ldif	X.500 と LDAP 標準 (RFC) で推奨されるコアスキーマで、Directory Server 自体が使用するスキーマ
05rfc2247.ldif	RFC 2247 と関連する試験的なスキーマ「Using Domains in LDAP/X.500 Distinguished Names」のスキーマ
05rfc2927.ldif	RFC 2927「MIME Directory Profile for LDAP Schema」のスキーマ
10rfc2307.ldif	RFC 2307「An Approach for Using LDAP as a Network Information Service」のスキーマ
20subscriber.ldif	iPlanet-Nortel 加入者の相互運用に対応した共通スキーマ要素
25java-object.ldif	RFC 2713「Schema for Representing Java(TM) Objects in an LDAP Directory」のスキーマ
28pilot.ldif	iPlanet の新規導入では推奨されない試験的な RFC (特に RFC 1274) のスキーマ
30ns-common.ldif	共通 iPlanet スキーマ
50ns-directory.ldif	iPlanet Directory Server 4.x の使用する追加スキーマ
50ns-value.ldif	iPlanet サーバの「value item」スキーマ
99user.ldif	顧客によるスキーマの変更

表 1-3 他の iPlanet 製品が使用するスキーマファイル 

スキーマファイル名	目的
50iplanet-servicemgt.ldif	iPlanet サービス管理スキーマ要素
50ns-admin.ldif	iPlanet Administration Services で使用されるスキーマ
50ns-calendar.ldif	iPlanet Calendar Server スキーマ
50ns-certificate.ldif	iPlanet Certificate Management System 用のスキーマ
50ns-compass.ldif	Netscape Compass Server 用のスキーマ
50ns-delegated-admin.ldif	iPlanet Delegated Administrator 4.5 用のスキーマ
50ns-legacy.ldif	古いバージョンの Netscape スキーマ
50ns-mail.ldif	iPlanet Messaging Server 用のスキーマ
50ns-mcd-browser.ldif	Netscape Mission Control Desktop - Browser 用のスキーマ
50ns-mcd-config.ldif	Netscape Mission Control Desktop - Configuration 用のスキーマ
50ns-mcd-li.ldif	Netscape Mission Control Desktop - Location Independence 用のスキーマ
50ns-mcd-mail.ldif	Netscape Mission Control Desktop - Mail 用のスキーマ
50ns-media.ldif	Netscape Media Server 用のスキーマ
50ns-mlm.ldif	iPlanet Mailing List Manager 用のスキーマ
50ns-msg.ldif	iPlanet Web Mail 用のスキーマ
50ns-netshare.ldif	iPlanet Netshare 用のスキーマ
50ns-news.ldif	iPlanet Collabra Server 用のスキーマ
50ns-proxy.ldif	iPlanet Proxy Server 用のスキーマ
50ns-wcal.ldif	iPlanet Web Calendaring 用のスキーマ
50ns-web.ldif	iPlanet Web Server 用のスキーマ

オブジェクト識別子 (OID)

---

オブジェクト識別子 (OID) は、LDAP と X.500 標準に準拠するため、すべての属性とオブジェクトクラスに割り当てられます。OID は、一般に、ドットで区切られた文字列で表現される一連の整数です。OID が指定されていない場合、Directory Server は自動的に ObjectClass_name-oid と attribute_name-oid を使用します。

Netscape ベース OID は、2.16.840.1.113730 です。

iPlanet Directory Server のベース OID は、2.16.840.1.113730.3 です。

iPlanet で定義された属性はすべて、ベース OID 2.16.840.1.113370.3.1 を保持します。

iPlanet で定義されたオブジェクトクラスはすべて、ベース OID 2.16.840.1.113730.3.2 を保持します。

OID に関する詳細情報や、企業の接頭辞の取得依頼については、IANA (Internet Assigned Number Authority) の Web サイト http://www.iana.org/ にアクセスしてください。

サーバスキーマの拡張

---

Directory Server スキーマには、たいていのニーズを満たす何百ものオブジェクトクラスと属性が含まれます。このスキーマに新規オブジェクトクラスと属性を使用して拡張することで、増大する企業のディレクトリサービス要件を満たすことができます。

スキーマに新規属性を追加する場合は、新規オブジェクトクラスを作成して、新規属性を含める必要があります (既存のオブジェクトクラスに新規属性を追加することにより、標準 LDAP スキーマに依存する既存の LDAP クライアントと Directory Server との互換性が犠牲になる可能性があります。このため、サーバをアップグレードする時に問題が発生する場合があります)。

サーバスキーマの拡張については、『iPlanet Directory Server 導入ガイド』を参照してください。

スキーマ検査

---

スキーマ検査を有効にして、Directory Server を実行する必要があります。

iPlanet Directory Server のスキーマ検査機能は、ディレクトリにエントリを追加した場合またはエントリを変更した場合に、エントリを検査して、以下の点を検証します。

• エントリ内のオブジェクトクラスと属性が、ディレクトリスキーマで定義されているか

• オブジェクトクラスに必須の属性がエントリに含まれているか

• オブジェクトクラスに許可された属性だけがエントリに含まれているか

LDIF を使用してデータベースをインポートする場合にも、スキーマ検査が実行されます。詳細は、iPlanet Directory Server の『管理者ガイド』を参照してください。