33 ディレクトリ・スキーマの管理
トピック
個々のスキーマ要素の詳細は、「Oracle Unified Directoryスキーマ・モデルの理解」を参照してください。
33.1 Oracle Unified Directoryにおけるスキーマの理解
スキーマでは、ディレクトリへの格納が可能な情報オブジェクトのタイプが定義および制御されます。スキーマによって、ディレクトリ情報ツリー内のエントリのタイプが定義され、要素の一意性が維持されます。また、新しい要素がディレクトリに追加されるときに発生することがある未チェックのスキーマの増大が防止されます。
この項の内容は次のとおりです。
33.1.1 Oracle Unified Directoryスキーマについて
ディレクトリ・サーバー・インスタンスは、起動時に一度スキーマを読み取ります。その後、スキーマ情報を使用して、検索フィルタ・リクエストまたはアサーションをエントリの属性と照合し、追加または変更操作がクライアントによって許可されているかどうかを判定します。
通常、ほとんどのアプリケーションにはデフォルトのスキーマで間に合います。しかし、ディレクトリ・サーバーの柔軟性を活用して、アプリケーションに合せてスキーマを拡張することもできます。一般的な手順では、新しいカスタムのスキーマの採用時に標準のスキーマを放棄するのではなく、標準の属性またはオブジェクト・クラスを可能なかぎり使用します。標準のスキーマで処理されないカスタム属性またはオブジェクト・クラスが必要な場合は、アプリケーションで必要な補助属性およびオブジェクト・クラスを使用して標準のスキーマを拡張することによって、スキーマを作成できます。
スキーマはディレクトリ内の接尾辞(cn=schema)の下に格納されます。またディレクトリ・サーバーには、スキーマ要素を定義するサブスキーマ・サブエントリと、ディレクトリでの操作属性セットも格納されます。
スキーマは次の2つの方法のいずれかで拡張できます:
-
LDAPを介してスキーマを拡張します。
-
カスタムのスキーマ定義ファイルを作成します。
33.1.2 スキーマの設計および拡張
デフォルト・スキーマの拡張または独自のスキーマの設計について検討する場合は、事前にスキーマの構文と設計を確実に理解する必要があります。
スキーマの設計または拡張の基本ステップは次のとおりです:
- データをデフォルト・スキーマにマップします。ディレクトリ・サーバーに定義されている既存のスキーマ要素をできるかぎり使用します。標準のスキーマ要素は、ディレクトリ対応アプリケーションとの互換性を確保するうえで役立ちます。スキーマはLDAP標準に基づいているため、多数のディレクトリ・ユーザーからレビューされ、これらのユーザーの合意を得ています。
- 一致しないデータを特定します。デフォルト・スキーマは様々な情報オブジェクトに対応するように設計されています。しかし、特定のデータ型がこのスキーマで処理されない場合は、そのデータをノートするとともに、ディレクトリに必要な他のデータ型をノートにとります。
- デフォルト・スキーマを拡張して、新しい要素を定義します。最適なパフォーマンスを達成するには、できるかぎり既存のスキーマ要素を再利用します。また、各オブジェクト・クラスに対して定義する必須属性を最小限に抑えます。スキーマはできるかぎり簡潔にします。同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。
- スキーマ・チェックを使用します。スキーマ・チェックによって、属性とオブジェクト・クラスをスキーマ・ルールに準拠させることができます。
- 一貫性のあるデータ書式を選択し、適用します。LDAPスキーマでは、属性値に任意のデータを設定できます。しかし、LDAPクライアント・アプリケーションおよびディレクトリ・ユーザーに適した書式を選択して、一貫性のある方法でデータを格納するようにしてください。
33.1.3 デフォルト・スキーマ・ファイル
ディレクトリ・サーバー付属のデフォルト・スキーマは、OUD_ORACLE_HOME/config/schemaに格納されたLDIFファイルの集合です。これらのスキーマ・ファイルは、そのOUD_ORACLE_HOMEに関連付けれたすべてのサーバー・インスタンスに適用されます。
ディレクトリ・サーバー・インスタンスは、サーバーの起動時にスキーマ・ファイルを英数字順に(数字が先)ロードします。
注意:
これらのファイル内の標準のスキーマ定義と内部操作属性は決して変更しないでください。
次の表で、各デフォルト・スキーマ・ファイルとそれぞれのファイルの内容を説明します。
表33-1 デフォルト・スキーマ・ファイル
| スキーマ・ファイル | 説明 |
|---|---|
|
|
LDAPv3標準ユーザーおよび組織に関するスキーマ定義を格納します。 |
|
|
|
|
|
ディレクトリ構成ファイル内の属性とオブジェクト・クラスの定義に関するスキーマ定義を格納します。 |
|
|
|
|
|
RFC 2713に基づくLDAPディレクトリでのJavaオブジェクトの表現に関するスキーマ定義を格納します。 |
|
|
RFC 2714に基づくLDAPディレクトリでのCORBAオブジェクト参照の表現に関するスキーマ定義を格納します。Common Object Request Broker Architecture (CORBA)は、マルチベンダー、マルチプラットフォーム環境でCORBAオブジェクトを使用してマシンを統合します。ディレクトリ・サーバーをCORBAオブジェクト参照のリポジトリにすることで、CORBAに準拠したアプリケーションでのサービスの集中管理が可能になります。 |
|
|
RFC 2739に基づくvCardディレクトリのカレンダ属性の表現に関するスキーマ定義を格納します。カレンダ・アプリケーションは、ディレクトリ内に配置されている、個人のカレンダのURIを特定するようにカレンダ・ユーザー・エージェントに要求します。ノート: RFC 2739の定義にはエラーがいくつか含まれています。これらのいくつかの問題を修正するために、このスキーマ・ファイルは標準の定義を変更したものとなっています。 |
|
|
RFC 2926に基づくサービス・ロケーション・プロトコル(SLP)通知のマッピングに関するスキーマ定義を格納します。この仕様は、SLPテンプレートとLDAPディレクトリ・スキーマ間のマッピングを作成するSLPディレクトリ・エージェント・バックエンドをディレクトリ・サーバーで処理することを可能にします。 |
|
|
RFC 3112に基づく認証パスワード構文に関するスキーマ定義を格納します。 |
|
|
RFC 3712に基づくディレクトリでのプリンタ情報の格納に関するスキーマ定義を格納します。 |
|
|
RFC 4403に基づくディレクトリでのUDDI v3情報の格納に関するスキーマ定義を格納します。Universal Description, Discovery and Integration (UDDI)は、企業向けの、プラットフォームに依存しないXMLベースのインターネット上のレジストリです。UDDIによって、企業はインターネットを介してサービス・リストを公開できます。UDDIでは、どのソフトウェア・アプリケーションがインターネット上で相互作用を行うかが定義されます。 |
|
|
|
|
|
ディレクトリ・ユーザー・エージェント(DUA)のプロファイルおよびプリファレンスのスキーマを定義するRFC 4876に基づくスキーマ定義を格納します。 |
|
|
SolarisおよびOpenSolaris LDAPネーミング・サービスに必要なスキーマ定義を格納します。 |
|
|
ディレクトリ・サーバー構成で使用する属性タイプとオブジェクト・クラスの定義を格納します。 |
|
|
Active Directoryページング関数に必要なスキーマ定義を格納します。 |
|
|
プロキシ・サーバー・インスタンスの配信機能に必要なスキーマ定義を格納します。 |
|
|
プロキシ・サーバー・インスタンスのグローバル索引付け機能に必要なスキーマ定義を格納します。 |
|
|
プロキシ・サーバー・インスタンスのロード・バランシング機能に必要なスキーマ定義を格納します。 |
|
|
プロキシ・サーバー・インスタンス固有のスキーマ定義を格納します。 |
|
|
レプリケーション・ゲートウェイ・サーバー・インスタンス固有のスキーマ定義を格納します。 |
|
|
プロキシ・サーバー・インスタンスの仮想化機能に必要なスキーマ定義を格納します。 |
33.2 スキーマ・チェックの構成
Oracle Unified Directoryは、新規書込みまたは追加エントリがディレクトリ・サーバーのスキーマに準拠しているかどうかを検証するスキーマ・チェック・メカニズムを備えています。このメカニズムによって、import-ldifを使用してインポートされるデータや、ldapmodifyを使用して追加されるデータをスキーマの構文ルールに確実に準拠させることができます。
スキーマ・チェック構成は拡張グローバル構成の一部であり、次のコマンドを使用して表示できます:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ --advanced get-global-configuration-prop Property : Value(s) ---------------------------------------:--------------------------------------- ... check-schema : true ... invalid-attribute-syntax-behavior : reject ... single-structural-objectclass-behavior : reject ...
スキーマ・チェックは次の構成プロパティによって制御されます:
-
check-schema。使用可能な値は、true(デフォルト)、falseです。このプロパティでは、新たにインポートまたは追加されるエントリに対してディレクトリ・サーバーでスキーマ・チェックを実行するかどうかが制御されます。デフォルトでは、このプロパティはtrueに設定されます。最大のパフォーマンスが得られるようにサーバーを構成する必要があり、スキーマ違反を発生させる変更をクライアントが行わないことが確実であれば、このプロパティをfalseに設定できます。ディレクトリにもたらす可能性があるリスクと比較すると、パフォーマンス上の利点はわずかしかありません。 -
invalid-attribute-syntax-behavior。使用可能な値は、reject(デフォルト)、acceptおよびwarnです。このプロパティでは、関連付けられた構文に違反する属性値の使用が試みられた場合のサーバーの動作が制御されます。デフォルトでは、サーバーはスキーマに違反する属性を使用するあらゆるリクエストを拒否します。このプロパティがacceptに設定されている場合、サーバーは属性違反を警告なしで受け入れます。このプロパティがwarnに設定されている場合、サーバーは違反を受け入れますが、エラー・ログにメッセージを書き込みます。check-schemaプロパティがfalseに設定されている場合、無効な属性構文のチェックは適用されません。 -
single-structural-objectclass-behavior。使用可能な値は、reject(デフォルト)、acceptおよびwarnです。このプロパティでは、構造化オブジェクト・クラスを正確に1つ持っているという条件に一致しないエントリの作成または変更が試みられた場合のサーバーの動作が制御されます。つまりデフォルトでは、構造化オブジェクト・クラスをまったく持たないかまたは複数持つオブジェクト・クラスは拒否されます。このプロパティがacceptに設定されている場合、構造化オブジェクト・クラスを持たないエントリが許可されます。このプロパティがwarnに設定されている場合、構造化オブジェクト・クラスをまったく持たない(または複数持つ)エントリが許可されますが、エラー・ログにメッセージが書き込まれます。check-schemaプロパティがfalseに設定されている場合、単一構造化オブジェクト・クラス・チェックは適用されません。
注意:
これらのプロパティの値をデフォルトから変更すると、スキーマの整合性が危険にさらされるため、通常は、これらの値を変更しないでください。
33.3 オブジェクト識別子(OID)の使用
オブジェクト識別子(OID)は、ディレクトリ内のオブジェクトを一意に識別するために使用される数値文字列です。OIDは、ディレクトリ・スキーマ、制御および拡張操作で要素の一意の識別を必要とする場合に使用されます。
この項の内容は次のとおりです。
33.3.1 オブジェクト識別子(OID)について
LDAPオブジェクト・クラスおよび属性にはベース・オブジェクト識別子(OID)が必要です。ディレクトリでの名前の競合を避けるために、このOIDは、組織内で一意にする必要があります。
ディレクトリを組織の内部で使用することを計画している場合は、ディレクトリ・サーバーで提供されるOIDを使用してください。スキーマをエクスポートすることや、なんらかの方法でスキーマを公開することを計画している場合は、自組織用の一意のOIDのリクエストを入力することを検討してください。詳細は、「ベースOIDの取得」を参照してください。
ベースOIDの取得後、組織のオブジェクト・クラスと属性用にそのOIDにブランチを追加できます。たとえば、ディレクトリ・サーバーは、割当て済ベースOIDとして1.3.6.1.4.1.26027を使用します。コンポーネント・タイプごとに、ディレクトリ・サーバーは各スキーマ・コンポーネントのベースOIDに一意のブランチ番号を提供します。
Oracle Unified Directoryは包括的なOIDセットを備えおり、ほとんどのアプリケーションにはこのセットで間に合います。
次の表に、各スキーマ・コンポーネントに使用されるベースOIDを示します:
表33-2 各スキーマ・コンポーネントに使用されるベースOID
| OID値 | タイプ |
|---|---|
|
|
属性 |
|
|
オブジェクト・クラス |
|
|
属性構文 |
|
|
一致ルール |
|
|
コントロール |
|
|
拡張操作 |
|
|
一般的な使用 |
|
|
試験的な使用 |
スキーマ・タイプごとに、一意のブランチ番号がベースOIDに追加されます。たとえば、属性タイプでは、ブランチ番号1が使用され、1.3.5.1.4.1.26027.1.*1*というOIDが形成されます。ディレクトリ・サーバーによって、個々の属性タイプごとに別のブランチ番号セットが1つずつ割り当てられます。
次の表に、各属性タイプに割り当てられたOID値のリスト(一部)を示します。
表33-3 各属性タイプに割り当てられたOID値
| OID値 | 属性タイプ |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oracle Unified Directoryでは非数値OIDを使用できます。ただし、対応する数値OIDがスキーマ内で定義されていることが前提となります。たとえば、名前付き属性myTestAttributeに対して、非数値OID、mytestattribute-oidを使用できます。非数値OIDは、すべて小文字で構成され、名前付き属性に-oidが付加されたものである必要があります。非数値OIDの使用はLDAP仕様違反ですが、使いやすさを考慮して許容されています。
33.3.2 ベースOIDの取得
ディレクトリ・サーバーを公開することを計画している場合や、スキーマ定義をカスタム・アプリケーション用に再配布することを計画している場合は、自組織用のベースOIDを取得できます。ディレクトリ・サーバーのカスタム拡張を作成することを計画している場合は、カスタム・スキーマ・ファイルで独自のOIDを使用できます。または、ベースOIDをそのブランチ番号とともに追加することによって、スキーマ構成ファイルを変更できます。
ノート:
デフォルトOIDの変更は、この操作の影響を十分に理解している場合を除いて、行わないでください。OIDを変更すると、ディレクトリ・サーバーが破損する可能性があります。
組織のベースOIDを取得および作成するには:
- ブラウザから、Internet Assigned Numbers Authority (IANA)のWebサイト(
http://www.iana.org)またはこの種のタスクを行っている国内組織のサイトにアクセスします。国によっては、企業にすでにOIDが割り当てられています。自組織用のOIDがまだ割り当てられていない場合は、IANAのWebサイトでリクエストを入力できます。 - 一意のオブジェクト・クラス、属性、名前およびその他のスキーマ要素について決定します。スキーマの管理を容易化するために、わかりやすい名前を使用してください。カスタムのオブジェクト・クラスと属性にカスタムの接頭辞を追加するのも1つの方法です。たとえば、Example.comという組織の場合、各カスタム・スキーマ要素の前に
Exampleという接頭辞を追加します。例として、Personというオブジェクト・クラスがある場合、このクラスにExampleを付けて、ExamplePersonとします。 - OIDの割当てを追跡するためのOIDレジストリを作成します。このレジストリは単なるリストであり、このリストを管理することによって、各OIDとその説明をディレクトリ内で確実に一意のものにします。このレジストリには十分な保護を適用し、特権のある管理者以外、このレジストリを変更できないようにします。
- スキーマ要素を格納するブランチをOIDツリー内に作成します。
- トポロジ内のディレクトリ・サーバーを停止します。
- トポロジ内の各ディレクトリ・サーバーでスキーマ構成ファイルを手動で編集します。各OIDを自社のOIDに置き換えます。それによって、スキーマ・レプリケーションでのスキーマ内の相違の認識と情報の同期試行に関連する問題が回避されます。
- カスタムのスキーマ拡張を手動で編集します。理想的には、カスタム拡張はいずれも別のファイルで定義します。
33.4 スキーマの拡張
Oracle Unified Directoryでは、複数のスキーマ拡張方法をサポートしています。
この項の内容は次のとおりです。
33.4.1 スキーマの拡張について
Oracle Unified Directoryでは、複数のスキーマ拡張方法をサポートしています。標準のスキーマ・ファイルは、OUD_ORACLE_HOME/config/schemaにあるLDIFファイル・セットです。これらのファイルの直接的な変更は行わないでください。このような変更によって、サーバーが予測不可能な動作を起こす可能性があります。
標準のスキーマ定義は、そのOUD_ORACLE_HOMEに関連付けられた各サーバー・インスタンスに適用されます。instance-dir/OUD/config/schema/99-user.ldifにあるカスタム・スキーマ定義は、その定義の作成場所のサーバー・インスタンスにのみ適用されます。
スキーマは次の方法で拡張できます:
-
LDAPを介してスキーマを拡張します。スキーマ拡張を定義してLDIFファイルに定義を書き込み、
ldapmodifyコマンドを使用してカスタム・スキーマ拡張を追加します。この方法を使用した場合、ディレクトリ・サーバーによって、新しいスキーマ定義が次のファイルに自動的に書き込まれます:
instance-dir/OUD/config/schema/99-user.ldif別のスキーマ・ファイルを指定するには、
X-SCHEMA-FILE要素をスキーマ・ファイルの名前とともに含めます。たとえば、属性タイプ定義の一部として、要素X-SCHEMA-FILE '98myschema.ldif'を含めます。LDAPを介してスキーマを拡張した場合は、サーバーを再起動しなくてもスキーマの変更が考慮されます。
-
カスタム・スキーマ・ファイルを作成します。定義を格納したカスタム・スキーマ・ファイルを作成し、そのファイルを次のディレクトリに移動します:
instance-dir/OUD/config/schema/ディレクトリ・サーバーはスキーマ・ファイルを英数字順に(数字が先)ロードします。そのため、カスタム・スキーマ・ファイルには
[00-99]filename.ldifという名前を付けてください。この数字は、定義済の標準のスキーマ・ファイルのどれよりも大きい数字にします。カスタム・スキーマ・ファイル名で標準のスキーマ・ファイルよりも小さい数字を使用した場合、サーバーでスキーマのロード時にエラーが発生することがあります。カスタム・スキーマ・ファイルでスキーマを拡張した場合は、サーバーを再起動しないと、スキーマの変更は考慮されません。
-
既存のスキーマ・ファイルを変更します。
instance-dir/OUD/config/schema/99-user.ldifなどの既存のカスタム・スキーマ・ファイルにカスタムのスキーマ拡張を追加できます。既存のスキーマ・ファイルを変更してスキーマを拡張した場合は、サーバーを再起動しないと、スキーマの変更は考慮されません。
新しいスキーマ要素を追加するときには、すべての属性を定義する必要があります。未定義の属性はオブジェクト・クラスで使用できません。他のオブジェクト・クラスから継承されるオブジェクト・クラスをいくつか作成する場合は、先に親のオブジェクト・クラスを作成する必要があります。
作成するカスタムの各属性またはオブジェクト・クラスは、1つのスキーマ・ファイルのみで定義する必要があります。
新しいスキーマ定義を手動で定義するときのベスト・プラクティスは、99-user.ldifファイルまたは任意のスキーマ・ファイルにこの定義を追加することです。
33.4.2 属性タイプの管理
スキーマに新しい属性タイプを追加するには、ldapmodifyコマンドを使用します。属性タイプの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。
この項の内容は次のとおりです。
33.4.2.1 属性タイプの識別子のリスト
標準的なアプリケーションでは、オプションで、属性タイプに関する次の識別子を含めることができます。属性タイプ要素の完全セットの詳細は、「属性タイプの理解」を参照してください。
-
OID -
必須。ディレクトリ・サーバー内でその属性タイプを一意に識別するOIDを指定します。LDAP v3仕様では、OIDにはUTF-8エンコードのドット区切り10進数を使用することが要件となっています。しかし、Oracle Unified Directoryでは、スキーマが組織の内部で使用される場合、識別を容易化するため非数値OIDの使用をサポートしています。書式は
attributename-oidです(たとえば、telephoneNumber-oid)。非数値OIDを使用する場合は、非数値OIDごとに、対応するドット区切り10進数のOIDがスキーマで定義されていることが必要です。 -
NAME -
オプション。その属性タイプについて言及するときに使用する、判読可能な名前セットを指定します。名前が1つのときは、一重引用符で囲みます(たとえば、
'blogURL')。名前が複数あるときは、一重引用符で囲んだ各名前をスペースで区切り、名前セット全体をカッコで囲みます(たとえば、('blog' 'blogURL'))。左カッコと名前の間および右カッコの前に1つずつ、必ずスペースを挿入してください。 -
SUP -
オプション。属性タイプに別の属性タイプの要素を継承させる場合に、上位属性タイプを指定します。一致ルールと属性構文の仕様を上位属性タイプから下位タイプに継承できます。ただし、これは、上位属性タイプの定義よりも優先される下位タイプの定義が存在しない場合です。上位属性タイプのOID、上位属性タイプに関連付けられた判読可能ないずれかの名前またはこの両方を、すべての下位属性タイプを一括参照する目的で使用できます。
-
DESC -
オプション。その属性タイプに関する判読可能な説明を指定します。
-
SYNTAX -
オプション。その属性タイプで使用する属性構文を指定します。指定する場合は、数値OIDとして指定します。RFC 4517 (
http://www.ietf.org/rfc/rfc4517.txt)の第3.3項および同じドキュメントの付録Aで、コア構文が定義されています。 -
SINGLE-VALUE -
オプション。そのタイプの属性を含むエントリでそのタイプの属性に対して単一値のみを指定可能とするかどうかを指定します。
SINGLE-VALUEが指定されていない場合、同じエントリ内で複数の固有の値をその属性に対して指定できます。 -
NO-USER-MODIFICATION -
オプション。そのタイプの属性の値を外部クライアントが変更不能かどうか(つまり、ディレクトリ・サーバー内部の処理によってのみ値の変更が可能かどうか)を示します。
-
USAGE -
オプション。その属性の用途を示します。使用可能な値は次のとおりです。
userApplications:ユーザー・データの格納に使用。directoryOperation:ディレクトリ・サーバー内部の処理に必要なデータの格納に使用。distributeOperation:トポロジ内のディレクトリ・サーバー間で同期する必要がある操作データの格納に使用。dSAOperation:トポロジ全体での同期を行わない、特定のディレクトリ・サーバー固有の操作データの格納に使用。 -
extensions -
オプション。属性タイプで使用可能な拡張を指定します。Oracle Unified Directoryには、次の拡張が用意されています。
-
X-ORIGIN。その属性タイプが定義されている場所に関する情報を提供します。この要素は非標準のツールであり、RFC番号(RFC4517)などのスキーマ要素を見つけるときに使用できます。 -
X-SCHEMA-FILE。その属性タイプ定義を格納するスキーマ・ファイルを示します。内部目的でのみ使用され、クライアントには公開されません。この拡張を使用して、ディレクトリ・サーバーがカスタム・スキーマ定義をどこに格納するかを指定できます。 -
X-APPROX。その属性タイプでどの近似一致ルールを使用するかを示します。指定する場合は、登録されている一致ルールのOIDの名前を値として指定します。
-
たとえば、新しい属性タイプblogURLの追加をLDIFファイルで指定し、このファイルをスキーマに追加できます。
$ cat blogURL.ldif
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590
NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Oracle Unified Directory Server'
USAGE userApplications )
ノート:
属性タイプの宣言では、スペースに特に注意してください。LDAPの仕様で、左カッコとOIDの間およびUSAGE要素値と右カッコの間にスペースが存在することが要件となっています。また、LDIFの仕様で、LDIFパーサーは各行の先頭で厳密にスペース1つのみを無視すると規定されています。そのため、要素キーワードで始まる行の先頭にスペースを2つ追加することをお薦めします。たとえば、前の例のNAME、DESC、SYNTAX、SINGLE-VALUE、X-ORIGINおよびUSAGEの前にスペースを2つ追加します。
この例で使用しているOIDは説明用であり、実際のディレクトリには実装しないでください。
33.4.2.2 属性タイプの表示
cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。スキーマ定義を表示するには、ldapsearchコマンドを使用します。スキーマ要素はLDAPサブエントリとして表現されるため、cn=schemaでの検索にはLDAPサブエントリ検索制御を含める必要があります。
33.4.2.3 属性タイプの作成
cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。カスタムのスキーマ定義を追加するには、ldapmodifyコマンドを使用します。次の例では、blogという名前の属性を追加します。
33.4.3 オブジェクト・クラスの管理
オブジェクト・クラスは、エントリに格納するデータ型を制御するために使用される属性定義の名前付きセットです。新しいオブジェクト・クラスをスキーマに追加するには、ldapmodifyコマンドを使用します。オブジェクト・クラスの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。
この項の内容は次のとおりです。
33.4.3.1 オブジェクト・クラスのオプションの識別子のリスト
標準的なアプリケーションでは、オブジェクト・クラス・タイプに関する次のオプションの識別子も含めることができます。オブジェクト・クラス定義の詳細は、「Oracle Unified Directoryにおけるスキーマの理解」を参照してください。
-
OID -
必須。ディレクトリ・サーバー内でそのオブジェクト・クラスを一意に識別するOIDを指定します。LDAP v3仕様では、OIDにはUTF-8エンコードのドット区切り10進数を使用することが要件となっています。しかし、Oracle Unified Directoryでは、組織の内部で使用されるスキーマの識別を容易化するため、非数値OIDの使用をサポートしています。たとえば、objectClassName
-oidのような書式になります(person-oidなど)。 -
NAME -
オプション。そのオブジェクト・クラスについて言及するときに使用する、判読可能な名前セットを指定します。名前が1つのときは、一重引用符で囲みます(たとえば、
'blogURL')。名前が複数あるときは、一重引用符で囲んだ各名前をスペースで区切り、名前セット全体をカッコで囲みます(たとえば、('blog' 'blogURL'))。左カッコと名前の間および右カッコの前に1つずつ、必ずスペースを挿入してください。 -
DESC -
オプション。そのオブジェクト・クラスに関する判読可能な説明を指定します。指定する場合は、説明を一重引用符で囲みます。
-
SUP -
オプション。そのオブジェクト・クラスに別のオブジェクト・クラスの要素を継承させる場合に、上位オブジェクト・クラスを指定します。ディレクトリ・サーバーで使用できる上位オブジェクト・クラスは1つのみです。ただし、LDAP v3の仕様では複数の上位オブジェクト・クラスが許容されています。
-
OBSOLETE -
オプション。そのオブジェクト・クラスがアクティブかどうかを示します。
OBSOLETEとしてマークされているオブジェクト・クラスは、ディレクトリ・サーバーで作成される新しい要素からは参照されません。 -
SUP oids -
オプション。
SUPキーワードに続けて上位クラスのOIDを指定します。 -
KIND -
オプション。定義対象のオブジェクト・クラスのタイプを示します。使用可能な値は
ABSTRACT、AUXILIARYおよびSTRUCTURALです。 -
MUST oids -
オプション。そのオブジェクト・クラスを含むエントリに存在する(つまり、1つ以上の値を持つ)必要がある属性タイプ・セットを指定します。必須属性が1つのみの場合は、
MUSTキーワードに続けてその属性タイプの名前またはOIDを指定します。必須属性タイプが複数ある場合は、属性タイプ間をドル記号($)で区切り、属性タイプ・セット全体をカッコで囲みます。たとえば、MUST (sn $cn)。 -
MAY oids -
オプション。そのオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプ・セットを指定します。指定する属性が1つのみの場合は、
MAYキーワードに続けてその属性タイプの名前またはOIDを指定します。属性タイプを複数指定する場合は、各属性タイプ間をドル記号($)で区切り、属性タイプ・セット全体をカッコで囲みます。たとえば、MAY (userPassword $telephoneNumber $seeAlso $description)。 -
extensions -
オプション。そのオブジェクト・クラスで使用できる拡張を指定します。ディレクトリ・サーバーは次の拡張を備えています。
X-ORIGIN:そのオブジェクト・クラスが定義されている場所に関する情報を提供します。この要素は、ユーザーがスキーマ要素を見つけやすいようにする非標準のツールです。X-SCHEMA-FILE。そのオブジェクト・クラス定義を格納するスキーマ・ファイルを示します。内部目的でのみ使用され、クライアントには公開されません。この拡張を使用して、ディレクトリ・サーバーがカスタム・スキーマ定義をどこに格納するかを指定できます。
たとえば、新しいオブジェクト・クラスbloggerの追加をLDIFファイルで指定し、このファイルをスキーマに追加できます。
$ cat blogger.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.32473.1.1.10
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'Oracle Unified Directory Server' )
オブジェクト・クラスの宣言では、スペースに特に注意してください。LDAPの仕様で、左カッコとOIDの間およびX-ORIGIN要素値と右カッコの間にスペースが存在することが要件となっています。また、LDIFの仕様で、LDIFパーサーは各行の先頭で厳密にスペース1つのみを無視すると規定されています。そのため、前の例のNAME、DESC、SUP、STRUCTURAL、MAY、X-ORIGINなどの要素キーワードで始まる行の前にスペースを2つ追加することをお薦めします。
この例で使用しているOIDは説明用であり、実際のディレクトリには実装しないでください。
33.4.3.2 オブジェクト・クラスの表示
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。スキーマ定義を表示するには、ldapsearchコマンドを使用します。
33.4.3.3 オブジェクト・クラスの作成
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。カスタム・スキーマを追加するには、ldapmodifyコマンドを使用します。次の例では、前の例で作成した属性タイプに基づいて、オブジェクト・クラスbloggerを追加します。
33.5 スキーマのレプリケートについて
レプリケート・トポロジでは、スキーマ定義が自動的にレプリケートされ、1つのスキーマがすべてのサーバーで確実に使用されます。どのサーバーで行われたスキーマの変更も、トポロジ内の他のすべてのサーバーにレプリケートされます。
レプリケーションを構成すると、デフォルトで、最初のサーバーのスキーマを使用して2番目のサーバーのスキーマが初期化されます。しかし、2番目のサーバーのスキーマを使用して最初のサーバーのスキーマを初期化するように指定できます。また、そのスキーマ・レプリケーションを完全に無効化するように指定することも可能です。詳細は、「スキーマ・レプリケーションの構成」を参照してください。
33.6 OUDSMを使用したスキーマの管理
ディレクトリ・スキーマのほとんどの要素は、OUDSMを使用して管理できます。次の各項では、スキーマの表示および拡張の一般的な面を管理するステップを示します。
この項の内容は次のとおりです。
33.6.1 新規属性タイプの追加
Oracle Unified Directory Services Manager (OUDSM)を使用して、スキーマに新しい属性タイプを追加します。
OUDSMを使用して新しい属性タイプをスキーマに追加するには:
33.6.2 既存の属性に基づく属性の追加
Oracle Unified Directory Services Managerを使用して、既存の属性タイプに基づく属性タイプを追加します。
既存の属性タイプに基づく属性タイプを追加するには:
33.6.4 属性の削除
Oracle Unified Directory Services Managerを使用して、既存の属性タイプを削除します。
既存の属性タイプを削除するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
- 削除する属性タイプを選択します。
- 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
- 「適用」をクリックして、変更を保存します。
- 「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、その属性がスキーマから削除されたことを確認します。
ノート:
サーバー内の1つ以上のエントリによってすでに参照されている属性タイプを削除しようとすると、サーバーからエラーが返されます。
33.6.5 すべてのディレクトリ属性の表示
Oracle Unified Directory Services Managerを使用して、すべての既存の属性タイプを表示します。
すべての既存の属性タイプを表示するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
- スキーマで定義されているすべての属性が左側のペインにリストされます。
- 属性を選択すると、右側のペインにそのプロパティが表示されます。
33.6.7 属性の索引付け詳細の表示
索引は、サーバーごとに構成され、索引構成はレプリケートされません。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。索引なし検索は、ユーザーが索引なし検索特権を持っていない場合はデフォルトで拒否されます。
ローカル・データベース索引は次のいずれかのタイプです:
-
近似 - 近似検索フィルタを使用して検索の効率を高めます。
-
等価 - 等価検索フィルタを使用して検索の効率を高めます。
-
順序付け - 以上または以下検索フィルタを使用して検索の効率を高めます。
-
プレゼンス - プレゼンス検索フィルタを使用して検索の効率を高めます。
-
部分文字列 - 部分文字列検索フィルタを使用して検索の効率を高めます。
OUDSMを使用して、属性に対して定義されている索引を表示するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
- 属性を選択すると、右側のペインにそのプロパティが表示されます。
- 「索引付き」プロパティまで下にスクロールして、その属性の索引付け詳細を表示します。
33.6.8 新規オブジェクト・クラスの追加
Oracle Unified Directory Services Manager (OUDSM)を使用して、スキーマに新しい属性タイプを追加します。
OUDSMを使用して新しい属性タイプをスキーマに追加するには:
33.6.9 既存のオブジェクト・クラスに基づくオブジェクト・クラスの追加
Oracle Unified Directory Services Managerを使用して、既存のオブジェクト・クラスに基づくオブジェクト・クラスを追加します。
既存のオブジェクト・クラスに基づいたオブジェクト・クラスを追加するには:
33.6.10 オブジェクト・クラスのプロパティの表示
Oracle Unified Directory Services Managerを使用して、既存のオブジェクト・クラスのプロパティを表示します。
既存のオブジェクト・クラスのプロパティを表示するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- 「オブジェクト・クラス」パネルを開きます。
- スキーマで定義されているすべてのオブジェクト・クラスが左側のペインにリストされます。
- オブジェクト・クラスを選択すると、右側のペインにそのプロパティが表示されます。
33.6.11 オブジェクト・クラスの変更
Oracle Unified Directory Services Managerを使用して、既存のオブジェクト・クラスを変更します。
既存のオブジェクト・クラスを変更するには:
33.6.12 オブジェクト・クラスの削除
Oracle Unified Directory Services Managerを使用して、既存のオブジェクト・クラスを削除します。
既存のオブジェクト・クラスを削除するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- 「オブジェクト・クラス」パネルを開きます。
- 削除するオブジェクト・クラスを選択します。
- 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
- 「適用」をクリックして、変更を保存します。
- 「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、そのオブジェクト・クラスがスキーマから削除されたことを確認します。
ノート:
サーバー内の1つ以上のエントリによってすでに参照されているオブジェクト・クラスを削除しようとすると、サーバーからエラーが返されます。
33.6.13 オブジェクト・クラスの検索
Oracle Unified Directory Services Managerを使用して、特定のオブジェクト・クラスを検索します。
特定のオブジェクト・クラスを検索するには:
33.6.14 LDAP構文のリストの表示
LDAP構文は基本的にデータ型の定義です。属性タイプの構文は、対応する値が保持するデータ型を示します。構文の使用により、所定の属性に対して特定の値が許容されるかどうかと、ディレクトリ・サーバーが既存の値に対してどのように相互作用するかを決定できます。
Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要に応じて、構文チェックを完全に無効化できます。また、関連付けられた構文に違反する値が検出されたときに、その値を受け入れる一方、ディレクトリ・サーバーのエラー・ログに警告メッセージを記録することも可能です。スキーマ・チェックの無効化の詳細は、「スキーマ・チェックの構成」を参照してください。
LDAP構文は変更できませんが、既存のすべてのLDAP構文を表示できます。
OUDSMを使用して既存のLDAP構文をすべて表示するには:
33.6.16 LDAP一致ルールのリストの表示
一致ルールは、同じ属性の2つの値を比較する、つまりそれらの値に対して一致操作を実行するために、ディレクトリ・サーバーで使用されます。
次のような様々なタイプの一致ルールをサポートしています:
-
等価一致ルール。この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。
-
順序付け一致ルール。この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。
-
部分文字列一致ルール。この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。
-
近似一致ルール。この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。
一致ルールは変更できませんが、既存のすべての一致ルールを表示できます。
OUDSMを使用して既存の一致ルールをすべて表示するには:
33.6.18 コンテンツ・ルールのリストの表示
コンテンツ・ルールは、エントリが含むことができるコンテンツを定義するメカニズムを提供します。個々のエントリには、最大1つのコンテンツ・ルールをその構造化オブジェクト・クラスに基づいて関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。
OUDSMを使用して、サーバーに構成されているすべてのコンテンツ・ルールを表示するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- 「コンテンツ・ルール」パネルを開きます。
- 構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。
- コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。
33.6.19 コンテンツ・ルールの検索
Oracle Unified Directory Services Managerを使用して、特定のコンテンツ・ルールを検索します。
特定のコンテンツ・ルールを検索するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- 「コンテンツ・ルール」パネルを開きます。
- 構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。
- コンテンツ・ルール名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
- コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。
33.6.20 新規コンテンツ・ルールの作成
Oracle Unified Directory Services Managerを使用して、スキーマに新しいコンテンツ・ルールを追加します。
新しいコンテンツ・ルールをスキーマに追加するには:
33.6.21 既存のコンテンツ・ルールに基づくコンテンツ・ルールの作成
Oracle Unified Directory Services Managerを使用して、既存のコンテンツ・ルールに基づくコンテンツ・ルールを追加します。
既存のコンテンツ・ルールに基づいたコンテンツ・ルールを追加するには:
33.6.22 コンテンツ・ルールの変更
Oracle Unified Directory Services Managerを使用して、既存のコンテンツ・ルールを変更します。
既存のコンテンツ・ルールを変更するには:
33.6.23 コンテンツ・ルールの削除
Oracle Unified Directory Services Managerを使用して、既存のコンテンツ・ルールを削除します。
既存のコンテンツ・ルールを削除するには:
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「スキーマ」タブを選択します。
- 「コンテンツ・ルール」パネルを開きます。
- 削除するコンテンツ・ルールを選択します。
- 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
- 「適用」をクリックして、変更を保存します。
- 「リフレッシュ」アイコンをクリックして左側のペインのコンテンツ・ルール・リストをリフレッシュし、そのコンテンツ・ルールがスキーマから削除されたことを確認します。