この章では、ディレクトリ内のデータエントリを管理する方法について説明します。また、リフェラルを設定する方法と属性値を暗号化する方法についても説明します。
ディレクトリの配備を計画する場合には、ディレクトリに格納するデータの種類を把握する必要があります。エントリの作成とデフォルトスキーマの変更に入る前に、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の関連する章に目を通すようにしてください。
適切な ACI (アクセス制御命令) が定義されていない場合、ディレクトリは変更できません。詳細は、第 7 章「Directory Server のアクセス制御」を参照してください。
この章の内容は次のとおりです。
エントリを管理するための最良な方法は、状況によって異なります。
DSCC を主に管理用に使用していて、検索や変更を行いたいエントリは少ししかない場合は、DSCC を使用します。DSCC の詳細については、「Directory Service Control Center のインタフェース」を参照してください。
Directory Server で管理タスクを実行せず、検索や変更を行いたいエントリが少ししかない場合は、Directory Editor を使用します。Directory Editor の詳細は、『Sun Java System Directory Editor 1 2005Q1 Installation and Configuration Guide』を参照してください。
多数のエントリを検索したり変更したりする場合は、コマンド行ユーティリティー ldapmodify および ldapdelete を使用します。
DSCC では、エントリの読み取り可能な暗号化されていないすべての属性を表示し、書き込み可能な属性を編集できます。また、属性の追加と削除、複数値属性の設定、エントリのオブジェクトクラスの管理も行えます。DSCC によるエントリの管理方法の詳細は、DSCC のオンラインヘルプを参照してください。DSCC の概要については、「Directory Service Control Center のインタフェース」を参照してください。
Directory Editor は、管理者とエンドユーザーがデータを検索、作成、編集するための、使いやすいディレクトリ編集ツールです。扱えるデータの種類は、ユーザー、グループ、およびコンテナです。
コマンド行ユーティリティー ldapmodify および ldapdelete には、ディレクトリの内容を追加、編集、削除するための完全な機能が用意されています。これらのユーティリティーを使用して、サーバーの設定エントリと、ユーザーエントリに含まれるデータの両方を管理できます。これらのユーティリティーは、1 つまたは複数のディレクトリの一括管理を実行するためのスクリプトの作成にも利用できます。
ldapmodify コマンドと ldapdelete コマンドは、このマニュアル全体の手順で使用されます。次の節で、これらの手順の実行に必要な基本操作について説明します。ldapmodify コマンドと ldapdelete コマンドの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。
コマンド行ユーティリティーへの入力は、常に LDIF 形式で行います。この形式の入力は、コマンド行から直接指定できるだけでなく、入力ファイルからも行うことができます。次の節では、LDIF 入力について説明し、それ以降の節では各種変更処理で使われる LDIF 入力について説明します。
LDIF 入力の正しい形式については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Guidelines for Providing LDIF Input」を参照してください。
これらの基本操作については、次の節で説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
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。
オブジェクトクラスのリスト。
1 つまたは複数のネーミング属性。これは 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 を読み取ることができます。LDIF ファイルには、-a オプションの使用の有無に応じて、端末から入力する場合と同じ形式で情報を指定する必要があります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
既存のエントリの属性と属性値を追加、置換、または削除するときは、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 |
次のいずれかの場合は、処理が失敗し、エラーが返されることがあります。
指定した値がその属性にすでに存在する。
値が、属性に定義されている構文に準拠していない。
エントリのオブジェクトクラスが、その属性タイプを必要としないか、許可しない。
属性タイプが複数値ではなく、その属性にすでに値が存在する。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
attribute ;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 がこの文を処理するときに、このツールは、指定ファイルの内容全体から読み取った値を属性に設定します。
このタスクは DSCC を使用して実行することができます。詳細については、「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 で符号化する必要があります。
このタスクは DSCC を使用して実行することができます。詳細については、「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 コマンドで変更を確認します。
属性値を変更する場合、値末尾の後ろに空白文字を残さないでください。値の後ろに空白文字を残すと、その値が base-64 方式で表示される場合があります (34xy57eg など)。
属性値の後ろに空白文字がある場合、その空白文字は属性値の一部としてエンコードされます。DSCC コンソールまたは ldapsearch コマンドを使用して変更を確認する場合、値はプレーンテキストで表示されますが、base-64 方式のテキストで表示される場合もあります。これは、使用している Directory Server クライアントにより異なります。
このタスクは DSCC を使用して実行することができます。詳細については、「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 のペアを指定した場合は、その値だけが削除されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ldapmodify コマンドを使用して、複数値属性の 1 つの値を変更するには、次の例に示すように、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 |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ディレクトリからエントリを削除するときは、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 |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ldapmodify ユーティリティーを使用する場合は、changetype: delete キーワードを利用してエントリを削除することもできます。前の節で説明したように、ldapdelete の利用時と同じ制限事項がすべて適用されます。LDIF 構文を使用してエントリを削除する利点は、1 つの 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 |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ldapsearch コマンド行ユーティリティーは、ディレクトリエントリの検索と取得に使用できます。ldapsearch ユーティリティーは Solais プラットフォームに付属しているユーティリティーではありませんが、Directory Server Resource Kit の一部です。
ldapsearch の使い方、共通の ldapsearch オプション、受け入れられる形式、および例については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。
この手順では、DN 変更操作を使用します。この操作を始める前に、「DN の変更操作に関するガイドラインと制限」の節に記載されている内容を十分に理解してください。
この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。
グループの uniquemember であるエントリのDNを変更するときは、参照の完全性プラグインを有効にしておいてください。参照の完全性により、エントリが移動されたときにグループメンバーが調整されます。参照の完全性を有効にし、設定する方法の詳細は、「参照の完全性プラグインを設定する」を参照してください。
エントリをある親から別の親に移動する場合は、親エントリの ACI 権限を拡張します。
移動するエントリの現在の親エントリでは、ACI で export 操作が許可されていることを、allow (export ...) 構文を使用して確認します。
エントリの移動先の親エントリでは、ACI で import 操作が許可されていることを、allow (import ...) 構文を使用して確認します。
ACI の使い方については、第 7 章「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(1) のマニュアルページを参照してください。
多数のエントリが含まれているサブツリーを移動したり名前変更したりするときに、リソース制限エラーが発生した場合は、データベースで使用できるロック数を増やします。
$ dsconf set-server-prop -h host -p port db-lock-count:value |
このプロパティーを変更する場合は、変更を有効にするためにサーバーを再起動する必要があります。
DN の変更操作を、前の節で説明したように使用する場合は、次の節で説明するガイドラインにしたがってください。
DN の変更操作は、エントリのサフィックス間の移動や、ルートサフィックスの名前変更または移動には使用しないでください。
実行中の Directory Server が 5.2 2005Q1 以降であることを確認してください。Directory Server 5.2 2005Q1 以前のバージョンの Directory Server では、DN の変更操作を使用できません。
entryid オペレーショナル属性は、内部使用専用の属性のため、DN 変更操作では使用しないでください。エントリの entryid オペレーショナル属性は、エントリが移動する際に変更される可能性があります。
DN の変更操作はサーバー上のすべてのサフィックスに対してグローバルに、または操作を実行する各サフィックスで個別に有効にすることができます。デフォルトでは、DN の変更操作は無効になっています。
サフィックス上で、DN の変更操作を実行するには、そのサフィックスの ACI 権限を拡張します。Import アクセス権を許可すると、指定された DN にエントリをインポートすることができます。Export アクセス権を許可すると、指定された DN からエントリをエクスポートすることができます。
DN の変更操作を実行する前に、この操作によってクライアント認証が無効にならないことを確認してください。クライアント証明書を参照しているエントリを移動すると、クライアント認証が無効になってしまいます。エントリの移動によって、証明書が無効になっていないかどうかを確認してください。
DN の変更操作を実行する前に、この操作によってアプリケーションが中断されることがないようにしてください。エントリの名前変更または移動によりいくつかのサフィックスに影響が及ぶ場合があります。あるいはエントリの次の特性が変更される可能性があります。
エントリのフィルタが適用されたロールの範囲。
エントリの入れ子のロール。入れ子のロールにはフィルタ化されたロールが格納されます。
エントリのダイナミックグループのメンバーシップ。
次の要件を満たさずに DN の変更操作を実行すると、レプリケーションが中断され、ディレクトリサービスが停止する可能性があります。
レプリケーショントポロジのすべてのサーバーが Directory Server 5.2 以降を実行していることを確認します。Directory Server 5.2 より前のバージョンの Directory Server では、DN の変更操作を使用できません。
レプリケーショントポロジのすべてのサーバーで、DN の変更操作を有効にします。DN の変更操作がマスターサーバーでサポートされていてもコンシューマサーバーでサポートされていない場合、レプリケーションは失敗します。サプライヤサーバーのエラーログに、次のようなメッセージが書き込まれます。
Unable to start a replication session with MODDN enabled
レプリケーションを再開するには、レプリケーショントポロジを再設定してすべてのサーバーで DN の変更操作を有効にします。そのあと、次のいずれかの方法で、レプリケーションセッションを開始します。
「レプリケーションの更新を強制的に実行する」の手順に従います。
サプライヤサーバーでエントリを変更します。変更内容はコンシューマサーバーにレプリケートされます。
トポロジのすべてのマスターレプリカで、参照の完全性プラグインを有効にし設定します。このアクションにより、サーバーがグループとロールに対して参照の完全性を維持できます。参照の完全性を有効にし、設定する方法の詳細は、「参照の完全性プラグインを設定する」を参照してください。
DN の変更操作を実行した後で、参照の完全性プラグインにより変更内容がレプリケートされるまで待機します。
情報をローカルに取得できない場合に、どのサーバーに接続すべきかをクライアントアプリケーションに通知するには、リフェラルを使います。リフェラルとは、リモートサフィックスへのポインタ、つまり Directory Server が結果の代わりにクライアントへ返すエントリへのポインタです。クライアントは、リフェラルで指定されたリモートサーバー上で、再度、操作を実行する必要があります。
リダイレクションは、次の 3 つの場合に行われます。
クライアントアプリケーションがローカルサーバーに存在しないエントリを要求し、サーバーがデフォルトのリフェラルを返すよう構成されている場合。
サフィックス全体がメンテナンスまたはセキュリティー上の理由で無効になっている場合。
サーバーは、該当のサフィックスで定義されているリフェラルを返します。サフィックスレベルのリフェラルについては、「リフェラルを設定し、サフィックスを読み取り専用にする」を参照してください。クライアントが書き込み処理を要求する場合、サフィックスの読み取り専用レプリカも、マスターサーバーへのリフェラルを返します。
クライアントが特にスマートリフェラルにアクセスする場合。
スマートリフェラルは、ユーザーが作成するエントリです。サーバーは、スマートリフェラルが定義するリフェラルを返します。
いずれの場合も、リフェラルは LDAP URL であり、ホスト名、ポート番号、およびオプションとして別のサーバー上の DN を含みます。たとえば、ldap://east.example.com:389 です。
ディレクトリの配備でリフェラルを使用する方法の概念情報は、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。
次に、ディレクトリのデフォルトリフェラルを設定する手順と、スマートリフェラルを作成および定義する手順について説明します。
デフォルトリフェラルは、Directory Server で管理されているサフィックスに含まれない DN に対して操作を送信するクライアントアプリケーションに返されます。サーバーは定義されているすべてのリフェラルを返しますが、返す順序は定義されていません。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
1 つ以上のデフォルトリフェラルを設定するには、dsconf コマンド行ユーティリティーを使用します。
$ 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 に指定されている標準に準拠する必要があります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
スマートリフェラルを作成するには、referral オブジェクトクラスと extensibleObject オブジェクトクラスを持つエントリを作成します。
referral オブジェクトクラスでは、ref 属性で LDAP URL を指定します。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 では、空白の代わりに %20 を使用する必要があります。その他の特殊文字はエスケープする必要があります。
スマートリフェラルを定義すると、別のサーバー上の cn=Babs Jensen エントリで、uid=bjensen エントリの修正が実際に行われます。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 を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
デフォルトでは、サーバーは、新たに作成または変更されたエントリの特別な属性を LDAP v3 仕様の指定どおりに保持します。これらの特別な属性は、サフィックス内のエントリに格納され、次のものが組み込まれます。
creatorsName — 最初にエントリを作成したユーザーの DN。
createTimestamp — エントリが作成されたときのタイムスタンプ (GMT 形式)。
modifiersName — エントリを最後に変更したユーザーの DN。
modifyTimestamp — エントリが変更されたときのタイムスタンプ (GMT 形式)。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
エントリの変更記録をオフにすると、データが準拠しないものになります。多くのアプリケーションはこれらの属性に依存しているため、また、これらの機能を無効にすると最低限のパフォーマンスしか得られなくなるため、エントリ変更記録はオフにしないことをお勧めします。
属性の暗号化はディレクトリに格納されている機密データを保護します。この機能を使用すると、エントリの特定の属性を暗号化された形式で格納するように指定できます。これにより、データベースファイル、バックアップファイル、およびエクスポートされた LDIF ファイルに格納されているデータが読み取られることを防ぎます。
この機能では、属性値は Directory Server データベースに格納される前に暗号化され、クライアントに返される前に元の値に復号化されます。クライアントと Directory Server との間でやり取りを行うときに、アクセス制御を使用してクライアントがこれらの属性に許可なくアクセスすることを防ぎ、SSL を使用して属性値を暗号化する必要があります。データセキュリティー全般のアーキテクチャー上の概要と、属性の暗号化の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。
属性の暗号化は、サーバー上で SSL が設定され有効になっている場合だけアクティブになります。ただし、デフォルトでは、どの属性も暗号化されません。属性の暗号化はサフィックスレベルで設定されます。つまり、サフィックス内でその属性が現れるすべてのエントリについて、属性が暗号化されます。ディレクトリ全体で属性を暗号化するには、すべてのサフィックスでその属性の暗号化を有効にする必要があります。
属性を暗号化すると、サフィックスに関連付けられたすべてのデータとインデックスファイルが影響を受けます。既存のサフィックスについて暗号化設定を変更するときは、まずサフィックスの内容をエクスポートし、設定を変更してからその内容をふたたびインポートする必要があります。これらの手順は、DSCCを使用して実行できます。DSCC の使用については、「Directory Service Control Center のインタフェース」を参照してください。
さらにセキュリティーについて考慮するならば、属性の暗号化をオンにする際に、暗号化されていない値がまだ含まれている可能性があるデータベースキャッシュファイルとデータベースログファイルを、手動で削除してください。これらのファイルを削除する手順については、「属性の暗号化を設定する」を参照してください。
新しいサフィックスにデータを読み込むときや作成するときは、暗号化されているすべての属性を有効にしてください。
一部のエントリがネーミング属性として使用している属性を暗号化すると、DN に表示される値は暗号化されないままですが、エントリ内に格納されている値は暗号化されています。
暗号化のために userPassword 属性を選択することはできますが、パスワードがクリアテキストとして格納される必要がある場合を除き、実質的なセキュリティー上の利点はありません。これは、DIGEST-MD5 SASL 認証などの場合です。パスワードポリシーにパスワードの暗号化メカニズムが定義されている場合、それをさらに暗号化してもセキュリティーの強化にはならず、バインド操作のたびにパフォーマンスが低下するという結果になるだけです。
暗号化された上で格納されている属性には、適用された暗号化アルゴリズムを示す暗号化方式タグが最初に付けられます。DES 暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。
{CKM_DES_CBC}3hakc&jla+=snda% |
データを暗号化するためにオンラインで (dsconf コマンドを使って) インポートする場合、サーバーへの認証に使用される鍵データベースのパスワードはすでに指定されているため、2 回目には要求されなくなります。データをオフラインで (dsadm コマンドを使って) インポートする場合、インポートするデータを暗号化するたびに Directory Server はパスワードを要求します。より機密性の高い操作であるデータの復号化では、エクスポートをオンライン、オフラインのどちらで行うかに関係なく、Directory Server は常に鍵データベースのパスワードを要求します。これにより、セキュリティーはさらに高まります。
証明書や非公開鍵を変更しない限り、サーバーにより引き続き同じ鍵が生成されます。そのため、両方のサーバーインスタンスが同じ証明書を使用していた場合は、データをあるサーバーインスタンスから別のサーバーインスタンスにトランスポートできます。つまりエクスポートしてからトランスポートできます。
属性を暗号化することでデータのセキュリティーは向上しますが、システムのパフォーマンスに影響が生じます。どの属性を暗号化する必要があるかを十分に検討し、特に機密にするべきと考えられる属性のみを暗号化します。
機密データはインデックスファイルから直接アクセスできるため、暗号化された属性に対応するインデックスキーを暗号化して、それらの属性を完全に保護する必要があります。インデックス付け自体がすでに Directory Server のパフォーマンスに影響しているため (インデックスキーの暗号化による負荷は含まれない)、データをインポートする、またはデータベースに初めて追加する前に属性暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。
属性暗号化機能を実装するときは、次の点を考慮してください。
一般に、属性暗号化の設定を変更するときは、データをエクスポートし、変更を加えた上で、新たに設定されたデータをインポートする必要があります。
これにより、機能が喪失することなく、すべての設定変更が全体として適用されます。このような方法で行わなかった場合、一部の機能が喪失し、データのセキュリティーが危険にさらされる可能性があります。
既存のデータベースに対する属性暗号化の設定を変更すると、システムのパフォーマンスに大きく影響することがあります。
たとえば、既存のデータが格納されたデータベースインスタンスについて考えてみましょう。このデータベースには、mySensitiveAttribute という属性を持つエントリが格納されています。その属性の値は、データベースとインデックスファイルにクリアテキストで格納されているものとします。この状態で、あとから、mySensitiveAttribute 属性を暗号化しようとすると、属性暗号化の設定を適用するためにサーバーがデータベースとインデックスファイルを更新する必要があり、データベースインスタンス内のすべてのデータはエクスポートされ、データベースに再びインポートされます。これにより、パフォーマンスに大きな影響が生じます。この結果生じるパフォーマンスの問題は、もし、この属性を最初から暗号化していれば回避できるはずです。
復号化された形式でデータをエクスポートするときに、誤ったパスワードを使用するとエクスポートが拒否されます。
データを復号化された形式でエクスポートしようとすると、セキュリティー保護のために、ユーザーにパスワードの入力を求めるプロンプトが表示されます。ユーザーが誤ったパスワードを入力すると、サーバーにより復号化されたデータのエクスポート操作が拒否されます。パスワードは、直接入力するか、パスワードが含まれているファイルへのパスを指定することで入力できます。このファイルには、SSL パスワードファイルと同じ構文があります。「証明書データベースパスワードの設定」を参照してください。
dsconf コマンドで -–decrypt-attr オプションを使用するには、set password prompt を on に設定し、「証明書データベースパスワードの設定」で説明するように、証明書データベースパスワードを選択している必要があります。
アルゴリズムの変更はサポートされていますが、正しく作成されていない場合、インデックス付け機能は失われる可能性があります。
データの暗号化に使用するアルゴリズムを変更するには、データをエクスポートし、属性の暗号化設定を変更してから、データをインポートします。この手順どおりに行わない場合、内部暗号化アルゴリズムに基づいて作成されたインデックスは機能しなくなります。
暗号化された属性は使用する暗号化アルゴリズムを指定する暗号化方式タグの前に置かれるため、データのインポートは内部サーバー操作が処理します。このため、Directory Server では、アルゴリズムを変更する前に、データを暗号化された形式でエクスポートできます。
サーバーの SSL 証明書を変更すると、暗号化されたデータを復号化できなくなります。
サーバーの SSL 証明書は、属性暗号化機能で独自の鍵の生成に使用され、そのあと暗号化および復号化操作の実行に使用されます。このため、SSL 証明書は暗号化されたデータの復号化に必要です。前もってデータを復号化しないで証明書を変更すると、データは復号化できません。これを回避するには、復号化された形式でデータをエクスポートし、証明書を変更してからデータをインポートしてください。
暗号化されたデータを伝送する、つまり、サーバーインスタンス間でエクスポートとインポートを行うには、両方のサーバーインスタンスが同じ証明書を使用する必要があります。
詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「属性値の暗号化」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「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 ストリーム暗号化方式
次に例を示します。
$ dsconf create-encrypted-attr -h host1 -p 1389 dc=example,dc=com uid rc4 |
暗号化された属性を元の状態に戻すには、次のコマンドを使用します。
$ dsconf delete-encrypted-attr -h host -p port suffix-DN attr-name |
1 つ以上の属性を暗号化するように設定を変更していて、インポート操作の前にそれらの属性に値が含まれている場合は、データベースキャッシュをクリアし、ログを削除します。
暗号化されていない値は、データベースキャッシュとデータベースログには表示されません。
これらのファイルを削除すると、一部の追跡情報が失われます。また、これらのファイルを削除すると、サーバーが復旧モードになり、再起動に時間がかかる場合があります。
データベースキャッシュをクリアし、ログを削除するには、次のように操作します。
「Directory Server インスタンスの起動、停止、および再起動」で説明するように、Directory Server を停止します。
root または管理者権限を持つユーザーとして、ファイルシステムの次の場所にあるデータベースキャッシュファイルを削除します。
# rm instance-path/db/__db.* |
ファイルシステムからデータベースログファイルを削除します。
# rm instance-path/db/log.0000000001 |
Directory Server を再起動します。
サーバーは、新しいデータベースキャッシュファイルを自動的に作成します。ふたたびキャッシュがいっぱいになるまで、このサフィックスでの操作のパフォーマンスは、若干の影響を受ける可能性があります。
「サフィックスの初期化」で説明する方法で、LDIF ファイルを使用してサフィックスを初期化します。
このファイルが読み込まれ、対応するインデックスが作成されるときに、指定した属性の値はすべて暗号化されます。