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でオブジェクト・クラスを作成、表示および削除する方法について説明します。
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapmodify(1)コマンドを使用して、これらの定義に追加できます。
新しいオブジェクト・クラスの定義、およびユーザー定義オブジェクト・クラスへの変更はファイル99user.ldifに保存されます。
他のオブジェクト・クラスから継承されるオブジェクト・クラスをいくつか作成する場合、まず親のオブジェクト・クラスを作成する必要があります。新しいオブジェクト・クラスがカスタム属性を使用する場合は、まずその属性を定義する必要があります。
各オブジェクト・クラス定義には、少なくとも1つのOIDを指定する必要があります。新しいオブジェクト・クラスには、少なくとも次の要素を使用することを考慮してください。
オブジェクト・クラスOID。オブジェクト・クラスのオブジェクト識別子に相当します。OIDは通常、ドット区切りの10進数の文字列で、スキーマ・オブジェクトを一意に識別します。
LDAP v3に厳密に準拠するには、有効な数値のOIDを指定する必要があります。OIDについて学ぶには、またはユーザーの企業用に接頭辞を要求するには、IANA (Internet Assigned Number Authority)のiana@iana.org宛に電子メールを送付するか、IANAのWebサイトを参照してください。。
オブジェクト・クラス名。オブジェクト・クラスの一意の名前に相当します。
親オブジェクト・クラス。このオブジェクト・クラスが属性を継承する既存のオブジェクト・クラスです。
このオブジェクト・クラスを他の特定のオブジェクト・クラスから継承させない場合は、topを使用します。
一般に、ユーザー・エントリに新しい属性を追加する場合、親はinetOrgPersonオブジェクト・クラスとなります。企業エントリに新しい属性を追加する場合、通常、親はorganizationまたはorganizationalUnitとなります。グループ・エントリに新しい属性を追加する場合、通常、親はgroupOfNamesまたはgroupOfUniqueNamesとなります。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
Directory Serverにより、X-ORIGIN 'user defined'が指定した定義に追加されます。
例11-4 オブジェクト・クラスの作成
次の例では、ldapmodifyコマンドを使用して、新しいオブジェクト・クラスを追加します。
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif Enter bind password: modifying entry cn=schema $
本番環境では、1.2.3.4.5.6.8ではなく、有効な一意のOIDを指定します。
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapsearch(1)コマンドを使用して、これらの定義を読み取ることができます。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
例11-5 オブジェクト・クラスの表示
次のコマンドにより、すべてのオブジェクト・クラスの定義を表示します。
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses
-Tオプションにより、ldapsearchコマンドはLDIF行を折りたたまないため、grepまたはsedなどのコマンドを使用して出力の操作をより容易にできます。さらに、grepコマンドにより、コマンドの出力をパイプすると、ディレクトリ・スキーマのユーザー定義の拡張のみを表示できます。たとえば、次のようになります。
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined" objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) $
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapmodify(1)コマンドを使用して、X-ORIGIN 'user defined'を含む定義を削除できます。
スキーマは、cn=schemaのLDAPビューにより定義されるので、ldapsearchおよびldapmodifyユーティリティを使用してオンラインでスキーマを表示および変更できます。ただし、X-ORIGINフィールドに値’user defined’があるスキーマ要素しか削除できません。サーバーでは、その他の定義を削除しません。
ユーザー定義要素への変更は、ファイル99user.ldifに保存されます。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
詳細は、「オブジェクト・クラスを表示するには:」を参照してください。
例11-6 オブジェクト・クラスの削除
次のコマンドで、例11-4で作成したオブジェクト・クラスを削除します。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) ^D
X-ORIGIN 'user defined'を含める必要があることに注意してください。これは、このスキーマ定義を拡張として分類するために、Directory Serverにより追加されたものです。