Red Hat Summit第5章 ディレクトリーエントリースキーマのリファレンス
5.1. Directory Server スキーマについて
本章では、ディレクトリースキーマの基本概念の概要を説明し、スキーマを記述するファイルをリスト表示します。オブジェクトクラス、属性、オブジェクト識別子 (OID) を記述し、サーバースキーマとスキーマチェックの拡張を簡単に説明します。
5.1.1. スキーマ定義
ディレクトリースキーマは、ディレクトリーへのデータの保存方法を定義する一連のルールです。ディレクトリー情報は個別のエントリーに保存され、各エントリーは属性のセットとその値で構成されます。エントリーで説明されるアイデンティティーの種類は、エントリーのオブジェクトクラスで定義されます。オブジェクトクラスは、オブジェクトクラスの定義された属性セットでエントリーが記述するオブジェクトの種類を指定します。
基本的に、スキーマファイルは、作成できるエントリーの種類 (オブジェクトクラス) と、それらのエントリーを記述する方法 (属性) のリストです。スキーマは、オブジェクトクラスおよび属性を 定義 します。スキーマは、属性値に含まれる形式 (属性の 構文) と、その属性のインスタンスが 1 つだけであるかどうかも定義します。
追加のスキーマファイルを DirectoryServer 設定に追加してサーバーにロードできるため、スキーマはカスタマイズ可能であり、必要に応じて拡張できます。
オブジェクトクラス、属性、および Directory Server がスキーマの使用方法についての詳細は、デプロイメントガイドを参照してください。
スキーマ定義に文字数が多すぎると、Directory Server は起動に失敗します。これらの場所では、LDAP 標準で、NAME キーワードと属性タイプの名前など、ゼロまたは多数のスペースを使用できるようにするスペースを 1 つだけ使用します。
5.1.1.1. オブジェクトクラス
LDAP では、オブジェクトクラスはエントリーの定義に使用できる属性のセットを定義します。LDAP 標準仕様は、ユーザー (person および inetOrgPerson)、グループ (groupOfUniqueNames)、場所 (locality)、組織および部門 (organization および organizationalUnit)、および機器 (device) など、多くの一般的なエントリーに対するオブジェクトクラスを提供します。
スキーマファイルでは、オブジェクトクラスは objectclasses 行によって識別され、その後 OID、名前、説明、その直接の上位オブジェクトクラス (オブジェクトクラスと使用する必要のあるオブジェクトクラス、およびそのオブジェクトクラスと属性を共有するのに必要なオブジェクトクラス)、および必須属性のリスト (MUST) および許可される属性のリスト (MAY) が続きます。
これは、例5.1「個人のオブジェクトクラススキーマエントリー」 に示されています。
例5.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 2256' )
5.1.1.1.1. 必須および許可される属性
すべてのオブジェクトクラスは、多数の必須属性と許可される属性を定義します。必須属性は、指定されたオブジェクトクラスを使用するエントリーに存在する必要がありますが、許可された属性は許可されており、エントリーで使用できますが、エントリーが有効である必要はありません。
例5.1「個人のオブジェクトクラススキーマエントリー」 と同様に、person オブジェクトクラスには cn、sn、および objectClass 属性が必要で、description (seeAlso、telephoneNumber、および userPassword 属性) を許可します。
すべてのエントリーには、エントリーに割り当てられたオブジェクトクラスをリスト表示する objectClass 属性が必要です。
5.1.1.1.2. オブジェクトクラスの継承
エントリーには、複数のオブジェクトクラスを含めることができます。たとえば、個人のエントリーは person オブジェクトクラスで定義されますが、同じユーザーが inetOrgPerson および organizationalPerson オブジェクトクラスの属性で記述することもできます。
さらに、オブジェクトクラスは階層的に実行できます。オブジェクトクラスは、独自の必須属性と許可される属性に加えて、別のクラスから属性を継承できます。2 つ目のオブジェクトクラスは、最初のオブジェクトクラスの superior オブジェクトクラスです。
サーバーのオブジェクトクラス構造は、特定のエントリーに必要な属性と許可される属性のリストを決定します。たとえば、ユーザーのエントリーに inetOrgPerson オブジェクトクラスが必要です。その場合、エントリーには、inetOrgPerson の上位オブジェクトクラスである organizationalPerson と、organizationalPerson の上位オブジェクトクラスである person も含める必要があります。
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
inetOrgPerson オブジェクトクラスがエントリーに割り当てられている場合、エントリーは上位オブジェクトクラスから必要な属性および許可される属性を自動的に継承します。
5.1.1.2. 属性
ディレクトリーエントリーは、属性とその値で構成されます。これらのペアは、属性値表明 または AVA と呼ばれます。ディレクトリー内の情報には説明的な属性が関連付けられています。たとえば、cn 属性は、cn: John Smith などのユーザーの氏名を保存するために使用されます。
追加の属性は、John Smith に関する補足情報を提供できます。
givenname: John surname: Smith mail: jsmith@example.com
スキーマファイルでは、属性は attributetypes 行で識別され、次に OID、名前、説明、構文 (値に使用できる形式)、任意で属性が単一の値または複数の値であるかどうか、および属性が定義されます。
これは、例5.2「説明属性スキーマエントリー」 に示されています。
例5.2 説明属性スキーマエントリー
attributetypes: ( 2.5.4.13 NAME 'description' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' )
一部の属性は省略できます。これらの略語は、属性定義の一部としてリストされています。
attributetypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) ...5.1.1.2.1. Directory Server 属性の構文
属性の構文は、属性が許可する値の形式を定義します。他のスキーマ要素と同様に、構文は、スキーマファイルエントリーで構文の OID を使用して属性に対して定義されます。Directory Server Console では、構文は分かりやすい名前で参照されます。
Directory Server は、属性の構文を使用してエントリーでのソートとパターン一致を実行します。
LDAP 属性の構文に関する詳細は、RFC 4517 を参照してください。
| 名前 | OID | 定義 |
|---|---|---|
| Binary | 1.3.6.1.4.1.1466.115.121.1.5 | 非推奨:代わりに Octet 文字列を使用してください。 |
| Bit String | 1.3.6.1.4.1.1466.115.121.1.6 |
|
| Boolean | 1.3.6.1.4.1.1466.115.121.1.7 | 許可される値が TRUE または FALSE の 2 つしかない属性の場合。 |
| 国文字列 | 1.3.6.1.4.1.1466.115.121.1.11 | 正確に 2 つの印刷可能な文字列文字に制限されている値の場合。たとえば、米国の場合は米国です。 |
| DN | 1.3.6.1.4.1.1466.115.121.1.12 | 識別名 (DN) である値の場合。 |
| 配信方法 | 1.3.6.1.4.1.1466.115.121.1.14 | 情報の配信やエンティティーへの問い合わせの推奨方法が含まれる値の場合。異なる値はドル記号 ($) で区切ります。以下に例を示します。 [literal,subs="+quotes,verbatim"] …. telephone $ physical …. |
| ディレクトリー文字列 | 1.3.6.1.4.1.1466.115.121.1.15 | 有効な UTF-8 文字列である値の場合。これらの値は、大文字と小文字を区別する場合もあります。Directory String および関連する構文では、大文字と小文字の区別のないマッチングルールの両方を使用できます。 |
| 拡張されたガイド | 1.3.6.1.4.1.1466.115.121.1.21 | 属性およびフィルターに基づく、複雑な検索パラメーターが含まれる値の場合。 |
| Facsimile | 1.3.6.1.4.1.1466.115.121.1.22 | ファックス番号を含む値の場合。 |
| Fax | 1.3.6.1.4.1.1466.115.121.1.23 | 送信されるファックスのイメージを含む値の場合。 |
| 一般化時間 | 1.3.6.1.4.1.1466.115.121.1.24 | 印刷可能な文字列としてエンコードされる値の場合。タイムゾーンを指定する必要があります。GMT 時間を使用することを強く推奨します。 |
| ガイド | 1.3.6.1.4.1.1466.115.121.1.25 | 廃止属性およびフィルターに基づく、複雑な検索パラメーターが含まれる値の場合。 |
| IA5 String | 1.3.6.1.4.1.1466.115.121.1.26 | 有効な文字列である値の場合。これらの値は、大文字と小文字を区別する場合もあります。IA5 String および関連する構文では、大文字と小文字の区別のないマッチングルールの両方を使用できます。 |
| 整数 | 1.3.6.1.4.1.1466.115.121.1.27 | 整数の値。 |
| JPEG | 1.3.6.1.4.1.1466.115.121.1.28 | イメージデータが含まれる値の場合。 |
| 名前および任意の UID | 1.3.6.1.4.1.1466.115.121.1.34 | DN と (オプションの) 一意の ID の組み合わせ値を含む値の場合。 |
| 数値文字列 | 1.3.6.1.4.1.1466.115.121.1.36 | 数値とスペースの両方の文字列を含む値の場合。 |
| OctetString | 1.3.6.1.4.1.1466.115.121.1.40 | バイナリーの値の場合は、バイナリー構文が置き換えられます。 |
| Object Class Description | 1.3.6.1.4.1.1466.115.121.1.37 | オブジェクトクラス定義を含む値の場合。 |
| OID | 1.3.6.1.4.1.1466.115.121.1.38 | OID 定義を含む値の場合。 |
| 住所 | 1.3.6.1.4.1.1466.115.121.1.41 |
[literal,subs="+quotes,verbatim"] ….1234 Main St.$Raleigh, NC 12345$USA …. 各 dstring コンポーネントは DirectoryString の値としてエンコードされます。バックスラッシュとドル文字は引用符で囲まれるため、行の区切り文字では間違いはなくなりました。多くのサーバーは、ポストアドレスを最大 30 文字までの 6 行に制限します。 |
| 出力可能な文字列 | 1.3.6.1.4.1.1466.115.121.1.44 | 印刷可能な文字列を含む値の場合。 |
| Space-Insensitive String | 2.16.840.1.113730.3.7.1 | スペースの区別のない文字列を含む値の場合: |
| TelephoneNumber | 1.3.6.1.4.1.1466.115.121.1.50 | 電話番号の形式にある値国際形式で電話番号を使用することが推奨されます。 |
| Teletex Terminal Identifier | 1.3.6.1.4.1.1466.115.121.1.51 | 国際電話番号が含まれる値の場合。 |
| Telex Number | 1.3.6.1.4.1.1466.115.121.1.52 | テレックス端末のテレックス番号、国コード、および回答コードを含む値の場合。 |
| URI |
|
5.1.1.2.2. 単一値および複数値の属性
デフォルトでは、ほとんどの属性は複数値です。つまり、エントリーに同じ属性を複数回追加できます。以下に例を示します。
dn: uid=jsmith,ou=marketing,ou=people,dc=example,dc=com ou: marketing ou: people
cn 属性、tel 属性、および objectclass 属性は、すべて複数の値を持つことができます。単一値である属性 (属性の 1 つのインスタンスのみを指定可能) は、単一の値のみを許可するようにスキーマに指定されます。たとえば、uidNumber は使用可能な値は 1 つしかないため、スキーマエントリーには SINGLE-VALUE という用語があります。属性が複数値の場合、値式はありません。
5.1.2. デフォルトの Directory Server スキーマファイル
Directory Server のテンプレートスキーマ定義は /etc/dirsrv/schema ディレクトリーに保存されます。これらのデフォルトのスキーマファイルは、新しい Directory Server インスタンスのスキーマファイルを生成します。各サーバーインスタンスには、/etc/dirsrv/slapd- instance/schema に独自のインスタンス固有のスキーマディレクトリーがあります。インスタンスディレクトリーのスキーマファイルは、そのインスタンスによってのみ使用されます。
ディレクトリースキーマを変更するには、インスタンス固有のスキーマディレクトリーに新しい属性と新しいオブジェクトクラスを作成します。デフォルトのスキーマは新規インスタンスの作成に使用され、各インスタンスには独自のスキーマファイルがあるため、各インスタンスの使用は若干異なるため、各インスタンスの使用を照合することができます。
Directory Server コンソールまたは LDAP コマンドを使用して追加されるカスタム属性は、99user.ldif ファイルに保存されます。その他のカスタムスキーマファイルは、各インスタンスの /etc/dirsrv/slapd-instance/schema ディレクトリーに追加できます。Red Hat Directory Server に同梱されている標準ファイルには変更を加えないでください。
Directory Server の情報やプランニングディレクトリースキーマに関する提案についての詳細は、デプロイメントガイドを参照してください。
| スキーマファイル | 目的 |
|---|---|
| 00core.ldif | X.500 および LDAP 標準 (RFC) から推奨されるコアスキーマ。このスキーマは、インスタンス設定の Directory Server 自体で使用され、サーバーインスタンスを起動します。 |
| 01core389.ldif | X.500 および LDAP 標準 (RFC) から推奨されるコアスキーマ。このスキーマは、インスタンス設定の Directory Server 自体で使用され、サーバーインスタンスを起動します。 |
| 02common.ldif | エントリーを設定するために使用される Directory Server で定義された RFC 2256、LDAPv3、および標準スキーマの標準関連のスキーマ。 |
| 05rfc2927.ldif | RFC 2927 からのスキーマ "MIME Directory Profile for LDAP Schema"。 |
| 05rfc4523.ldif | X.509 証明書のスキーマ定義。 |
| 05rfc4524.ldif | LDAP/X.500 スキーマをコーディングします。 |
| 06inetorgperson.ldif | RFC 2798、RFC 2079、および RFC 1274 の一部からの inetorgperson スキーマ要素。 |
| 10rfc2307.ldif | RFC 2307 からのスキーマ "An Approach for Using LDAP as a Network Information Service"。 |
| 20subscriber.ldif | Directory Server-Nortel サブスクライバーの相互運用性の一般的なスキーマ要素。 |
| 25java-object.ldif | RFC 2713 のスキーマ "Schema for Representing Java Objects in an LDAP Directory"。 |
| 28pilot.ldif | パイロット RFC、特に RFC 1274 からのスキーマで、新しいデプロイメントでの使用は推奨されなくなりました。 |
| 30ns-common.ldif | 共通スキーマ。 |
| 50ns-admin.ldif | 管理サーバーで使用されるスキーマ。 |
| 50ns-certificate.ldif | Red Hat 証明書システムで使用されるスキーマ。 |
| 50ns-directory.ldif | レガシー Directory Server 4.x サーバーによって使用されるスキーマ。 |
| 50ns-mail.ldif | メールサーバーのスキーマ。 |
| 50ns-value.ldif | Directory Server のバリューアイテムのスキーマ。 |
| 50ns-web.ldif | Web サーバーのスキーマ。 |
| 60autofs.ldif | 自動マウント設定のオブジェクトクラス。これは、NIS サーバーに使用される複数のスキーマファイルの 1 つです。 |
| 60eduperson.ldif | 企業関連の人や組織エントリーのスキーマ要素。 |
| 60mozilla.ldif | Mozilla 関連のユーザープロファイルのスキーマ要素。 |
| 60nss-ldap.ldif | GSS-API サービス名のスキーマ要素。 |
| 60pam-plugin.ldif | ディレクトリーサービスを PAM モジュールと統合するためのスキーマ要素。 |
| 60pureftpd.ldif | FTP ユーザーアカウントを定義するためのスキーマ要素。 |
| 60rfc2739.ldif | カレンダーおよび vCard プロパティーのスキーマ要素。 |
| 60rfc3712.ldif | プリンターを設定するためのスキーマ要素。 |
| 60sabayon.ldif | sabayon ユーザーエントリーを定義するためのスキーマ要素。 |
| 60sudo.ldif | sudo ユーザーおよびロールを定義するためのスキーマ要素。 |
| 60trust.ldif | NSS または PAM の信頼関係を定義するためのスキーマ要素。 |
| 99user.ldif | Directory Server コンソールから追加されるカスタムスキーマ要素。 |
5.1.3. オブジェクト識別子 (OID)
すべてのスキーマ要素には、属性やオブジェクトクラスなど、オブジェクト識別子 (OID) が割り当てられます。OID は、通常はドットで区切られた文字列として記述される整数のシーケンスです。すべてのカスタム属性とクラスは、X.500 および LDAP 標準に準拠する必要があります。
スキーマ要素に OID が指定されていない場合、Directory Server は ObjectClass_name-oid および attribute_name-oid を自動的に使用します。ただし、数値 OID の代わりにテキスト OID を使用すると、クライアント、サーバーの相互運用性、およびサーバーの動作に問題が発生する可能性があるため、数値 OID を割り当てることを強く推奨します。
OID をビルドできます。ベース OID は、組織のすべてのスキーマ要素に使用されるルート番号で、そこからスキーマ要素を増やすことができます。たとえば、ベース OID は 1 になります。その後、属性に 1.1 を使用するため、新しい属性の OID は 1.1.x です。オブジェクトクラスに 1.2 を使用するため、新しいオブジェクトクラスの OID は 1.2.x です。
Directory Server 定義のスキーマ要素では、ベース OID は以下のようになります。
-
Netscape のベース OID は
2.16.840.1.113730です。 -
DirectoryServer のベース OID は
2.16.840.1.113730.3です。 -
Netscape で定義されたすべての属性には、ベース
OID2.16.840.1.113370.3.1があります。 -
Netscape で定義されたすべてのオブジェクトクラスには、基本
OID2.16.840.1.113730.3.2があります。
OID に関する詳細や接頭辞を要求する場合は、Internet Assigned Number Authority (IANA) Web サイト (http://www.iana.org/) を参照してください。
5.1.4. スキーマの拡張
Directory Server スキーマには、ほとんどのディレクトリー要件を満たすために使用できる数百のオブジェクトクラスと属性が含まれています。このスキーマは、カスタムスキーマファイルを作成して、企業内のディレクトリーサービスの進化要件を満たす新しいオブジェクトクラスおよび属性で拡張できます。
スキーマに新しい属性を追加する場合、新しいオブジェクトクラスを作成してスキーマを含める必要があります。既存のオブジェクトクラスに新しい属性を追加すると、標準の LDAP スキーマに依存する既存の LDAP クライアントとの互換性が Directory Server の互換性が危険にさらされ、サーバーのアップグレード時に問題が発生する可能性があります。
サーバースキーマの拡張に関する詳細は、デプロイメントガイドを参照してください。
5.1.5. スキーマチェック
スキーマチェックとは、Directory Server が LDIF を使用してインポートされたデータベースで作成、変更、またはデータベースですべてのエントリーをチェックし、スキーマファイルのスキーマ定義に準拠することを確認します。スキーマチェックでは、次の 3 つのことを確認します。
- エントリーで使用されるオブジェクトクラスおよび属性はディレクトリースキーマで定義されます。
- オブジェクトクラスに必要な属性はエントリーに含まれます。
- オブジェクトクラスで使用できる属性のみがエントリーに含まれます。
スキーマチェックが有効になっている Directory Server を実行する必要があります。スキーマチェックを有効にする方法は、管理ガイドを参照してください。
5.1.6. 構文の検証
構文の検証 とは、Directory Server が属性の値が、その属性に必要な構文と一致することを確認することを意味します。たとえば、構文の検証では、新しい telephoneNumber 属性に、実際にその値に有効な電話番号が指定されていることを確認します。
基本設定では、構文検証 (スキーマチェックなど) により、ディレクトリーの変更がチェックされ、属性値が必要な構文と一致することが確認され、構文に違反する変更が拒否されます。オプションで、構文違反に関する警告メッセージをログに記録し、変更を拒否するか、変更プロセスを成功できるように構文の検証を設定できます。
すべての構文は、DN を除く RFC 4514 に対して検証されます。デフォルトでは、DN は RFC 1779 または RFC 2253 に対して検証されますが、RFC 4514 よりは厳格ではありません。DN の厳密な検証を明示的に設定する必要があります。
この機能は、バイナリー構文 (検証できない) および標準以外の構文 (定義された必要な形式がない) を除き、表5.1「サポートされる LDAP 属性構文」 に記載されるすべての属性構文を確認します。未検証 の構文は以下のとおりです。
- Fax (バイナリー)
- OctetString (binary)
- JPEG (バイナリー)
- バイナリー (標準以外)
- スペースに依存しない文字列 (非標準)
- URI (標準以外)
構文検証が有効になっている場合、属性がエントリーに追加または変更されるたびに、新しい 属性値がチェックされます。(構文はサプライヤーサーバーでチェックされているため、これには レプリケーション の変更は含まれません。)syntax-validation.pl スクリプトを実行して、既存 の属性値で構文違反の有無を確認することもできます。
構文の検証に関する詳細は、管理ガイドを参照してください。
