2. Directory Serverのインスタンスと接尾辞
7. Directory Serverのパスワード・ポリシー
8. Directory Serverのバックアップとリストア
9. Directory Serverのグループ、ロールおよびCoS
スキーマ・ファイルおよびレプリケーションを使用したスキーマの拡張
スキーマ・ファイルおよびレプリケーションを使用してスキーマを拡張するには:
16. Directory Proxy Serverのツール
17. Directory Proxy Serverのインスタンス
19. Directory Proxy Serverの証明書
20. Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ
22. Directory Proxy Serverによる仮想化
24. Directory Proxy ServerとバックエンドLDAPサーバーの接続
25. クライアントとDirectory Proxy Serverの接続
26. Directory Proxy Serverのクライアント認証
27. Directory Proxy Serverのロギング
28. Directory Proxy Serverの監視とアラート
第3部 Directory Service Control Centerの管理
ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする際は、次のガイドラインに従います。
可能なかぎり、既存のスキーマ要素を再利用します。
各オブジェクト・クラスに対して定義する必須属性の数を最小限にします。
同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。
スキーマはできるかぎり簡潔にします。
スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除および置換は行わないでください。これを行うと、他のディレクトリおよびLDAPクライアント・アプリケーションとの互換性に問題が生じる可能性があります。
Directory Serverの内部操作属性は変更しないでください。ただし、外部のアプリケーション用に独自の操作変数を作成できます。
objectClass: extensibleObjectを使用するかわりに、常にオブジェクトクラスを定義しますDirectory Serverでは、オブジェクト・クラスextensibleObjectがあるエントリのスキーマ・チェックを実行しないため、エントリに存在する属性を制限したり、チェックしたりしません。アプリケーションでのタイプ・ミス(givenName属性タイプのgiveNameなど)は、Directory Serverでは認識されません。Directory Serverでは、extensibleObjectエントリの未定義属性はすべて複数値で、大文字/小文字が区別されないことを前提とします。さらに、特定のオブジェクト・クラスを持つエントリに依存するアプリケーションもあります。一般に、オブジェクト・クラスに対して拡張が必要なアプリケーションがある場合は、スキーマ管理を放棄しないでください。そのかわりに、アプリケーションで必要な属性を含む補助オブジェクト・クラスを作成します。
この項では、デフォルトのディレクトリ・スキーマについて、およびカスタムの属性とオブジェクト・クラスの作成について説明します。
Directory Serverで提供するスキーマについては、instance-path/config/schema/ディレクトリに格納されている一連のファイルで説明しています。
このディレクトリには、Directory Serverと関連製品の共通スキーマがすべて含まれます。LDAP v3ユーザーおよび組織用の標準スキーマは、00core.ldifファイル内に記述されています。旧バージョンのディレクトリで使用された構成スキーマは、50ns-directory.ldifファイル内に記述されています。オブジェクト・クラスや属性など、ユーザーが作成した要素は、99user.ldifに格納されます。
LDAPの各オブジェクト・クラスまたは属性には、一意の名前およびオブジェクト識別子(OID)を割り当てる必要があります。スキーマを定義する際は、組織に固有のOIDが必要になります。ユーザーのスキーマに対するニーズをすべて満たすには、1つのOIDで十分となります。属性およびオブジェクト・クラスのそのOIDに新しいブランチを追加します。
OIDの取得およびスキーマでの割当てでは、次の処理を行います。
IANA(Internet Assigned Numbers Authority)または国内の機関から組織のOIDを取得します。
国によっては、企業にすでにOIDが割り当てられています。組織がまだOIDを持っていない場合、IANAよりOIDを取得できます。
OIDの割当てを追跡できるように、OIDレジストリを作成します。
OIDレジストリは、ディレクトリスキーマで使用するOIDとOIDの説明を提供するリストで、作成者が保持します。OIDレジストリにより、OIDが複数の目的で使用されないようにできます。
OIDツリーにスキーマ要素を収容するブランチを作成します。
OIDブランチすなわちディレクトリ・スキーマの下に2つ以上のブランチ(属性用にOID.1、オブジェクト・クラス用にOID.2)を作成します。独自のマッチング・ルールや制御を定義する場合、必要に応じてOID.3などの新しいブランチを追加できます。
新規の属性およびオブジェクト・クラスの名前を作成する場合、スキーマで使用しやすいように、わかりやすい名前を作成します。
カスタム要素に一意の接頭辞を含めることにより、カスタム・スキーマ要素と既存のスキーマ要素の名前の競合を防ぎます。たとえばExample.com社では、各カスタム・スキーマ要素の前に接尾辞Exampleを追加できます。ExamplePersonという特殊オブジェクト・クラスを追加して、ディレクトリ内のExample.comの従業員を識別することもできます。
LDAPでは、属性タイプ名およびオブジェクト・クラス名は大文字と小文字の区別がないことに注意してください。アプリケーションでは、それらを大文字/小文字の区別なしで扱う必要があります。
既存のオブジェクト・クラスでは、ディレクトリ・エントリへ格納する必要のある情報のすべてがサポートされていない場合、新しいオブジェクト・クラスを追加します。
新しいオブジェクト・クラスを作成するには、次の2つの方法があります。
属性を追加する各オブジェクト・クラス構造に1つずつ、多数の新しいオブジェクト・クラスを作成します。
ディレクトリ用に作成する属性をすべてサポートする単一のオブジェクト・クラスを作成します。この種のオブジェクト・クラスは、AUXILIARYオブジェクト・クラスと定義して作成します。
サイトで属性ExampleDepartmentNumberおよびExampleEmergencyPhoneNumberを作成するとします。これらの属性のいくつかのサブセットを許可するオブジェクト・クラスを複数作成できます。ExamplePersonというオブジェクト・クラスを作成して、それがExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにします。ExamplePersonの親はinetOrgPersonです。ExampleOrganizationというオブジェクト・クラスを作成し、それもExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにできます。ExampleOrganizationの親はorganizationオブジェクト・クラスです。
新しいオブジェクト・クラスは、次のようにLDAP v3スキーマ・フォーマットで表されます。
objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson' DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) ) objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME 'ExampleOrganization' DESC 'Example Organization Object Class' SUP organization STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
または、これらの属性をすべて許可する単一のオブジェクト・クラスを作成することもできます。これらの属性を使用するエントリで、このオブジェクト・クラスを使用できます。この単一オブジェクト・クラスは、次のように表されます。
objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry' DESC 'Example Auxiliary Object Class' SUP top AUXILIARY MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
新しいExampleEntryオブジェクト・クラスには、構造的なオブジェクト・クラスに関係なく、任意のエントリで使用できることを示すAUXILIARYというマークが付けられます。
新しいオブジェクト・クラスの実装方法を決定する際には、次のことを考慮します。
複数のSTRUCTURALオブジェクト・クラスでは、作成および管理するスキーマ要素も増えます。
一般に、要素数を少なく抑えると、メンテナンスの必要性が軽減されます。しかし、スキーマに3つまたは4つ以上のオブジェクト・クラスを追加する場合は、単一オブジェクト・クラスを使用する方が簡単な場合があります。
複数のSTRUCTURALオブジェクト・クラスでは、より入念かつ厳密にデータ設計をする必要があります。
厳密なデータ設計では、個々のデータが配置されるオブジェクト・クラス構造を考慮する必要があります。この制約は役立つ場合もありますが、煩雑でもあります。
単一のAUXILIARYオブジェクト・クラスでは、複数のタイプのオブジェクト・クラス構造にデータを配置する場合に、データ設計が簡素化されます。
たとえば、個人およびグループの両方のエントリに、preferredOSを置くとします。このような場合、オブジェクト・クラスを1つのみ作成し、この属性を許可するようにできます。
実際のオブジェクトに関連するオブジェクト・クラスと目的に合ったグループ化を構成するグループ要素を設計します。
新しいオブジェクト・クラスには、必須属性を回避します。
属性を必要とすることにより、スキーマに柔軟性がなくなる可能性があります。新しいオブジェクト・クラスを作成する場合は、属性を要求するのではなく許可します。
新しいオブジェクト・クラスを定義したら、オブジェクト・クラスで許可される属性と必要とする属性、および継承するオブジェクト・クラスを決める必要があります。
既存の属性で、ディレクトリ・エントリに格納する必要がある情報のすべてをサポートしていない場合、新しい属性を追加します。可能なかぎり標準の属性を使用するようにします。デフォルトのディレクトリ・スキーマにある属性を検索して、それらの属性を新しいオブジェクト・クラスに関連付けて使用します。
たとえば、person、organizationalPersonまたはinetOrgPersonの各オブジェクト・クラスがサポートしている以外の情報を個人エントリに格納する場合もあります。ディレクトリに誕生日を格納する場合、標準のDirectory Serverスキーマにはそのような属性が存在しません。dateOfBirthという新しい属性を作成することはできます。この属性を許可する新しい補助クラスを定義することで、この属性が人々を表すエントリで使用できるようになります。