この章では、ディレクトリ・サーバーに付属しているスキーマの表示手順と拡張手順について説明します。
スキーマでは、ディレクトリへの格納が可能な情報オブジェクトのタイプが定義および制御されます。スキーマによって、ディレクトリ情報ツリー内のエントリのタイプが定義され、要素の一意性が維持されます。また、新しい要素がディレクトリに追加されるときに発生することがある未チェックのスキーマの増大が防止されます。
この章の構成は、次のとおりです。
個々のスキーマ要素の詳細は、第10章「Oracle Unified Directoryスキーマ・モデルの理解」を参照してください。
ディレクトリ・サーバー・インスタンスは、起動時に一度スキーマを読み取ります。その後、スキーマ情報を使用して、検索フィルタ・リクエストまたはアサーションをエントリの属性と照合し、追加または変更操作がクライアントによって許可されているかどうかを判定します。
通常、ほとんどのアプリケーションにはデフォルトのスキーマで間に合います。しかし、ディレクトリ・サーバーの柔軟性を活用して、アプリケーションに合せてスキーマを拡張することもできます。一般的な手順では、新しいカスタムのスキーマの採用時に標準のスキーマを放棄するのではなく、標準の属性またはオブジェクト・クラスを可能なかぎり使用します。標準のスキーマで処理されないカスタム属性またはオブジェクト・クラスが必要な場合は、アプリケーションで必要な補助属性およびオブジェクト・クラスを使用して標準のスキーマを拡張することによって、スキーマを作成できます。
スキーマはディレクトリ内の接尾辞(cn=schema
)の下に格納されます。またディレクトリ・サーバーには、スキーマ要素を定義するサブスキーマ・サブエントリと、ディレクトリでの操作属性セットも格納されます。
スキーマは次の2つの方法のいずれかで拡張できます:
LDAPを介してスキーマを拡張します。
カスタムのスキーマ定義ファイルを作成します。
デフォルト・スキーマの拡張または独自のスキーマの設計について検討する場合は、事前にスキーマの構文と設計を確実に理解する必要があります。
スキーマの設計または拡張の基本ステップは次のとおりです:
データをデフォルト・スキーマにマップします。ディレクトリ・サーバーに定義されている既存のスキーマ要素をできるかぎり使用します。標準のスキーマ要素は、ディレクトリ対応アプリケーションとの互換性を確保するうえで役立ちます。スキーマはLDAP標準に基づいているため、多数のディレクトリ・ユーザーからレビューされ、これらのユーザーの合意を得ています。
一致しないデータを特定します。デフォルト・スキーマは様々な情報オブジェクトに対応するように設計されています。しかし、特定のデータ型がこのスキーマで処理されない場合は、そのデータをメモするとともに、ディレクトリに必要な他のデータ型をメモします。
デフォルト・スキーマを拡張して、新しい要素を定義します。最適なパフォーマンスを達成するには、できるかぎり既存のスキーマ要素を再利用します。また、各オブジェクト・クラスに対して定義する必須属性を最小限に抑えます。スキーマはできるかぎり簡潔にします。同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。
スキーマ・チェックを使用します。スキーマ・チェックによって、属性とオブジェクト・クラスをスキーマ・ルールに準拠させることができます。
一貫性のあるデータ書式を選択し、適用します。LDAPスキーマでは、属性値に任意のデータを設定できます。しかし、LDAPクライアント・アプリケーションおよびディレクトリ・ユーザーに適した書式を選択して、一貫性のある方法でデータを格納するようにしてください。
ディレクトリ・サーバー付属のデフォルト・スキーマは、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ページング関数に必要なスキーマ定義を格納します。 |
|
プロキシ・サーバー・インスタンスの配信機能に必要なスキーマ定義を格納します。 |
|
プロキシ・サーバー・インスタンスのグローバル索引付け機能に必要なスキーマ定義を格納します。 |
|
プロキシ・サーバー・インスタンスのロード・バランシング機能に必要なスキーマ定義を格納します。 |
|
プロキシ・サーバー・インスタンス固有のスキーマ定義を格納します。 |
|
レプリケーション・ゲートウェイ・サーバー・インスタンス固有のスキーマ定義を格納します。 |
|
プロキシ・サーバー・インスタンスの仮想化機能に必要なスキーマ定義を格納します。 |
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
に設定されている場合、単一構造化オブジェクト・クラス・チェックは適用されません。
注意: これらのプロパティの値をデフォルトから変更すると、スキーマの整合性が危険にさらされるため、通常は、これらの値を変更しないでください。 |
オブジェクト識別子(OID)は、ディレクトリ内のオブジェクトを一意に識別するために使用される数値文字列です。OIDは、ディレクトリ・スキーマ、制御および拡張操作で要素の一意の識別を必要とする場合に使用されます。
LDAPオブジェクト・クラスおよび属性にはベース・オブジェクト識別子(OID)が必要です。ディレクトリでの名前の競合を避けるために、このOIDは、組織内で一意にする必要があります。ディレクトリを組織の内部で使用することを計画している場合は、ディレクトリ・サーバーで提供されるOIDを使用してください。スキーマをエクスポートすることや、なんらかの方法でスキーマを公開することを計画している場合は、自組織用の一意のOIDのリクエストを入力することを検討してください。詳細は、第33.3.1項「ベース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仕様違反ですが、使いやすさを考慮して許容されています。
ディレクトリ・サーバーを公開することを計画している場合や、スキーマ定義をカスタム・アプリケーション用に再配布することを計画している場合は、自組織用のベース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に置き換えます。それによって、スキーマ・レプリケーションでのスキーマ内の相違の認識と情報の同期試行に関連する問題が回避されます。
カスタムのスキーマ拡張を手動で編集します。理想的には、カスタム拡張はいずれも別のファイルで定義します。
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つのスキーマ・ファイルのみで定義する必要があります。
新しいスキーマ定義を手動で定義するときのベスト・プラクティスは、99user.ldif
ファイルまたは任意のスキーマ・ファイルにこの定義を追加することです。
スキーマに新しい属性タイプを追加するには、ldapmodify
コマンドを使用します。属性タイプの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。標準的なアプリケーションでは、オプションで、属性タイプに関する次の識別子を含めることができます。属性タイプ要素の完全セットの詳細は、第10.3項「属性タイプの理解」を参照してください。
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は説明用であり、実際のディレクトリには実装しないでください。 |
cn=schema
エントリは複数値属性attributeTypes
を持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。スキーマ定義を表示するには、ldapsearch
コマンドを使用します。スキーマ要素はLDAPサブエントリとして表現されるため、cn=schema
での検索にはLDAPサブエントリ検索制御を含める必要があります。
LDAPサブエントリ検索制御とともにldapsearch
コマンドを使用する方法は次のとおりです:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=schema" -s base "(objectclass=*)" attributeTypes dn: cn=schema attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreeSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} X-ORIGIN 'RFC 4519' ) attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 4519' ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 4512' ) ...(more output)...
特定の属性タイプを表示するには、--dontWrap
オプションを使用し、その後grep
コマンド(UNIXシステム上)を使用して必要な属性を検索します。
次の例では、telexNumber
という文字列を含む属性タイプを検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base --dontWrap "(objectclass=*)" \ attributeTypes | grep "telexNumber" attributeTypes: ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 X-ORIGIN 'RFC 4519' ) attributeTypes: ( 2.5.4.21.1 NAME 'c-TelexNumber' SUP telexNumber COLLECTIVE X-ORIGIN 'RFC 3671' )
cn=schema
エントリは複数値属性attributeTypes
を持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。カスタムのスキーマ定義を追加するには、ldapmodify
コマンドを使用します。次の例では、blog
という名前の属性を追加します。
テキスト・エディタを使用して、スキーマ拡張を含む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 )
ldapmodify
を使用してファイルを追加します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -a -f blogURL.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
ldapsearch
を使用して追加内容を表示することによって、これを検証します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=schema" -s base --dontWrap "(objectclass=*)" \ attributeTypes | grep 'blog' 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 )
注意: 新しい属性定義は、Oracle Unified Directoryによって、instance-dir/OUD/config/schema/ 99-user.ldif ファイルに自動的に追加されます。 |
cn=schema
エントリは複数値属性attributeTypes
を持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。カスタムのスキーマ定義は、ldapmodify
コマンドを使用して削除できます。Oracle Unified Directoryでの標準のスキーマ定義の削除は行えません。
注意: 属性タイプを削除する際には注意してください。この削除によってディレクトリが損なわれることがあります。属性タイプの削除は、どうしても削除する必要がある場合以外は行わないでください。 |
LDIFファイルに削除リクエストを作成します。
dn: cn=schema changetype: modify delete: 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 )
ldapmodify
コマンドを使用して、削除リクエストを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --fileName "remove_blogURL.ldif" Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
オブジェクト・クラスは、エントリに格納するデータ型を制御するために使用される属性定義の名前付きセットです。新しいオブジェクト・クラスをスキーマに追加するには、ldapmodify
コマンドを使用します。オブジェクト・クラスの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。標準的なアプリケーションでは、オブジェクト・クラス・タイプに関する次のオプションの識別子も含めることができます。オブジェクト・クラス定義の詳細は、第33.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は説明用であり、実際のディレクトリには実装しないでください。
cn=schema
エントリは複数値属性objectClasses
を持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。スキーマ定義を表示するには、ldapsearch
コマンドを使用します。
オブジェクト・クラス定義を表示するには、ldapsearch
コマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base "(objectclass=*)" objectClasses dn: cn=schema objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512' ) objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName X-ORIGIN 'RFC 4512' ) objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registered Address $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) ...(more output)...
特定のオブジェクト・クラスを検索する場合は、--dontWrap
オプションとgrep
コマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base --dontWrap "(objectclass=*)" \ objectClasses | grep "inetOrgPerson" objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500UniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) X-ORIGIN 'RFC 2798' )
cn=schema
エントリは複数値属性objectClasses
を持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。カスタム・スキーマを追加するには、ldapmodify
コマンドを使用します。次の例では、前の例で作成した属性タイプに基づいて、オブジェクト・クラス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' )
ldapmodify
コマンドを使用してファイルを追加します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -a -f blogger.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
ldapsearch
を使用して追加内容を表示することによって、これを検証します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base --dontWrap "(objectclass=*)" \ objectClasses | grep 'blogger'
注意: 新しいオブジェクト・クラス定義は、Oracle Unified Directoryによって、instance-dir/OUD/config/schema/ 99-user.ldif ファイルに自動的に追加されます。 |
cn=schema
エントリは複数値属性objectClasses
を持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。カスタムのオブジェクト・クラス定義を削除するには、ldapmodify
コマンドを使用します。
注意: オブジェクト・クラスを削除する際には注意してください。この削除によってディレクトリが損なわれることがあります。オブジェクト・クラスの削除は、どうしても削除する必要がある場合以外は行わないでください。 |
LDIF形式の削除リクエストを作成します。
dn: cn=schema changetype: modify delete: 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' )
ldapmodify
を使用してLDIFファイルを適用することによって、オブジェクト・クラスを削除します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --fileName "remove_objectclass_schema.ldif"
レプリケート・トポロジでは、スキーマ定義が自動的にレプリケートされ、1つのスキーマがすべてのサーバーで確実に使用されます。どのサーバーで行われたスキーマの変更も、トポロジ内の他のすべてのサーバーにレプリケートされます。
レプリケーションを構成すると、デフォルトで、最初のサーバーのスキーマを使用して2番目のサーバーのスキーマが初期化されます。しかし、2番目のサーバーのスキーマを使用して最初のサーバーのスキーマを初期化するように指定できます。また、そのスキーマ・レプリケーションを完全に無効化するように指定することも可能です。詳細は、第32.9項「スキーマのレプリケーションの構成」を参照してください。
ディレクトリ・スキーマのほとんどの要素は、ODSMを使用して管理できます。次の各項では、スキーマの表示および拡張の一般的な面を管理するステップを示します。
ODSMを使用して新しい属性タイプをスキーマに追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
「追加」アイコンをクリックします。
「新規属性の作成」ウィンドウで次の情報を設定します:
名前: 新しい属性タイプの一意の名前を入力します。
オブジェクトID: ディレクトリ・サーバー内でその属性タイプを一意に識別するOIDを指定します。Oracle Unified Directoryでは、スキーマが組織の内部で使用される場合、識別を容易化するため非数値OIDの使用をサポートしています。ただし、このリリースでODSMがサポートしているOIDは数値OIDのみです。
説明: その属性タイプに関する判読可能な説明を入力します。
構文: その属性タイプで使用する属性構文を入力します。構文を指定する場合は、数値OIDとして指定します。RFC 4517の第3.3項および同じドキュメントの付録Aで、コア構文が定義されています。
サイズ: その属性の値の最大サイズをバイト単位で入力します。複数値属性の場合は、この設定は各値の結合ではなく、単一値の最大サイズのことです。
使用方法: その属性の用途を指定します。次の値があります:
userApplications: その属性を、ユーザー・データの格納に使用します。
directoryOperation: その属性を、ディレクトリ・サーバー内部の処理に必要なデータの格納に使用します。
distributedOperation: その属性を、トポロジ内のディレクトリ・サーバー間で同期する必要がある操作データの格納に使用します。
dSAOperation: その属性を、トポロジ全体での同期を行わない、特定のディレクトリ・サーバー固有の操作データの格納に使用します。
順序付け: この属性タイプの順序付け一致ルールを選択します。詳細は、第10.1項「一致ルールの理解」を参照してください。
等価: この属性タイプの等価一致ルールを選択します。詳細は、第10.1項「一致ルールの理解」を参照してください。
部分文字列: この属性タイプの部分文字列一致ルールを選択します。詳細は、第10.1項「一致ルールの理解」を参照してください。
廃止: この属性タイプは使用廃止となっているが、互換性用に維持する場合は、このボックスを選択します。
単一値: このタイプの属性を含むエントリでそのタイプの属性に対して単一値のみを指定可能とするどうかを示します。このチェック・ボックスの選択を解除すると、同じエントリ内で複数の固有の値を属性に対して指定できるようになります。
集合: この属性が集合属性かどうかを示します。詳細は、第18.13項「集合属性の使用方法」を参照してください。
スーパー: この新しい属性が既存の属性の拡張である場合は、既存のスーパー・タイプの名前を入力または選択します。
オリジン: この新しい属性タイプのソース(RFC 4512など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。
スキーマ・ファイル拡張: この属性タイプの定義がファイルに格納されている場合は、そのファイルのパスを入力します。
「作成」をクリックすると、新しい属性が作成されます。
ODSMを使用して既存の属性タイプに基づく属性タイプを追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
新しい属性タイプのベースとする属性を選択します。
「類似作成」アイコンをクリックします。
一部のフィールドは、選択した属性に基づいてデフォルトで設定されます。
新しい属性タイプの残りのフィールドを設定します。
各フィールドとその値の詳細は、第33.6.1項「新規属性タイプの追加」を参照してください。
「作成」をクリックすると、新しい属性が作成されます。
ODSMを使用して既存の属性タイプを変更する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
変更する属性タイプを選択します。
右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第33.6.1項「新規属性タイプの追加」を参照してください。
「適用」をクリックして、変更を保存します。
ODSMを使用して既存の属性タイプを削除する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
削除する属性タイプを選択します。
「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
「適用」をクリックして、変更を保存します。
「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、その属性がスキーマから削除されたことを確認します。
注意: サーバー内の1つ以上のエントリによってすでに参照されている属性タイプを削除しようとすると、サーバーからエラーが返されます。 |
ODSMを使用して既存のすべての属性タイプを表示する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
スキーマで定義されているすべての属性が左側のペインにリストされます。
属性を選択すると、右側のペインにそのプロパティが表示されます。
ODSMを使用して特定の属性タイプを検索する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
スキーマで定義されているすべての属性が左側のペインにリストされます。
属性名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、uid
という文字列で終わるすべての属性を検索するには、*uid
と入力します。
属性を選択すると、右側のペインにそのプロパティが表示されます。
索引は、サーバーごとに構成され、索引構成はレプリケートされません。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。索引なし検索は、ユーザーが索引なし検索特権を持っていない場合はデフォルトで拒否されます。
ローカル・データベース索引は次のいずれかのタイプです:
近似: 近似検索フィルタを使用して検索の効率を高めます。
等価: 等価検索フィルタを使用して検索の効率を高めます。
順序付け: 以上または以下検索フィルタを使用して検索の効率を高めます。
プレゼンス: プレゼンス検索フィルタを使用して検索の効率を高めます。
部分文字列: 部分文字列検索フィルタを使用して検索の効率を高めます。
ODSMを使用して、属性に対して定義されている索引を表示する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。
属性を選択すると、右側のペインにそのプロパティが表示されます。
「索引付き」プロパティまで下にスクロールして、その属性の索引付け詳細を表示します。
ODSMを使用して新しい属性タイプをスキーマに追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルをクリックして開きます。
既存のすべてのオブジェクト・クラスが左側のペインに表示されます。
「追加」アイコンをクリックします。
「新規オブジェクト・クラスの作成」ウィンドウで次の情報を設定します:
名前: 新しいオブジェクト・クラスの一意の名前を入力します。
オブジェクトID: ディレクトリ・サーバー内でそのオブジェクト・クラスを一意に識別するOIDを指定します。Oracle Unified Directoryでは、スキーマが組織の内部で使用される場合、識別を容易化するため非数値OIDの使用をサポートしています。ただし、このリリースでODSMがサポートしているOIDは数値OIDのみです。
説明: そのオブジェクト・クラスに関する判読可能な説明を入力します。
タイプ: そのオブジェクト・クラスのタイプを指定します。次の値があります:
構造型: 構造化オブジェクト・クラスでは、そのオブジェクト・クラスを含むあらゆるエントリのコア・タイプが定義されます。個々のエントリは厳密に1つの構造化クラスを持っている必要があります(ただし、構造化クラスは他の構造化クラスまたは抽象クラスから継承可能です)。
補助型: 補助オブジェクト・クラスでは、エントリのコア・タイプは定義されず、そのエントリの追加属性が定義されます。個々のエントリは1つ以上の補助オブジェクト・クラスを含むことができます。個々のエントリで使用可能な補助オブジェクト・クラス・セットは、そのエントリの構造化オブジェクト・クラスに関連付けられたDITコンテンツ・ルールによって制御できます。
抽象型: 抽象オブジェクト・クラスは、エントリで直接使用できず、構造化オブジェクト・クラスまたは補助オブジェクト・クラスのどちらかでサブクラス化する必要があります。そのサブクラスは、抽象クラスで定義される必須またはオプション、あるいはその両方の属性タイプを継承します。
スーパークラス: 「追加」アイコンをクリックして、1つ以上の上位オブジェクト・クラスを指定します。新しいオブジェクト・クラスはその上位オブジェクト・クラスから要素を継承します。
必須属性: 「追加」アイコンをクリックして、そのオブジェクト・クラスを含むエントリに存在する(つまり、1つ以上の値を持つ)必要がある属性タイプ・セットを指定します。
オプション属性: 「追加」アイコンをクリックして、そのオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプ・セットを指定します。
継承属性: オブジェクト・クラスの作成後、このオブジェクト・クラスの上位オブジェクト・クラスから継承された属性がこのフィールドに表示されます。
オリジン: この新しいオブジェクト・クラスのソース(RFC 4512など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。
スキーマ・ファイル拡張: この新しいオブジェクト・クラスの定義がファイルに格納されている場合は、そのファイルのパスを入力します。
「作成」をクリックすると、新しいオブジェクト・クラスが作成されます。
ODSMを使用して既存のオブジェクト・クラスに基づくオブジェクト・クラスを追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルを開きます。
新しいオブジェクト・クラスのベースとするオブジェクト・クラスを選択します。
「類似作成」アイコンをクリックします。
一部のフィールドは、選択したオブジェクト・クラスに基づいてデフォルトで設定されます。既存のオブジェクト・クラスが、この新しいオブジェクト・クラスの上位オブジェクト・クラスとして使用されます。
新しいオブジェクト・クラスの残りのフィールドを設定します。
各フィールドとその値の詳細は、第33.6.8項「新規オブジェクト・クラスの追加」を参照してください。
「作成」をクリックすると、新しいオブジェクト・クラスが作成されます。
ODSMを使用して既存のオブジェクト・クラスのプロパティを表示する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルを開きます。
スキーマで定義されているすべてのオブジェクト・クラスが左側のペインにリストされます。
オブジェクト・クラスを選択すると、右側のペインにそのプロパティが表示されます。
ODSMを使用して既存のオブジェクト・クラスを変更する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルを開きます。
変更するオブジェクト・クラスを選択します。
右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第33.6.8項「新規オブジェクト・クラスの追加」を参照してください。
「適用」をクリックして、変更を保存します。
ODSMを使用して既存のオブジェクト・クラスを削除する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルを開きます。
削除するオブジェクト・クラスを選択します。
「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
「適用」をクリックして、変更を保存します。
「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、そのオブジェクト・クラスがスキーマから削除されたことを確認します。
注意: サーバー内の1つ以上のエントリによってすでに参照されているオブジェクト・クラスを削除しようとすると、サーバーからエラーが返されます。 |
ODSMを使用して特定のオブジェクト・クラスを検索する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「オブジェクト・クラス」パネルを開きます。
スキーマで定義されているすべてのオブジェクト・クラスが左側のペインにリストされます。
オブジェクト・クラス名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、person
という文字列で終わるすべてのオブジェクト・クラスを検索するには、*person
と入力します。
オブジェクト・クラスを選択すると、右側のペインにそのプロパティが表示されます。
LDAP構文は基本的にデータ型の定義です。属性タイプの構文は、対応する値が保持するデータ型を示します。構文の使用により、所定の属性に対して特定の値が許容されるかどうかと、ディレクトリ・サーバーが既存の値に対してどのように相互作用するかを決定できます。
Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要に応じて、構文チェックを完全に無効化できます。また、関連付けられた構文に違反する値が検出されたときに、その値を受け入れる一方、ディレクトリ・サーバーのエラー・ログに警告メッセージを記録することも可能です。スキーマ・チェックの無効化の詳細は、第33.2項「スキーマ・チェックの構成」を参照してください。
LDAP構文は変更できませんが、ODSMを使用して既存のすべてのLDAP構文を表示できます。この手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「構文」パネルを開きます。
サポートされているすべてのLDAP構文が左側のペインにリストされます。
構文を選択すると、そのプロパティが右側のペインに表示されます。
すべての属性や、その構文を現在参照している一致ルールなどの情報が表示されます。
ODSMを使用して特定のLDAP構文を検索する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「構文」パネルを開きます。
サポートされているすべてのLDAP構文が左側のペインにリストされます。
構文名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、time
という文字列で終わるすべての構文を検索するには、*time
と入力します。
構文を選択すると、そのプロパティが右側のペインに表示されます。
一致ルールは、同じ属性の2つの値を比較する、つまりそれらの値に対して一致操作を実行するために、ディレクトリ・サーバーで使用されます。次のような様々なタイプの一致ルールをサポートしています:
等価一致ルール: この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。
順序付け一致ルール: この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。
部分文字列一致ルール: この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。
近似一致ルール: この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。
一致ルールは変更できませんが、ODSMを使用して既存のすべての一致ルールを表示できます。この手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「一致ルール」パネルを開きます。
構成済のすべての一致ルールが左側のペインにリストされます。
一致ルールを選択すると、そのプロパティが右側のペインに表示されます。
すべての属性や、その一致ルールを現在参照している一致ルールなどの情報が表示されます。
ODSMを使用して特定の一致ルールを検索する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「一致ルール」パネルを開きます。
構成済のすべての一致ルールが左側のペインにリストされます。
一致ルール名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、match
という文字列で終わるすべての一致ルールを検索するには、*match
と入力します。
一致ルールを選択すると、そのプロパティが右側のペインに表示されます。
コンテンツ・ルールは、エントリが含むことができるコンテンツを定義するメカニズムを提供します。個々のエントリには、最大1つのコンテンツ・ルールをその構造化オブジェクト・クラスに基づいて関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。
ODSMを使用して、サーバーに構成されているすべてのコンテンツ・ルールを表示する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。
コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。
ODSMを使用して特定のコンテンツ・ルールを検索する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。
コンテンツ・ルール名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。
ODSMを使用して新しいコンテンツ・ルールをスキーマに追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
「追加」アイコンをクリックします。
「新規コンテンツ・ルールの作成」ウィンドウで次の情報を設定します:
名前: 新しいコンテンツ・ルールの一意の名前を入力します。
構造化オブジェクト・クラス: このコンテンツ・ルールに関連付ける構造化オブジェクト・クラスの名前を指定します。
説明: そのコンテンツ・ルールに関する判読可能な説明を入力します。
補助オブジェクト・クラス: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在することが可能な補助オブジェクト・クラスのリストを指定します。値を何も指定しない場合、このようなエントリは補助オブジェクト・クラスを持つことができません。使用可能な補助オブジェクト・クラスは、その名前またはOIDによって指定できます。
必須属性: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在する必要がある属性タイプのリストを指定します。このリストは、エントリに含まれるオブジェクト・クラスで必要とされる属性タイプ以外のものです。これらの追加属性タイプは、このようなオブジェクト・クラスのいずれでも使用可能とされていないものでもかまいません。必須属性は、その名前またはOIDによって指定できます。
オプション属性: 「追加」アイコンをクリックして、関連付けられたオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプのリストを指定します。このリストは、エントリに含まれるオブジェクト・クラスで使用可能な属性タイプ以外のものです。オプション属性は、その名前またはOIDによって指定できます。
拒否属性: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在することを禁止する属性タイプのリストを指定します。構造化クラスまたは使用可能な補助クラスのいずれかで必要とされる属性タイプは、このリストに含めることはできません。このリストを使用することで、それらのオブジェクト・クラスのいずれかで使用可能となっている属性タイプの含有を防止できます。拒否属性は、その名前またはOIDによって指定できます。
オリジン: この新しいコンテンツ・ルールのソース(RFC 4517など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。
スキーマ・ファイル拡張: このコンテンツ・ルールの定義がファイルに格納されている場合は、そのファイルのパスを入力します。
「作成」をクリックすると、新しいコンテンツ・ルールが作成されます。
ODSMを使用して既存のコンテンツ・ルールに基づくコンテンツ・ルールを追加する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
新しいコンテンツ・ルールのベースとするコンテンツ・ルールを選択します。
「類似作成」アイコンをクリックします。
一部のフィールドは、選択したコンテンツ・ルールに基づいてデフォルトで設定されます。
新しいコンテンツ・ルールの残りのフィールドを設定します。
各フィールドとその値の詳細は、第33.6.20項「新規コンテンツ・ルールの作成」を参照してください。
「作成」をクリックすると、新しいコンテンツ・ルールが作成されます。
ODSMを使用して既存のコンテンツ・ルールを変更する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
変更するコンテンツ・ルールを選択します。
右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第33.6.20項「新規コンテンツ・ルールの作成」を参照してください。
「適用」をクリックして、変更を保存します。
ODSMを使用して既存のコンテンツ・ルールを削除する手順は次のとおりです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「スキーマ」タブを選択します。
「コンテンツ・ルール」パネルを開きます。
削除するコンテンツ・ルールを選択します。
「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。
「適用」をクリックして、変更を保存します。
「リフレッシュ」アイコンをクリックして左側のペインのコンテンツ・ルール・リストをリフレッシュし、そのコンテンツ・ルールがスキーマから削除されたことを確認します。