Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第12章 ディレクトリースキーマの管理

Red Hat Directory Server には、数百のオブジェクトクラスおよび属性を含む標準スキーマが同梱されています。標準のオブジェクトクラスおよび属性はほとんどのデプロイメントの要件を満たす必要がありますが、特定のディレクトリーデータのスキーマを拡張しないといけない場合があります。スキーマの拡張は、新規オブジェクトクラスおよび属性を作成することで行われます。
『Red Hat Directory Server 10 Configuration, Command, and File Reference』 は、ほとんどの標準の 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 10 の設定、コマンド、およびファイルリファレンス の他の構成設定で説明されています。』

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' )
Copy to Clipboard Toggle word wrap
すべてのオブジェクトクラスは、必須属性 (そのスキーマの 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
Copy to Clipboard Toggle word wrap

12.1.3. 属性
リンクのコピー

ディレクトリーエントリーは、属性とその値で構成されます。これらのペアは、属性値表明 または AVA と呼ばれます。ディレクトリー内の情報には説明的な属性が関連付けられています。たとえば、cn 属性は、cn: John Smith などのユーザーの氏名を保存するために使用されます。
追加の属性は、John Smith に関する補足情報を提供できます。 
givenname: John
surname: Smith
mail: jsmith@example.com
Copy to Clipboard Toggle word wrap
スキーマファイルでは、属性が以下によって記述されます。
  • 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' )
Copy to Clipboard Toggle word wrap

12.1.4. スキーマの拡張
リンクのコピー

新規、カスタム属性、およびオブジェクトクラスを Directory Server インスタンスに追加してスキーマを拡張することができ、スキーマ要素を追加する方法は複数あります。Directory Server Console または LDAP ツールを使用すると、インスタンスのデフォルトのカスタムスキーマファイルにスキーマ要素が追加されます(99 user.ldif )。新しい個別のスキーマファイルを作成し、デフォルトのスキーマファイルで追加することもできます。
新規スキーマ要素を追加するには、3 点が必要になります。
  1. 新規スキーマの OID の計画および定義。スキーマ要素はその OID によってサーバーが認識されるため、OID を一意で、整理することが重要です。Directory Server 自体は OID を管理しませんが、「オブジェクト識別子の管理」で説明するベストプラクティスがいくつかあります。
  2. 新しい属性を作成します。属性定義には名前、構文 (許可される値の形式)、OID、および属性をエントリーごとに一度または複数回使用できるかどうかの説明が必要です。
  3. 新規属性を含むオブジェクトクラスを作成します。オブジェクトクラスは、そのエントリータイプに必要な属性と許可される (許容) 属性を一覧表示します。デフォルトのスキーマは変更できないため、新規属性を作成している場合は、カスタムオブジェクトクラスに追加する必要があります。
スキーマ要素は事前に計画する必要があります。同じ情報に複数の属性を使用しないでください。可能な場合は、標準の Directory Server スキーマを使用します。Directory Server には、数百の属性があり、デフォルトのスキーマファイルで定義されたオブジェクトクラスが多数あります。『Red Hat Directory Server 10 の設定、コマンド、およびファイルリファレンス は』、標準の属性およびオブジェクトクラスを一覧表示して説明します。スキーマはすべて Directory Server コンソールに表示するか、/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 ファイルに保存します。カスタムスキーマファイルの作成方法は、「カスタムスキーマファイルの作成」を参照してください。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat