第5章 ディレクトリーエントリースキーマの参照

5.1. Directory Server スキーマ

本章では、ディレクトリースキーマの基本的な概念の概要と、スキーマを記述するファイルが記載されています。これはオブジェクトクラス、属性、およびオブジェクト識別子(OID)を記述し、サーバースキーマおよびスキーマチェックの拡張について簡単に説明します。

5.1.1. スキーマ定義

ディレクトリースキーマは、ディレクトリーへのデータの保存方法を定義する一連のルールです。ディレクトリー情報は個別のエントリーに保存され、各エントリーは属性のセットとその値で構成されます。エントリーで説明されるアイデンティティーの種類は、エントリーのオブジェクトクラスで定義されます。オブジェクトクラスは、オブジェクトクラスの定義された属性セットでエントリーが記述するオブジェクトの種類を指定します。

基本的に、スキーマファイルは、作成できるエントリーの種類( オブジェクトクラス)と、これらのエントリーの記述方法( 属性)です。スキーマは オブジェクトクラス および属性を定義します。スキーマは、属性値に含まれる形式(属性 の構文)と、その属性の単一インスタンスのみを含む形式を定義します。

追加のスキーマファイルを Directory Server 設定に追加し、サーバーにロードできるため、スキーマはカスタマイズ可能であり、必要に応じて拡張できます。

オブジェクトクラス、属性、および Directory Server がスキーマの使用方法についての詳細は、『デプロイメントガイド』を参照してください。

警告

スキーマ定義に多すぎる文字や文字が多すぎると、Directory Server が起動に失敗します。LDAP 標準で空白を 1 つ使用します。たとえば、NAME キーワードと属性タイプの名前の間など、スペースをゼロまたは多数に使用することができます。

5.1.1.1. オブジェクトクラス

LDAP では、オブジェクトクラスはエントリーの定義に使用できる属性のセットを定義します。LDAP 標準は、人(person および inetOrgPerson 、グループ(groupOfUniqueNames)、場所(locality)、組織および区分(organization および organization Unit、および機器(デバイス など、多くの一般的なエントリーに対してオブジェクトクラスを提供します。

スキーマファイルでは、オブジェクトクラスは 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. required および Allowed 属性

すべてのオブジェクトクラスは数多くの必須属性と許可された属性を定義します。必須属性は、指定されたオブジェクトクラスを使用するエントリーに存在する必要がありますが、許可された属性は許可されており、エントリーで使用できますが、エントリーが有効である必要はありません。

例5.1「個人のオブジェクトクラススキーマエントリー」 のように、人のオブジェクトクラス には cn、sn、およびtimeoutSeconds 属性 が必要です。また、説明seeAlso、 telephoneNumber、および userPassword 属性 を許可します。

注記

すべてのエントリーには エントリーに割り当てられたオブジェクトクラスを一覧表示するオブジェクトクラスが必要です。

5.1.1.1.2. オブジェクトクラスの継承

エントリーには複数のオブジェクトクラスを指定できます。たとえば、ユーザーのエントリーは person オブジェクトクラス によって定義されますが、同じ人も inetOrgPerson および organizationalPerson オブジェクトクラスの属性で記述することもできます。

さらに、オブジェクトクラスは階層的にすることができます。オブジェクトクラスは、独自の必須属性と許可される属性に加えて、別のクラスから属性を継承できます。2 つ目のオブジェクトクラス は最初の 上位のオブジェクトクラスです。

サーバーのオブジェクトクラス構造は、特定のエントリーに必要な属性および許可される属性の一覧を決定します。たとえば、ユーザーエントリーには inetOrgPerson オブジェクトクラス が必要です。その場合、エントリーには、inetOrgPerson の上位オブジェクトクラスである organizationalPerson と、organizationalPerson の上位オブジェクトクラスである person も含める必要があります。

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

inetOrgPerson オブジェクトクラス がエントリーに割り当てられると、エントリーは superior オブジェクトクラスから required および allowed 属性を自動的に継承します。

5.1.1.2. 属性

ディレクトリーエントリーは、属性とその値で構成されます。これらのペアは、属性値表明 または AVA と呼ばれます。ディレクトリー内の情報には説明的な属性が関連付けられています。たとえば、cn 属性を使用すると、cn : John のフルネームが格納されます。

追加の属性は、John Smith に関する補足情報を提供できます。

givenname: John
surname: Smith
mail: jsmith@example.com

スキーマファイルでは、属性は attributetypes の行で識別され、その後に OID、名前、説明、構文(その値の許容形式)、オプションで属性が単一または複数値であるか、属性が定義される場所が続きます。

これは、例5.2「description 属性スキーマエントリー」 に示されています。

例5.2 description 属性スキーマエントリー

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 コンソールでは、構文は平易な名前で参照されます。

Directory Server は、属性の構文を使用してエントリーでのソートとパターン一致を実行します。

LDAP 属性の構文に関する詳細は、RFC 4517 を参照してください。

表5.1 サポートされる LDAP 属性構文

名前OID定義

バイナリー

1.3.6.1.4.1.1466.115.121.1.5

非推奨。代わりに 10 月の文字列を使用してください。

ビット文字列

1.3.6.1.4.1.1466.115.121.1.6

'0101111101'B などのビット化値の場合。

ブール値

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 つの出力可能な文字列文字に限定される値の場合(例: US for the United States)。

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 番号を含む値の場合。

Fax

1.3.6.1.4.1.1466.115.121.1.23

送信した faxes のイメージが含まれる値の場合。

一般化時間

1.3.6.1.4.1.1466.115.121.1.24

出力可能な文字列としてエンコードされた値の場合。タイムゾーンを指定してください。GMT 時間を使用することが強く推奨されます。

ガイド

1.3.6.1.4.1.1466.115.121.1.25

廃止予定属性およびフィルターに基づく、複雑な検索パラメーターが含まれる値の場合。

IA5 文字列

1.3.6.1.4.1.1466.115.121.1.26

有効な文字列である値。これらの値は、大文字と小文字を区別する場合もあります。大文字と小文字を区別しないマッチングルールはいずれも IA5 文字列と関連構文で利用できます。

整数

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

バイナリーである値。これはバイナリー構文に代わるものです。

オブジェクトクラスの説明

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

postal-address = dstring *("$" dstring) 形式でエンコードされた値の場合以下に例を示します。

[literal,subs="+quotes,verbatim"] …​.1234 メイン St.$Raleigh, NC 12345$USA …​

dstring の各コンポーネントは、DirectoryString 値としてエンコードされます。バックスラッシュとドル文字が発生した場合は引用符で囲まれるため、行区切り文字は間違いではありません。多くのサーバーは、住所を最大 30 文字まで 6 行に制限します。

出力可能な文字列

1.3.6.1.4.1.1466.115.121.1.44

出力可能な文字列を含む値の場合

領域と機密文字列

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 番号

1.3.6.1.4.1.1466.115.121.1.52

telex number、国コード、および telex ターミナルの応答バックコードを含む値の場合。

URI

 

URL の形式での値については、http://、https://、ftp ://ldap://ldaps :// などの文字列で導入されます。URI は IA5 文字列と同じ動作を持ちます。この構文についての詳細は、RFC 4517 を参照してください。

5.1.1.2.2. 単一および Multi-Valued 属性

デフォルトでは、ほとんどの属性は多値です。つまり、エントリーに同じ属性を複数回追加できます。以下に例を示します。

dn: uid=jsmith,ou=marketing,ou=people,dc=example,dc=com
ou: marketing
ou: people

cntel、および objectclass 属性(例: すべてに 1 つの値)を指定できます。単一値である属性 - つまり、属性の 1 つのインスタンスのみを指定できます。単一の値のみを許可すると、スキーマで指定されます。たとえば、uidNumber は使用できる値を 1 つだけ持て、そのスキーマエントリーには SINGLE-VALUE という用語があります。属性が多値である場合、値式はありません。

5.1.2. デフォルトの Directory Server スキーマファイル

Directory Server のテンプレートスキーマ定義は /etc/dirsrv/schema ディレクトリーに保存されます。これらのデフォルトのスキーマファイルは、新しい Directory Server インスタンスのスキーマファイルを生成するために使用されます。各サーバーインスタンスには、/etc/dirsrv/slapd-instance/schema に独自のインスタンス固有のスキーマディレクトリーがあります。インスタンスディレクトリーのスキーマファイルは、そのインスタンスによってのみ使用されます。

ディレクトリースキーマを変更するには、インスタンス固有のスキーマディレクトリーに新しい属性と新しいオブジェクトクラスを作成します。デフォルトのスキーマは新規インスタンスの作成に使用され、各インスタンスごとに独自のスキーマファイルがあるため、各インスタンスに対してスキーマが若干異なるため、各インスタンスの使用を一致させることができます。

Directory Server Console または LDAP コマンドを使用して追加したカスタム属性は 99user.ldif ファイルに保存されます。他のカスタムスキーマファイルは、各インスタンスの /etc/dirsrv/slapd-インスタンス/schema ディレクトリーに追加できます。Red Hat Directory Server に含まれる標準ファイルの変更しないでください。

Directory Server の情報やプランニングディレクトリースキーマに関する提案についての詳細は、『デプロイメントガイド』を参照してください。

表5.2 スキーマファイル

スキーマファイル目的

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 からのスキーマ「LDAP をネットワーク情報サービスとして使用するためのアプローチ」。

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 Certificate System が使用するスキーマ。

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 を使用するため、新しい属性はすべて 1.1.x の OID を持ちます。これはオブジェクトクラスに 1.2 を使用するため、新規オブジェクトクラスに 1.2.x のすべてのオブジェクトクラスには 1.2.x の OID があります。

Directory Server の定義するスキーマ要素の場合、ベース OID は以下のようになります。

  • Netscape ベース OID は 2.16.840.1.113730 です。
  • Directory Server ベース OID は 2.16.840.1.113730.3 です。
  • すべての Netscape-defined 属性には、ベース OID 2.16.840.1.113370.3.1 があります
  • すべての Netscape-defined オブジェクトクラスにはベース OID 2.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 スクリプトを実行して、構文違反の 既存の 属性値を確認することもできます。

構文の検証に関する詳細は、『管理ガイド』を参照してください。