第12章 ディレクトリースキーマの管理
Red Hat Directory Server には、数百のオブジェクトクラスおよび属性を含む標準スキーマが同梱されています。標準のオブジェクトクラスおよび属性はほとんどのデプロイメントの要件を満たす必要がありますが、特定のディレクトリーデータのスキーマを拡張しないといけない場合があります。スキーマの拡張は、新規オブジェクトクラスおよび属性を作成することで行われます。
『Red Hat Directory Server 11 の設定、コマンド、およびファイルリファレンス』 は、ほとんどの標準 Directory Server 属性およびオブジェクトクラスのリファレンスであり、許可された属性および必須属性、どのオブジェクトクラスがどの属性を取得するか、およびどの OID が値情報を取得するかの情報が含まれています。これは、ディレクトリーで有用なスキーマ要素を特定し、作成されるカスタムスキーマを決定するのに適したリソースです。
12.1. スキーマの概要 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリースキーマは、ディレクトリーへのデータの保存方法を定義する一連のルールです。ディレクトリー情報は個別のエントリーに保存され、各エントリーは属性のセットとその値で設定されます。エントリーで説明されるアイデンティティーの種類は、エントリーのオブジェクトクラスで定義されます。オブジェクトクラスは、オブジェクトクラスの定義された属性セットでエントリーが記述するオブジェクトの種類を指定します。
LDAP では、オブジェクトクラスはエントリーの定義に使用できる属性のセットを定義します。LDAP 標準仕様は、人、グループ、場所、組織、部門、機器など、多くの一般的なエントリーに対するオブジェクトクラスを提供します。ID は、属性とその値を含むディレクトリーエントリーで説明されています。ペアは、属性値表明 または AVA と呼ばれます。ディレクトリー内の情報には説明的な属性が関連付けられています。一致するルールや LDAP コントロールを含む Directory Server 設定のその他の側面は、スキーマにも定義されます。これらすべてが スキーマ要素 です。
すべての schema 要素は、一意のドット区切り番号で識別されます。これは オブジェクト ID または OID と呼ばれます。
12.1.1. デフォルトのスキーマファイル リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
Directory Server のスキーマは、複数のスキーマファイル (スキーマ要素を定義する LDIF ファイル) で定義されます。Directory Server スキーマファイルは、
/usr/share/dirsrv/schema/ ディレクトリーにあります。このディレクトリーのファイルは、新しい Directory Server インスタンスのテンプレートとして使用されます。このディレクトリーに新しいスキーマを追加すると、新しいインスタンスが利用可能になります。
Directory Server が操作を実行し、エントリーを管理するために使用する属性は、『Red Hat Directory Server 11 の設定、コマンド、およびファイルリファレンス』 で他の設定とともに説明されています。
12.1.2. オブジェクトクラス リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
LDAP では、オブジェクトクラスはエントリーの定義に使用できる属性のセットを定義します。LDAP 標準仕様は、ユーザー (person および inetOrgPerson)、グループ (groupOfNames)、場所 (locality)、組織および部門 (organization および organizationalUnit)、および機器 (device) など、多くの一般的なエントリーに対するオブジェクトクラスを提供します。
スキーマファイルでは、オブジェクトクラスは
objectclasses 行によって識別され、その後 OID、名前、説明、その直接の上位オブジェクトクラス (オブジェクトクラスと使用する必要のあるオブジェクトクラス、およびそのオブジェクトクラスと属性を共有するのに必要なオブジェクトクラス)、および必須属性の一覧 (MUST) および許可される属性の一覧 (MAY) が続きます。
これは、例12.1「個人のオブジェクトクラススキーマエントリー」 に示されています。
例12.1 個人のオブジェクトクラススキーマエントリー
objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 4519' )
すべてのオブジェクトクラスは、必須属性 (そのスキーマの MUST キーワード) および許可された属性 (そのスキーマの MAY キーワード) を定義します。必須属性は、指定されたオブジェクトクラスを使用するエントリーに存在する必要がありますが、許可された属性は許可されており、エントリーで使用できますが、エントリーが有効である必要はありません。
例12.1「個人のオブジェクトクラススキーマエントリー」 のように、person オブジェクトクラスには、
cn 属性、sn 属性、および objectClass 属性が必要で、description 属性、seeAlso 属性、telephoneNumber 属性、および userPassword 属性を許可します。
オブジェクトクラスは、独自の必須属性と許可される属性に加えて、別のクラスから属性を継承できます。2 つ目のオブジェクトクラスは、最初のオブジェクトクラスの superior または parent オブジェクトクラスです。
たとえば、ユーザーのエントリーに inetOrgPerson オブジェクトクラスが必要です。その場合、エントリーには、inetOrgPerson と organizationalPerson の上位オブジェクトクラスと、organizationalPerson の上位オブジェクトクラスである person も含める必要があります。
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
オブジェクトクラス定義は、cn=schema エントリーの
objectclasses 属性です。objectclasses 属性の形式は以下のとおりです。
objectclasses: ( definition )
objectclasses: ( definition )
オブジェクトクラス定義には複数のコンポーネントが含まれます。
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- SUP object_class の形式で、このオブジェクトクラスの上位または親のオブジェクトクラス。関連する親がない場合は、SUP top を使用してください。
- AUXILIARY という単語で、オブジェクトクラスを適用するエントリーのタイプを指定します。AUXILIARY は、任意のエントリーに適用できることを意味します。
- MUST の後に続く必要な属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
- MAY の後に続く許可される属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
顧客のオブジェクトクラス定義は、コマンドラインまたは Web コンソールで cn=schema エントリーを変更する場合に
/etc/dirsrv/slapd-instance_name/schema/99user.ldif に保存されます。
12.1.3. 属性 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーエントリーは、属性とその値で設定されます。これらのペアは、属性値表明 または AVA と呼ばれます。ディレクトリー内の情報には説明的な属性が関連付けられています。たとえば、
cn 属性は、cn: John Smith などのユーザーの氏名を保存するために使用されます。
追加の属性は、John Smith に関する補足情報を提供できます。
givenname: John surname: Smith mail: jsmith@example.com
givenname: John
surname: Smith
mail: jsmith@example.com
スキーマファイルでは、属性が以下によって記述されます。
- OID
- name
- 構文マッチングルール (任意)
- 部分文字列マッチングルール (任意)
- 順序ルール (任意)
- 説明 (任意)
- 構文
- 単値または多値の属性
- 属性が定義されている場所の詳細
これは、例12.2「
uid 属性スキーマエントリー」 に示されています。
例12.2 uid 属性スキーマエントリー
( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4519' )
( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4519' )
12.1.3.1. Directory Server 属性の構文 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
属性の構文は、属性が許可する値の形式を定義します。他のスキーマ要素と同様に、構文は、スキーマファイルエントリーで構文の OID を使用して属性に対して定義されます。
Directory Server は、属性の構文を使用してエントリーでのソートとパターン一致を実行します。
LDAP 属性の構文に関する詳細は、RFC 4517 を参照してください。
サポートされる LDAP 属性の構文については、Red Hat Directory Server 10 の設定、コマンド、およびファイルリファレンス の 『Directory Server 属性構文』 に記載されています。
12.1.4. スキーマの拡張 リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
新規、カスタム属性、およびオブジェクトクラスを Directory Server インスタンスに追加してスキーマを拡張することができ、スキーマ要素を追加する方法は複数あります。LDAP ツールを使用すると、インスタンスのデフォルトのカスタムスキーマファイルにスキーマ要素が追加されます (例:
99user.ldif)。新しい個別のスキーマファイルを作成し、デフォルトのスキーマファイルで追加することもできます。
新規スキーマ要素を追加するには、3 点が必要になります。
- 新規スキーマの OID の計画および定義。スキーマ要素はその OID によってサーバーが認識されるため、OID を一意で、整理することが重要です。Directory Server 自体は OID を管理しませんが、「オブジェクト識別子の管理」で説明するベストプラクティスがいくつかあります。
- 新しい属性を作成します。属性定義には名前、構文 (許可される値の形式)、OID、および属性をエントリーごとに一度または複数回使用できるかどうかの説明が必要です。
- 新規属性を含むオブジェクトクラスを作成します。オブジェクトクラスは、そのエントリータイプに必要な属性と許可される (許容) 属性をリスト表示します。デフォルトのスキーマは変更できないため、新規属性を作成している場合は、カスタムオブジェクトクラスに追加する必要があります。
スキーマ要素は事前に計画する必要があります。同じ情報に複数の属性を使用しないでください。可能な場合は、標準の Directory Server スキーマを使用します。Directory Server には、数百の属性があり、デフォルトのスキーマファイルで定義されたオブジェクトクラスが多数あります。『Red Hat Directory Server 11 の設定、コマンド、およびファイルリファレンス』 は、標準の属性およびオブジェクトクラスを一覧表示して説明します。スキーマはすべて
/usr/share/dirsrv/schema/ のスキーマファイルで確認できます。まずは、利用可能なスキーマを確認してください。次に、不足している情報属性と、不足している情報属性を補うためにカスタム属性を使用した最善の方法を計画します。スキーマのプランニングについては、『デプロイメントガイド』 で説明しています。
警告
Directory Server のデフォルトのオブジェクトクラスおよび属性は LDAP および X.500 標準仕様および RFC に基づいています。標準スキーマを使用すると、Directory Server が他のアプリケーションやサーバーとより簡単に統合され、LDAP クライアント、レガシー Directory Server インスタンス、および今後のリリースで相互運用性が可能になります。標準属性を編集したり、オブジェクトクラスを変更したりすることは推奨されません。
Directory Server スキーマをカスタマイズする場合は、以下のルールを念頭に置いてください。
- スキーマはできるだけシンプルに保ちます。
- 可能であれば、既存のスキーマ要素を再利用します。
- 各オブジェクトクラスに定義される必須属性の数を最小限に抑えます。
- 複数のオブジェクトクラスまたは属性を同じ目的で定義しないでください。
- 属性またはオブジェクトクラスの既存の定義は変更しないでください。
注記
標準スキーマを削除または置き換えることは ありません。これを行うと、他のディレクトリーやその他の LDAP クライアントアプリケーションとの互換性の問題が発生する可能性があります。
インスタンスが起動すると、スキーマが Directory Server インスタンスに読み込まれます。Directory Server が再起動するか、再読み込みタスクが開始されない限り、新しいスキーマファイルは読み込まれません。インスタンスのデフォルトのカスタムスキーマファイルは、99user.ldif が最後のスキーマファイルとして読み込まれます。標準スキーマファイルに定義がすでに含まれる場合、カスタム定義は標準スキーマファイルを上書きします。
12.1.5. スキーマレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリースキーマが cn=schema サブツリーで更新されると、Directory Server は変更状態番号 (CSN) を含むローカルの
/etc/dirsrv/slapd-instance_name/schema/99user.ldif ファイルに変更を保存します。更新されたスキーマは他のレプリカに自動的に複製されません。スキーマレプリケーションは、ディレクトリーのコンテンツが複製されたツリーで更新されると開始します。たとえば、スキーマの変更後にユーザーエントリーまたはグループエントリーを更新すると、nsSchemaCSN 属性に保存されている CSN と、コンシューマーにある CSN が比較されます。リモート CSN がサプライヤー上のものよりも小さい場合、スキーマはコンシューマーに複製されます。レプリケーションに成功すると、サプライヤーにあるすべてのオブジェクトクラスと属性タイプはコンシューマーの定義のスーパーセットである必要があります。
例12.3 スキーマのサブセットとスーパーセット
server1では、demo オブジェクトクラスはa1属性、a2属性、およびa3属性を許可します。server2では、demo オブジェクトクラスはa1属性およびa3属性を許可します。
例12.3「スキーマのサブセットとスーパーセット」では、
server1 にある demo オブジェクトクラスのスキーマ定義は、server2 のオブジェクトクラスのスーパーセットです。検証フェーズで、スキーマが複製または許可されると、Directory Server はスーパーセット定義を取得します。たとえば、ローカルスキーマのオブジェクトクラスがサプライヤースキーマのオブジェクトクラスよりも少ない属性を許可していることをコンシューマーが検出すると、ローカルスキーマが更新されます。
スキーマ定義が正常に複製された場合、
nsSchemaCSN 属性は両サーバーで同一であり、レプリケーションセッションの開始時に比較されなくなります。
以下のシナリオでは、スキーマは複製されません。
- あるホストのスキーマが、別のホストのスキーマのサブセットの場合たとえば、例12.3「スキーマのサブセットとスーパーセット」では、
server2にある demo オブジェクトクラスのスキーマ定義はserver1のオブジェクトクラスのサブセットです。サブセットは、属性 (単一値属性は複数値属性のサブセット) および属性の構文 (IA5はOctet_stringのサブセット) に対しても発生する可能性があります。 - サプライヤースキーマとコンシューマースキーマの定義をマージする必要がある場合Directory Server はマージスキーマをサポートしません。たとえば、1 台のサーバーのオブジェクトクラスが
a1属性、a2属性、およびa3属性を許可し、別のサーバーのオブジェクトクラスがa1属性、a3属性、およびa4属性を許可する場合、スキーマはサブセットではなく、マージできません。 /etc/dirsrv/slapd-instance_name/schema/99user.ldif以外のスキーマファイルが使用されます。Directory Server を使用すると、/etc/dirsrv/slapd-instance_name/schema/ディレクトリーにスキーマファイルを追加できます。ただし、99user.ldifファイルの CSN のみが更新されます。このため、他のスキーマファイルはローカルでのみ使用され、レプリケーションパートナーに自動的に転送されません。更新されたスキーマファイルをコンシューマーに手動でコピーし、スキーマを再読み込みします。詳細については、「スキーマの動的再読み込み」 を参照してください。スキーマ定義の重複を回避し、自動レプリケーションを有効にするには、すべてのカスタムスキーマを/etc/dirsrv/slapd-instance_name/schema/99user.ldifファイルに保存します。カスタムスキーマファイルの作成方法は、「カスタムスキーマファイルの作成」を参照してください。