| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
この章では、ディレクトリ内のデータ・エントリを管理する方法について説明します。また、リフェラルを設定する方法、属性値を暗号化する方法、エントリを圧縮する方法についても説明します。
ディレクトリのデプロイメントを計画する場合には、ディレクトリに格納するデータの種類を把握する必要があります。エントリの作成とデフォルト・スキーマの変更に入る前に、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』の関連する章に目を通してください。
適切なACI(アクセス制御命令)が定義されていない場合、ディレクトリは変更できません。詳細は、第6章「Directory Serverのアクセス制御」を参照してください。
この章の内容は、次のとおりです。
エントリの管理に最適な方法は、状況によって異なります。
管理作業にはほとんどDSCCを使用しており、少数のエントリのみを検索または変更する場合は、DSCCを使用します。DSCCの詳細は、「Directory Service Control Centerのインタフェース」を参照してください。
大量のエントリを検索または変更する場合は、コマンドライン・ユーティリティldapmodifyおよびldapdeleteを使用します。
DSCCでは、暗号化されていない読取り可能なすべてのエントリの属性を表示し、書込み可能な属性を編集できます。また、属性を追加および削除したり、複数値属性を設定したり、エントリのオブジェクト・クラスを管理することもできます。DSCCを使用してエントリを管理する方法の詳細は、DSCCのオンライン・ヘルプを参照してください。DSCC全般の詳細は、「Directory Service Control Centerのインタフェース」を参照してください。
DSCCを使用して、Directory Serverインスタンスのエントリ管理タブ・ページでディレクトリ・エントリを直接追加または編集できます。エントリを追加および編集するためのウィザードを起動するボタンがあります。
次の手順では、エントリを拡張して、既存のエントリにユーザー定義属性を追加する方法を示します。たとえば、新しいアプリケーションでディレクトリにアクセスするには、各エントリに追加情報を格納する必要があり、テスト用にもエントリをいくつか作成する必要があります。
スキーマ・ウィザードを使用して、エントリに追加できる属性を指定するユーザー定義オブジェクト・クラスを設定します。
ディレクトリ・インスタンスへのリンクをクリックしてから、「スキーマ」をクリックして、ユーザー定義オブジェクト・クラスまでスクロールし、「追加」ボタンを押してウィザードを開きます。
または、構成ファイルを編集して、LDAPでディレクトリ・スキーマを更新することもできます。詳細は、第11章「Directory Serverのスキーマ」を参照してください。
LDAPでは、オブジェクト・クラス属性値をエントリに追加することでエントリが持つ属性のリストを拡張するため、オブジェクト・クラスを作成する必要があります。
エントリ管理タブで、更新するエントリを見つけます。
エントリを編集する場合、テキスト表示を使用します。
フォームベース・エディタには、編集可能なすべての属性が表示されますが、エントリを拡張するために追加できるオブジェクト・クラスは表示されません。
テキスト表示で、LDIFフォーマットに必要なオブジェクト・クラスおよび属性を追加します。
たとえば、example-attribute属性をLDIFに追加できるようにするexample-objectclassでスキーマを拡張する場合は次のとおりです。
dn: uid=bjensen,ou=People,dc=example,dc=com cn: Babs Jensen mail: bjensen@example.com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: example-objectclass sn: Jensen uid: bjensen example-attribute: Extended entry
テキスト表示エディタには、組込みのチェック・ルーチンがあるので、編集内容が有効かどうかを1回のクリックでチェックできます。編集内容がすべて想定どおりであれば、変更を適用します。
ldapmodifyおよびldapdeleteを使用したエントリの管理ldapmodifyおよびldapdelete コマンドライン・ユーティリティは、ディレクトリの内容を追加、編集および削除するためのすべての機能を提供します。これらのユーティリティを使用して、サーバーの構成エントリとユーザー・エントリのデータを管理できます。このユーティリティを使用して、1つ以上のディレクトリを一括管理するスクリプトを記述することもできます。
ldapmodifyおよびldapdeleteコマンドは、本書全般の手順で使用されます。次の各項では、それらの手順の実行に必要な基本的な操作について説明します。ldapmodifyおよびldapdeleteコマンドの詳細は、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
コマンドライン・ユーティリティの入力は、常にLDIFで行います。これはコマンドラインから直接指定することも、入力ファイルで指定することもできます。次の項では、LDIFの入力について説明し、それ以降の各項では、各種の変更で使用されるLDIF入力について説明します。
LDIF入力の正しいフォーマットの詳細は、Oracle Directory Server Enterprise EditionのリファレンスのLDIF入力の指定のガイドラインに関する項を参照してください。
次の各項では、それらの基本的な操作について説明します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: 必ずDirectory Server Enterprise Editionソフトウェアに付属の |
ldapmodifyの-aオプションを使用して、1つ以上のエントリをディレクトリに追加できます。次の例では、ユーザーを格納する構造化エントリを作成して、ユーザーのエントリを作成します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries dn: uid=bjensen,ou=People,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson uid: bjensen givenName: Barbara sn: Jensen cn: Babs Jensen telephoneNumber: (408) 555-3922 facsimileTelephoneNumber: (408) 555-4000 mail: bjensen@example.com userPassword: secret
-Dおよび-wオプションにより、これらのエントリを作成する権限を持つユーザーのバインドDNとパスワードをそれぞれ指定します。-aオプションは、LDIFのすべてのエントリが追加されることを示します。各エントリはそのDNとその属性値でリストされ、各エントリ間に空行が入ります。ldapmodifyユーティリティは、各エントリが入力されるとそのエントリを作成し、エラーがあるとそれを報告します。
エントリのLDIFには、慣例により、次の属性がリストされます。
エントリのDN。
オブジェクト・クラスのリスト。
ネーミング属性。これは、DNに使用される属性であり、必ずしも必要な属性ではありません。
すべてのオブジェクト・クラスに必要な属性のリスト。
含める必要がある、許可される任意の属性。
userPassword属性の値を入力する場合、クリアテキスト版のパスワードを入力します。サーバーではこの値を暗号化し、暗号化された値のみを保存します。LDIFファイルに表示されるクリアテキストのパスワードを保護するため、読取り権限を制限してください。
また、コマンドラインで-aオプションが不要なLDIFの別の形式を使用することもできます。この形式の利点は、次の例に示すように、エントリの追加文とエントリの変更文を組み合せられるということです。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: ou=People,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries dn: uid=bjensen,ou=People,dc=example,dc=com changetype: add objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson uid: bjensen givenName: Barbara sn: Jensen cn: Barbara Jensen telephoneNumber: (408) 555-3922 facsimileTelephoneNumber: (408) 555-4000 mail: bjensen@example.com userPassword: secret
changetype: addキーワードは、特定のDNを持つエントリが後続の属性をすべて含めて作成されることを意味します。その他すべてのオプションとLDIFの表記は、この項の前半で述べたものと同様です。
両方の例とも、-f filenameオプションを使用して、端末入力からではなく、ファイルからLDIFを読み込むことができます。-aオプションの使用に応じて、LDIFファイルには端末入力と同様のフォーマットが含まれる必要があります。
ldapmodifyを使用したエントリの変更WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: 必ずDirectory Server Enterprise Editionソフトウェアに付属の |
changetype: modifyキーワードを使用して、既存のエントリの属性とその値を追加、置換、または削除します。changetype: modifyを指定する場合、エントリの変更方法を示す1つ以上の変更操作を指定する必要があります。次の例に、使用可能な3つのLDIF変更操作を示します。
dn: entryDN changetype: modify add: attribute attribute: value... - replace: attribute attribute: newValue... - delete: attribute [attribute: value] ...
行の中にハイフン(-)を使用して、同じエントリ上の操作を区切ります。また、空行を使用して、様々なエントリの操作グループを区切ります。それぞれの操作にいくつかのattribute: valueのペアを指定することもできます。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
次の例では、同じadd LDIF構文を使用して、既存の複数値属性およびまだ存在していない属性に値を追加する方法を示します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: cn cn: Babs Jensen - add: mobile mobile: (408) 555-7844
次のいずれかの状況では、この操作は失敗し、サーバーがエラーを返す可能性があります。
属性に特定の値がすでに存在している。
値が属性に定義されている構文に従っていない。
属性タイプがエントリのオブジェクト・クラスで必要ない、または許可されていない。
属性タイプが複数値ではなく、その値がすでに存在している。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
属性の;binaryサブタイプは、実際の構文にかかわらず、その属性値がLDAP上でバイナリ・データとして転送される必要があることを示します。このサブタイプは、userCertificateなどのLDAP文字列表現を持たない複雑な構文用に設計されています。バイナリ・サブタイプは、この目的以外に使用しないでください。
ldapmodifyコマンドで使用する場合、任意のLDIF文で適切なサブタイプを属性名に追加できます。
バイナリ値を入力するには、LDIFテキストに直接入力するか、別のファイルから読み込みます。次の例で、ファイルから読み込むためのLDIF構文を示します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: version: 1 dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: userCertificate;binary userCertificate;binary:< file:///local/cert-file
:<構文を使用してファイル名を指定するには、LDIF文をversion: 1という行で開始する必要があります。ldapmodifyでこの文を処理する場合、特定のファイルの内容全体から読み込まれる値に属性が設定されます。
デフォルトでは、検索で;binaryオプションを使用すると、バイナリ属性を返します。compat-flagをnorfc4522に設定して、rfc4522コンプライアンスを無効にします。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
属性の言語とふりがなのサブタイプは、ローカライズされた値を指定します。属性の言語サブタイプを指定すると、そのサブタイプは次のように属性名に追加されます。
attribute;lang-CC
ここで、attributeは既存の属性タイプを表し、ccは言語を表す2文字の国コードを表します。必要に応じて、言語サブタイプにふりがなのサブタイプを追加し、ローカライズされた値の発音表記を指定できます。その場合、属性名は次のようになります。
attribute;lang-CC;phonetic
サブタイプを持つ属性上で操作を実行するには、そのタイプを明示的に一致させる必要があります。たとえば、lang-fr言語サブタイプを持つ属性値を変更する場合、変更操作で次のようにlang-frを含める必要があります。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: homePostalAddress;lang-fr homePostalAddress;lang-fr: 34, rue de la Paix
|
注意: 属性値にASCII以外の文字がある場合、UTF-8でエンコードする必要があります。 |
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次の例は、LDIFでreplace構文を使用して属性値を変更する方法を示します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify replace: sn sn: Morris - replace: cn cn: Barbara Morris cn: Babs Morris
指定された属性の現在の値はすべて削除され、指定されたすべての値が追加されます。
属性値を変更したら、ldapsearchコマンドを使用して、変更を検証できます。
属性値を変更する場合、誤って値の最後に空白を入れないでください。後ろに空白があると、それも属性値の一部としてサーバーに保存され、予期しない値が格納されることになります。
DSCCまたはldapsearchコマンドを使用して変更を検証する場合、値にプレーン・テキストが表示される場合と別の予期しない値が表示される場合があります。これは、使用するDirectory Serverクライアントによって異なります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次の例は、属性全体を削除する方法および複数値属性の値を1つのみ削除する方法について説明します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify delete: facsimileTelephoneNumber - delete: cn cn: Babs Morris
attribute: valueペアを指定せずにdelete構文を使用すると、属性のすべての値が削除されます。attribute: valueペアを指定すると、その値のみが削除されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
複数値属性の1つの値をldapmodifyコマンドで変更するには、次の例に示すように2つの操作を実行する必要があります。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify delete: mobile mobile: (408) 555-7845 - add: mobile mobile: (408) 555-5487
ldapdeleteを使用したエントリの削除WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: 必ずDirectory Server Enterprise Editionソフトウェアに付属の |
ldapdeleteコマンドライン・ユーティリティを使用して、ディレクトリからエントリを削除します。このユーティリティにより、ディレクトリ・サーバーへのバインド、およびDNに基づく1つ以上のエントリの削除を実行します。指定されたエントリを削除する権限を持つバインドDNを指定する必要があります。
子を持つエントリは削除できません。LDAPプロトコルでは、子エントリが親を持たないことを禁止しています。たとえば、まず組織単位に属するすべてのエントリを削除しないと、その組織単位のエントリは削除できません。
次の例は、組織単位にエントリが1つしかないことを示しています。このエントリを削除すると、その親エントリは削除できます。
$ ldapdelete -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: uid=bjensen,ou=People,dc=example,dc=com ou=People,dc=example,dc=com
ldapmodifyを使用したエントリの削除WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: 必ずDirectory Server Enterprise Editionソフトウェアに付属の |
ldapmodifyユーティリティを使用する場合、changetype: deleteキーワードを使用してエントリを削除することもできます。前の項で説明したように、ldapdeleteの使用時と同じ制限がすべて適用されます。エントリの削除にLDIF構文を使用する利点は、単一のLDIFファイルで混合の操作を実行できるということです。
次の例では、前の例と同じ削除操作を実行しています。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: uid=bjensen,ou=People,dc=example,dc=com changetype: delete dn: ou=People,dc=example,dc=com changetype: delete
ldapsearchを使用したエントリの検索WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: 必ずDirectory Server Enterprise Editionソフトウェアに付属の |
ldapsearchコマンドライン・ユーティリティを使用して、ディレクトリ・エントリを検索および取得できます。
ldapsearchの使用方法、一般的なldapsearchオプション、使用できる形式および例については、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
ldapmodifyを使用してエントリを移動または名前変更するにはこの手順では、DN変更操作を使用します。この操作を開始する前に、必ず「DN変更操作を使用するためのガイドラインおよび制限」を読んでよく理解してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: グループの |
ある親から別の親にエントリを移動する場合、親エントリ上でACI権限を拡張します。
エントリの移動元の親エントリ上で、構文allow (export ...)を使用することで、ACIでエクスポート操作が許可されるようにします。
エントリの移動先の親エントリ上で、構文allow (import ...)を使用することで、ACIでインポート操作が許可されるようにします。
ACIの使用の詳細は、第6章「Directory Serverのアクセス制御」を参照してください。
DN変更操作がグローバルで有効であるか、少なくとも移動操作で影響を受ける接尾辞で有効であることを確認してください。
前のリリースのDirectory Serverとの互換性を確保するため、デフォルトでDN変更操作は無効です。
すでにDN変更操作が有効な場合、次の手順に進みます。
サーバーでグローバルにDN変更操作を有効にするには、次の操作を実行します。
$ dsconf set-server-prop -h host -p port moddn-enabled:on
ldapmodifyコマンドを実行します。
この手順では、DN変更操作を使用します。次のいずれかを実行します。
エントリを移動します。
たとえば、次のコマンドを実行すると、エントリuid=bjensenはコントラクタのサブツリーou=Contractors,dc=example,dc=comから従業員のサブツリーou=People,dc=example,dc=comに移動します
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=Contractors,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 0 newsuperior: ou=People,dc=example,dc=com
エントリの名前を変更します。
たとえば、次のコマンドを実行すると、エントリの名前がuid=bbjensenからuid=bjensenに変更されます。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bbjensen,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 1
LDIF文を記述する際は、次の属性に注意してください。
dn - 名前の変更または移動を行うエントリを指定します。
changetype: modrdn - DN変更操作を使用することを指定します。
newrdn - 新しいネーミング属性を指定します。
deleteoldrdn - 前のネーミング属性をエントリから削除するかどうかを指定します(1は削除、0は削除しない)。
エントリ定義でネーミング属性が必須の場合、その属性はエントリから削除できません。
newsuperior - エントリの新しい上位属性を指定します。
ldapmodifyコマンドとそのオプションの詳細は、ldapmodifyについての説明のマニュアル・ページを参照してください。
大量のエントリを含むサブツリーを移動またはその名前を変更したときにリソース制限エラーが発生する場合、データベースで使用できるロックの数を増加します。
$ dsconf set-server-prop -h host -p port db-lock-count:value
このプロパティを変更する場合、その変更を有効にするにはサーバーを再起動する必要があります。
前の項で述べたようにDN変更操作を使用する場合、次の項で説明するガイドラインに従ってください。
DN変更操作を使用して、エントリをある接尾辞から別の接尾辞に移動したり、ルート接尾辞の移動や名前変更を行わないでください。
entryid操作属性は、内部で使用するためのみに予約されているため、アプリケーションでは使用しないでください。エントリのentryid属性は、エントリを移動するときに変更できます。
DN変更操作は、サーバー上のすべての接尾辞でグローバルに有効にすることも、操作を実行する各接尾辞で個別に有効にすることもできます。デフォルトでは、DN変更操作は無効です。
DN変更操作を実行する各接尾辞でACI権限を拡張します。Importアクセス権により、エントリを指定されたDNにインポートできます。Exportアクセス権により、エントリを指定されたDNからエクスポートできます。
DN変更操作を実行する前に、その操作によりクライアント認証が無効にならないことを確認してください。クライアント証明書を参照するエントリを移動する場合、クライアント認証は無効になります。エントリを移動した後、証明書を検証してください。
DN変更操作を実行する前に、この操作によってアプリケーションが中断されることがないようにしてください。エントリの移動または名前変更は、いくつかの接尾辞に影響したり、エントリの次の特性を変える場合があります。
エントリのフィルタ処理されたロールの範囲。
エントリのネストされたロール。ネストされたロールにはフィルタ処理されたゴールが含まれます。
エントリの動的グループ・メンバーシップ。
|
注意: 次の要件を遵守せずにDN変更操作を使用すると、レプリケーションが中断され、ディレクトリ・サービスが停止する場合があります。 |
レプリケーション・トポロジ内のすべてのサーバー上で、DN変更操作を有効にします。DN変更操作がマスター・サーバー上でサポートされていても、コンシューマ・サーバー上でサポートされていないと、レプリケーションは失敗します。サプライヤ・サーバーのエラー・ログには、次のようなメッセージが書き込まれます。
Unable to start a replication session with MODDN enabled
レプリケーションを再開するには、DN変更操作をすべてのサーバー上で使用できるようにレプリケーション・トポロジを再構成してから、次のいずれかの方法でレプリケーション・セッションを開始します。
「レプリケーションの更新を強制するには:」の説明に従う。
サプライヤ・サーバーでエントリを変更する。この変更はコンシューマ・サーバーにレプリケートされます。
トポロジ内のすべてのマスター・レプリカ上で参照整合性プラグインを有効化および構成します。この操作により、サーバーでグループおよびロールの参照整合性が確実に維持されます。参照整合性プラグインの有効化および構成の方法については、「参照整合性プラグインを構成するには:」を参照してください。
DN変更操作を実行した後で、参照整合性プラグインにより変更内容がレプリケートされるまで待機します。
関連するエントリをグループに関連付けて、エントリの管理を簡単にできます。グループのメカニズムにより、特定のグループのメンバーとなるエントリのリストを取得したり、グループ全体のアクセス権限を設定することが容易になります。
エントリは、動的グループおよび静的グループのメンバーとして管理できます。静的グループは、ディレクトリ管理者のグループなど、少人数のメンバーのグループに最適です。動的グループは1つ以上のURL検索フィルタを指定するため、それらの検索フィルタが評価されるごとに動的グループのメンバーシップが定義されます。
動的なisMemberOf属性を使用して、特定のユーザーがメンバーとなるすべての静的グループのリストを取得できます。属性はユーザー・エントリおよびネストされたグループ・エントリの中に存在し、そのメンバーが属する静的グループのDNを保持します。たとえば、Kirsten Vaughanが人事部の新しいシステム管理者だとします。彼女のエントリは、彼女がSystem AdministratorsグループとHR Managersグループの両方のメンバーであることを示しています。
$ ldapsearch -b "dc=example,dc=com" uid=kvaughan isMemberOf uid=kvaughan, ou=People, dc=example,dc=com isMemberOf: cn=System Administrators, ou=Groups, dc=example,dc=com isMemberOf: cn=HR Managers,ou=groups,dc=example,dc=com
グループ・エントリのメンバーシップ・テストが機能強化されました。以前は静的グループに対するいくつかの制限がありましたが(特にグループ・サイズの制限)、それらの機能強化により取り除かれました。このパフォーマンスの向上は、グループのエントリがエントリ・キャッシュにロードされた後にのみ効果があります。
データベース・エントリのサイズを小さくするために、エントリを圧縮できます。エントリを圧縮すると、大きなデータベースでオーバーフロー・ページ数が削減され、パフォーマンスも向上します。
圧縮が必要なエントリを指定するcompressed-entriesを構成します。
$ dsconf set-suffix-prop -p port-number dc=example,dc=com compressed-entries:all
詳細は、compressed-entriesに関する説明を参照してください。
圧縮手法を指定するcompression-modeを構成します。
$ dsconf set-suffix-prop -p port-number dc=example,dc=com compression-mode:DSZ
詳細は、compression-modeに関する説明を参照してください。
情報をローカルに取得できない場合に、問い合せるサーバーをクライアント・アプリケーションに通知するには、リフェラルを使用します。リフェラルとは、リモート接尾辞へのポインタ、つまりDirectory Serverが結果のかわりにクライアントへ返すエントリへのポインタです。その後、クライアントは、リフェラルで指定されたリモート・サーバー上で再度操作を実行する必要があります。
リダイレクションは、次の3つの場合に行われます。
クライアント・アプリケーションでローカル・サーバー上に存在しないエントリをリクエストした場合、およびサーバーがデフォルトのリフェラルを返すように構成されている場合。
メンテナンス時またはセキュリティ上の理由でエントリの接尾辞が無効な場合。
サーバーは、その接尾辞で定義されたリフェラルを返します。接尾辞レベルのリフェラルについては、「リフェラルの設定および接尾辞の読取り専用化」に説明があります。クライアントが書込み操作をリクエストした場合、接尾辞の読取り専用レプリカもマスター・サーバーへのリフェラルを返します。
クライアントが、とりわけスマート・リフェラルにアクセスしている場合。
スマート・リフェラルとは、ユーザーが作成するエントリです。サーバーは、スマート・リフェラルで定義するリフェラルを返します。
すべての場合において、リフェラルは、ホスト名、ポート番号、および必要に応じて別のサーバーのDNを含むLDAP URLになります。たとえば、ldap://east.example.com:389です。
ディレクトリ・デプロイメントでリフェラルを使用する方法の概念については、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。
次の各項では、ディレクトリのデフォルト・リフェラルを設定する手順およびスマート・リフェラルを作成および定義する手順について説明します。
デフォルト・リフェラルは、Directory Serverで保守される接尾辞に含まれないDNで操作を送信したクライアント・アプリケーションに返されます。サーバーは定義されているすべてのリフェラルを返しますが、返される順序は不定です。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
dsconfコマンドライン・ユーティリティを使用して1つ以上のデフォルト・リフェラルを設定します。
$ dsconf set-server-prop -h host -p port suffix-DN referral-url:referral-URL
次に例を示します。
$ dsconf set-server-prop -h host1 -p 1389 dc=example,dc=com \ referral-url:ldap://east.example.com:1389
スマート・リフェラルにより、ディレクトリ・エントリまたはディレクトリ・ツリーを特定のLDAP URLにマップできます。スマート・リフェラルを使用して、クライアント・アプリケーションで特定のサーバーまたは特定のサーバー上の特定のエントリを参照できます。
多くの場合、スマート・リフェラルは別のサーバー上の同じDNを持つ実際のエントリを指しています。ただし、同じサーバーまたは別のサーバーのあらゆるエントリに対するスマート・リフェラルを定義できます。たとえば、次のDNを持つエントリをスマート・リフェラルとして定義できます。
uid=bjensen,ou=People,dc=example,dc=com
このスマート・リフェラルは、サーバーeast.example.com上の別のエントリを指しています。
cn=Babs Jensen,ou=Sales,o=east,dc=example,dc=com
ディレクトリがスマート・リフェラルを使用する方法は、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)の第4.1.10項で指定されている標準に従います。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
スマート・リフェラルを作成するには、referralおよびextensibleObjectオブジェクト・クラスを持つエントリを作成します。
referralオブジェクト・クラスでは、LDAP URLを格納するように想定されているref属性を使用できます。extensibleObjectオブジェクト・クラスでは、ターゲット・エントリと一致させるために、ネーミング属性として任意のスキーマ属性を使用できます。
たとえば、エントリuid=bjensenのかわりに、スマート・リフェラルを返す下のエントリを定義するには、次のコマンドを使用します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: referral uid: bjensen ref: ldap://east.example.com/cn=Babs%20Jensen,ou=Sales,o=east,dc=example,dc=com
|
注意: LDAP URL内の空白の後にある情報は、サーバーでは無視されます。そのため、リフェラルとして使用する任意のLDAP URL内で、空白のかわりに |
スマート・リフェラルを定義した後、uid=bjensenエントリに対する変更は、実際には別のサーバー上のcn=Babs Jensenエントリで実行されます。ldapmodifyコマンドは、次の例のように自動的にリフェラルを追従します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: replace replace: telephoneNumber telephoneNumber: (408) 555-1234
スマート・リフェラル・エントリを変更するには、ldapmodifyの-Mオプションを使用します。
$ ldapmodify -M -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: replace replace: ref ref: ldap://east.example.com/cn=Babs%20Jensen,ou=Marketing,o=east,dc=example,dc=com
Directory Serverでは、次の操作を実行するときは常に、属性の整合性をチェックできます。
dsadm importまたはdsconf importによるデータのインポート。
LDAPまたはDSMLによるエントリの追加、エントリの変更、またはエントリのDNの変更。
このチェックにより、属性値をIETF勧告に準拠させられます。準拠していないすべての属性は拒否され、エラー・ログに記録されます。ログ・メッセージには、適宜接続および操作IDが含まれます。
デフォルトでは、サーバーによって前述の操作の構文が自動的にチェックされません。構文チェックをオンにする場合は、次の手順に従います。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
自動構文チェックをオンにするには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port check-syntax-enabled:on
デフォルトでは、サーバーは、新たに作成または変更されたエントリの特別な属性をLDAP v3仕様の指定どおりに保持します。これらの特別な属性は、接尾辞内のエントリに格納され、次のものが組み込まれます。
creatorsName — 最初にエントリを作成したユーザーのDN。
createTimestamp — エントリが作成されたときのタイムスタンプ(GMT形式)。
modifiersName — 最後にエントリを変更したユーザーのDN。
modifyTimestamp — エントリが変更されたときのタイムスタンプ(GMT形式)。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
|
注意: エントリ変更の追跡をオフにすると、データが準拠しないものになります。多くのアプリケーションがこれらの属性に依存しており、この機能を無効にしてもパフォーマンスがわずかに改善されるだけなので、エントリ変更の追跡はオフにしないことをお薦めします。 |
サーバーのエントリ変更の追跡をオフにします。
$ dsconf set-server-prop -h host -p port suffix-DN mod-tracking-enabled:off
属性値の暗号化により、機密データはディレクトリに格納されている間保護されます。属性の暗号化により、エントリの特定の属性を暗号化されたフォーマットで保存するように指定できます。そうすることで、データベース・ファイル、バックアップ・ファイル、およびエクスポートされたLDIFファイルに格納されている間は、データが読めなくなります。
ディスク上に保存されたデータのみが暗号化されます。コンソールのエントリ管理パネルに表示されるデータ、またはldapsearchコマンドの出力として表示されるデータがすべて暗号化されるわけではありません。
この機能により、属性値はDirectory Serverデータベースに保存される前に暗号化され、クライアントに返される前に元の値に復号化されます。アクセス制御を使用してしてクライアントが許可なくこれらの属性にアクセスすることを防ぎ、SSLによってクライアントとDirectory Server間のすべての通信を暗号化する必要があります。データ・セキュリティの一般的なアーキテクチャ上の概要(特に属性の暗号化)については、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
属性の暗号化は、SSLが構成されてサーバー上で有効な場合にのみ有効です。ただしデフォルトでは、属性は暗号化されません。属性の暗号化は、接尾辞レベルで構成されます。つまり、接尾辞内でその属性が現れるエントリごとに属性が暗号化されます。ディレクトリ全体で属性を暗号化する場合は、それぞれの接尾辞でその属性の暗号化を有効にする必要があります。
|
注意: 属性の暗号化は、接尾辞に関連付けられたすべてのデータおよび索引ファイルに影響を与えます。属性の暗号化が有効になった後で変更された属性のみが暗号化されます。既存の属性は、そのまま変更されません。
|
一部のエントリでネーミング属性として使用する属性を暗号化する場合、DNに表示される値は暗号化されません。エントリに格納される値は暗号化されます。
userPassword属性を暗号化するように選択しても、パスワードをクリアテキストで保存する必要がなければ、実際のセキュリティ上の利点がもたらされません。これは、DIGEST-MD5 SASL認証などの場合です。パスワード・ポリシーにパスワードの暗号化メカニズムが定義されている場合、それをさらに暗号化してもセキュリティの強化にはならず、各バインド操作のパフォーマンスが低下する結果になるのみです。
暗号化された上で格納されている属性には、使用された暗号化アルゴリズムを示す暗号化方式タグが最初に付けられます。DES暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。
{CKM_DES_CBC}3hakc&jla+=snda%
データを暗号化するためにオンラインでインポートする場合、サーバーへの認証に使用される鍵データベースのパスワードはすでに指定されているため、2回目には要求されなくなります。データをオフラインでインポートする場合、インポートするデータの暗号化を許可する前に、Directory Serverはパスワードの入力を求めます。より機密性の高い操作であるデータの復号化では、エクスポートをオンライン、オフラインのどちらで操作するかに関係なく、Directory Serverは常に鍵データベースのパスワードを要求します。これにより、セキュリティはさらに高まります。
|
注意: 証明書や秘密鍵を変更しないかぎり、サーバーによって引き続き同じ鍵が生成されます。そのため、両方のサーバー・インスタンスで同じ証明書を使用していれば、あるサーバー・インスタンスから別のサーバー・インスタンスへデータを転送できます。つまりエクスポートしてからトランスポートできます。 |
属性を暗号化することでデータのセキュリティが向上しますが、システムのパフォーマンスにも影響を及ぼします。暗号化が必要な属性について注意深く検討し、特に機密にする必要があると判断された属性のみを暗号化します。
機密データは索引ファイルより直接アクセスできるため、暗号化された属性に対応する索引キーは属性が完全に保護されるように暗号化する必要があります。索引付け自体がすでにDirectory Serverのパフォーマンスに影響しているため(索引キーの暗号化による負荷は含まれない)、データをインポートする、またはデータベースに初めて追加する前に属性の暗号化を構成してください。こうすることで、暗号化された属性には最初から索引が付けられます。
属性の暗号化機能を実装する場合、次の点を考慮してください。
一般的には、属性の暗号化構成を変更する場合、データをエクスポートして、構成に変更を加えた上で、新しく構成されたデータをインポートします。
これにより、いずれの機能も失われることなく、すべての構成変更が全体として適用されます。このような方法で行わなかった場合、一部の機能が喪失し、データのセキュリティが危険にさらされる可能性があります。
既存のデータベースで属性の暗号化構成を変更すると、システムのパフォーマンスに多大な影響を及ぼす場合があります。
たとえば、既存のデータが格納されたデータベース・インスタンスがあるとします。データベースには、mySensitiveAttributeという属性を持つエントリがあらかじめ格納されています。この属性の値は、データベースおよび索引ファイルにクリア・テキストで保存されています。この状態で、後からmySensitiveAttribute属性を暗号化しようとすると、データベース・インスタンス内のすべてのデータはエクスポートしてからデータベースにインポートしなおし、属性暗号化の構成を適用するためにサーバーがデータベースおよび索引ファイルを更新する必要があります。この結果生じるパフォーマンスの問題は、この属性が最初から暗号化されていたとすると、回避できた可能性があります。
暗号化されたフォーマットでデータをエクスポートするときに、不正なパスワードが使用されると、エクスポートは拒否されます。
-yまたは--decrypt-attrオプションを指定してdsconfコマンドを使用できるようにするには、set password promptモードをonに設定して、「証明書データベース・パスワードの構成」の説明にあるように、証明書データベース・パスワードを選択します。
データを復号化されたフォーマットでエクスポートする場合、サーバーはセキュリティ対策としてユーザーにパスワード入力を求めます。ユーザーが不正なパスワードを入力すると、サーバーは復号化されたデータのエクスポート処理を拒否します。パスワードは直接入力するか、パスワードが格納されたファイルへのパスを指定します。このファイルは、SSLパスワード・ファイルと同じ構文を持ちます。「証明書データベース・パスワードの構成」を参照してください。
アルゴリズムの変更はサポートされますが、正しく実行しないと、索引機能が失われることになります。
データの暗号化に使用されるアルゴリズムを変更するには、データをエクスポートし、属性の暗号化構成を変更してから、データをインポートします。この手順に従わないと、最初の暗号化アルゴリズムに基づいて作成された索引は機能しなくなります。
暗号化された属性は、使用された暗号化アルゴリズムを示す暗号化方式タグが最初に付けられるため、データのインポートは内部サーバー操作が処理します。そのため、Directory Serverでは、アルゴリズムを変更する前に、暗号化された形式でデータをエクスポートできます。
サーバーのSSL証明書を変更すると、暗号化されたデータの復号化ができなくななります。
サーバーのSSL証明書は、属性の暗号化機能で独自の鍵を生成するために使用され、その鍵は、暗号化および復号化操作の実行に使用されます。このため、SSL証明書は暗号化されたデータの復号化に必要です。あらかじめデータを復号化せずに証明書を変更すると、データを復号化できなくなります。これを回避するには、復号化されたフォーマットのデータをエクスポートして、証明書を変更してから、データをインポートしなおします。
暗号化されたフォーマットでデータを転送するには(あるサーバー・インスタンスから別のサーバー・インスタンスにデータをエクスポートおよびインポートするには)、両方のサーバー・インスタンスで同じ証明書を使用する必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
属性の暗号化を構成する接尾辞になんらかのエントリが含まれている場合、まずその接尾辞の内容をLDIFファイルにエクスポートする必要があります。
その接尾辞に暗号化された属性が含まれており、エクスポートされたLDIFファイルを使用して接尾辞を再度初期化する予定がある場合、その属性はエクスポートされたLDIFファイル内で暗号化されたままにできます。
属性の暗号化を有効にするには、次のコマンドを使用します。
$ dsconf create-encrypted-attr -h host -p port suffix-DN attr-name cipher-name
ここで、cipher-nameは次のいずれかです。
des - DESブロック暗号方式
des3 - トリプルDESブロック暗号方式
rc2 - RC2ブロック暗号方式
rc4 - RC4ストリーム暗号方式
aes128 - AESブロック暗号方式
aes256 - AESブロック暗号方式
camellia128 - 128ビット・ブロック暗号方式
camellia256 - 256ビット・ブロック暗号方式
次に例を示します。
$ dsconf create-encrypted-attr -h host1 -p 1389 dc=example,dc=com uid rc4
「接尾辞の初期化」で説明されているように、LDIFファイルを使用して接尾辞を初期化します。
|
注意:
|
ファイルがロードされて対応する索引が作成されると、指定された属性のすべての値が暗号化されます。
