前へ
目次
索引
DocHome
次へ
|
| iPlanet Directory Server 5.1 管理者ガイド |
第 3 章 ディレクトリデータベースの構成
ディレクトリは複数のデータベースから構成されます。また、ディレクトリツリーは、データベース全体に分散させることができます。この章では、接尾辞の作成方法、ディレクトリツリーの分岐点、および各接尾辞 (suffix) に関連付けられているデータベースの作成方法について説明します。また、リモートサーバにあるデータベースを参照するデータベースリンクの作成方法や、レフェラルを使用して、クライアントにディレクトリデータの外部ソースをポイントさせる方法についても説明します。
接尾辞の作成と管理
ディレクトリデータの分散の概念については、『iPlanet Directory Server 導入ガイド』を参照してください。
接尾辞の作成と管理
ディレクトリツリーの各部分をさまざまなデータベースに格納し、これらのデータベースを複数のサーバに分散させることができます。ディレクトリツリーには、ノードと呼ばれる分岐点があります。これらのノードには、必ずしもデータベースを関連付ける必要はありません。ノードは、Directory Server Console の「ディレクトリ」タブを使用して作成します。このタブでは、ディレクトリツリーに表示されるエントリを自由に編集できます。接尾辞は、特定のデータベースに関連付けられているディレクトリツリーのノードです。この特殊なノードは、Directory Server Console の「データベース」タブを使用して作成します。次に、単純なディレクトリツリーの例を示します。
ou=people 接尾辞と、それ以下のすべてのエントリおよびノードは、1 つのデータベースに格納されます。ou=groups 接尾辞や ou=contractors 接尾辞はそれぞれ別のデータベースに格納されます。
ここでは、Directory Server に接尾辞を作成し、これらの接尾辞をデータベースと関連付ける方法について、次の項目ごとに説明します。
「接尾辞の作成」
接尾辞の作成
ルート接尾辞とサブ接尾辞の両方を作成して、ディレクトリツリーの内容を編成できます。ルート接尾辞 (root suffix) は、サブ接尾辞 (sub suffix) の親です。Directory Server 用に設計された大きなツリーの一部になることができます。サブ接尾辞は、ルート接尾辞の下にある分岐です。ルート接尾辞とサブ接尾辞のデータはデータベースに格納されます。ディレクトリに複数のルート接尾辞が含まれることもあります。たとえば、ある ISP が、siroe.com や i-zed.com など、複数の Web サイトにホスティングサービスを提供しているとします。ISP は、1 つは dc=siroe,dc=com 命名コンテクストに対応し、もう 1 つは dc=i-zed,dc=com 命名コンテクストに対応する、2 つのルート接尾辞を作成します。ディレクトリツリーは次のように表されます。
また、検索操作からディレクトリツリーの特定の部分を除外するように、ルート接尾辞を作成することもできます。たとえば、siroe.com Corporation が、企業全体のディレクトリ検索からヨーロッパオフィスを除外することを希望しているとします。このためには、2 つのルート接尾辞を作成します。1 つは siroe.com Corporation 全体のディレクトリツリーである dc=siroe,dc=com に対応するルート接尾辞で、もう 1 つはディレクトリツリーのヨーロッパ分岐 l=europe,dc=siroe,dc=com に対応するルート接尾辞です。クライアントアプリケーションからは、このディレクトリツリーは次のように見えます。
siroe.com Corporation ディレクトリの dc=siroe,dc=com 分岐に対してクライアントアプリケーションが検索を実行しても、l=europe,dc=siroe,dc=com 分岐にあるエントリは返されません。これは、ルート接尾辞が異なっているからです。
siroe.com Corporation が、ディレクトリツリーのヨーロッパ分岐のエントリを全体検索に含めると決めた場合は、この分岐を全体分岐のサブ接尾辞にする必要があります。このためには、siroe.com Corporation のルート接尾辞 dc=siroe,dc=com を作成してから、この下にヨーロッパディレクトリエントリのサブ接尾辞 l=europe,dc=siroe,dc=com を作成します。クライアントアプリケーションからは、このディレクトリツリーは次のように見えます。
ここでは、Directory Server Console またはコマンド行を使用して、ディレクトリにルート接尾辞とサブ接尾辞を作成する方法について説明します。次の手順について説明します。
「Console を使用した新しいルート接尾辞の作成」
Console を使用した新しいルート接尾辞の作成
接尾辞を作成し、これにデータベースを関連付ける手順は次のとおりです。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画で Data をマウスの右ボタンでクリックし、ポップアップメニューから「新規ルート接尾辞」を選択します。
「新規接頭辞」フィールドに、一意の接尾辞名を入力します。
- 「新規ルート接尾辞の作成」ダイアログボックスが表示されます。
新しいルート接尾辞の作成時に現在のディレクトリにデータベースも作成する場合は、「関連するデータベースの自動作成」チェックボックスがデフォルトで選択されています。
- 接尾辞の名前は、dc (domain-component) 命名規則に従って付ける必要があります。たとえば、dc=siroe,dc=com という新しい接尾辞名を入力します。
手順 4 で「関連するデータベースの自動作成」チェックボックスを選択した場合は、「データベース名」フィールドに新しいデータベースの一意な名前を入力します。
- 新しいルート接尾辞のデータベースを別のディレクトリに作成する場合または後で作成する場合は、このチェックボックスの選択を解除します。新しいルート接尾辞は、データベースが作成されるまで無効になっています。
「OK」をクリックして、新しいルート接尾辞を作成します。
- この名前に使用できる文字は、ASCII (7 ビット) 英数字、ハイフン (-)、およびアンダースコア (_) だけです。たとえば、新しいデータベースに siroe_2 という名前を付けることができます。
- 作成したルート接尾辞は、左側のナビゲーション区画にある Data 分岐の下に自動的に表示されます。
Console を使用した新しいサブ接尾辞の作成
既存のルート接尾辞またはサブ接尾辞の下にサブ接尾辞を作成する手順は次のとおりです。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画にある Data で、新しいサブ接尾辞の追加先となる接尾辞を選択します。この接尾辞をマウスの右ボタンでクリックし、ポップアップメニューから「新規サブ接尾辞」を選択します。
「新規接頭辞」フィールドに、一意の接尾辞を入力します。
- 「新規サブ接尾辞の作成」ダイアログボックスが表示されます。
新しいルート接尾辞の作成時に現在のディレクトリにデータベースも作成する場合は、「関連するデータベースの自動作成」チェックボックスがデフォルトで選択されています。
- そのルート接尾辞の命名規則に従って接尾辞を指定する必要があります。ルート接尾辞は自動的に名前に追加されます。たとえば、dc=siroe,dc=com ルート接尾辞の下にサブ接尾辞 ou=groups を作成すると、このサブ接尾辞に ou=groups,dc=siroe,dc=com という名前が自動的に付けられます。
手順 4 で「関連するデータベースの自動作成」チェックボックスを選択した場合は、「データベース名」フィールドに新しいデータベースの一意な名前を入力します。
- 新しいサブ接尾辞のデータベースを別のディレクトリに作成する場合または後で作成する場合は、このチェックボックスの選択を解除します。新しい接尾辞は、データベースが作成されるまで無効になっています。
「OK」をクリックして、新しいサブ接尾辞を作成します。
- この名前に使用できる文字は、ASCII (7 ビット) 英数字、ハイフン (-)、およびアンダースコア (_)のみです。たとえば、新しいデータベースに siroe_sub2 という名前を付けることができます。
- 新しい接尾辞は、左側のナビゲーション区画にある Data ツリーのルート接尾辞の下に自動的に表示されます。
コマンド行からのルート接尾辞およびサブ接尾辞の作成
ldapmodify コマンド行ユーティリティを使用して、ディレクトリ構成ファイルに新しい接尾辞を追加します。この項目で説明している例では、接尾辞の構成情報は cn=mapping tree,cn=config エントリに格納されます。
たとえば、ldapmodify ユーティリティを使用して、構成ファイルに新しいルート接尾辞を追加するとします。最初に次のユーティリティを含むディレクトリに移動します。
% cd /usr/iplanet/ds5/shared/bin % cd installDir/shared/bin
ldapmodify ユーティリティはサーバにバインドし、構成ファイルにエントリを追加する準備を行います。
- ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
次のように入力して、siroe.com Corporation のルート接尾辞エントリを作成します。
dn: cn="dc=siroe,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: UserData
cn:dc=siroe,dc=comこのルート接尾辞の下に groups のサブ接尾辞を作成するには、ldapmodify コマンドを使用して、次のエントリを追加します。
dn: cn="ou=groups,dc=siroe,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: GroupData
nsslapd-parent-suffix: "dc=siroe,dc=com"
cn: ou=groups,dc=siroe,dc=com
次の表に、接尾辞エントリを構成するために使用される属性を示します。
接尾辞の DN を定義する。DN は二重引用符 (") で囲む。値は、cn="dc=domain,dc=com",cn=mapping tree, cn=config という形式になる。
エントリがルート接尾辞エントリであるか、サブ接尾辞エントリであるかを示す。この属性は常に nsMappingTree という値をとる
接尾辞によって返される レプリカ (replica) の LDAP URL を定義する。この属性には、複数の値を指定できるが、1 つの値につき指定できるレフェラルは 1 つ。nsslapd-state 属性の値が referral または referral on update である場合に、この属性が必要
要求の処理に使用されるデータベース、または データベースリンク (database link) の名前を指定する。この属性には複数の値を指定できるが、1 つの値で 1 つのデータベースまたはデータベースリンクを指定する。データベースリンクについては、「データベースリンクの作成と管理」を参照
nsslapd-state 属性が backend または referral on update に設定されている場合、この属性は必須
カスタム分散関数とともに使用される共有ライブラリを指定する。nsslapd-backend 属性で複数のデータベースを指定した場合は、この属性は必須
カスタム分散関数については、「データベースの作成と管理」を参照
カスタム分散関数の名前を指定する。nsslapd-backend 属性で複数のデータベースを指定した場合は、この属性は必須
カスタム分散関数については、「データベースの作成と管理」を参照
サブ接尾辞の親エントリの DN を表す。デフォルトでは、この属性は存在しない。つまり、この接尾辞がルート接尾辞であるとみなされる
たとえば、ルート接尾辞 dc=siroe,dc=com の下にサブ接尾辞 o=sales,dc=siroe,dc=com を作成する場合、サブ接尾辞の nsslapd-parent-suffix 属性に次の値を追加する
nsslapd-parent-suffix: "dc=siroe,dc=com"
「接尾辞でのレフェラルの使い方」
接尾辞でのレフェラルの使い方
レフェラルを使用して、クライアントアプリケーションが一時的に別のサーバをポイントするように設定することができます。たとえば、接尾辞と関連付けられたデータベースが保守のためにオフラインになった場合でも、接尾辞にレフェラルを追加しておくことにより、クライアントが別のサーバをポイントするように設定することができます。レフェラルの概要については、『iPlanet Directory Server 導入ガイド』を参照してください。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data で、レフェラルの追加先となる接尾辞をクリックします。
「接尾辞の設定」タブをクリックします。「レフェラルを使用する」ラジオボタンを選択します。
「レフェラル」タブをクリックします。「新規レフェラルの入力」フィールドに LDAP URL を入力します。あるいは、「構築」をクリックすると、LDAP URL の作成がガイドされます。
「追加」をクリックすると、レプリカ (replica) がリストに追加されます。
- LDAP URL の構造については、付録 C「LDAP URLs」を参照してください。
「保存」をクリックします。
- 複数のレフェラルを入力できます。クライアントアプリケーションからの要求に対応して、ディレクトリがレフェラルのリスト全体を返します。
更新操作中だけのレフェラルの有効化
クライアントアプリケーションから読み取り専用データベースへの更新要求と書き込み要求に対して、リダイレクトされるようにディレクトリを構成することができます。たとえば、ディレクトリデータのローカルコピーがあり、その所有者がユーザ自身ではない場合に、更新操作のレフェラルを有効にしたとします。ここでこのデータを、検索には使用でき更新には使用できないようにするためには、更新要求中に限定して、レフェラルを有効にします。この設定により、クライアントアプリケーションからエントリの更新が要求されたときに限って、このデータを所有するサーバに対してクライアントが照会され、このサーバで修正要求が処理されるようになります。
更新操作中だけにレフェラルを有効にするには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data で、レフェラルの追加先となる接尾辞をクリックします。
「接尾辞の設定」タブをクリックします。「更新時にレフェラルを使用する」ラジオボタンを選択します。
「レフェラル」タブをクリックします。「新規レフェラルの入力」フィールドに LDAP URL を入力します。あるいは、「構築」をクリックすると、LDAP URL の作成がガイドされます。
「追加」をクリックすると、レプリカ (replica) がリストに追加されます。
- LDAP URL の構造については、付録 C「LDAP URLs」を参照してください。
「保存」をクリックします。
- 複数のレフェラルを入力できます。クライアントアプリケーションからの要求に対応して、ディレクトリがレフェラルのリスト全体を返します。
接尾辞の無効化
しばしば、保守のためのデータベースの停止が必要になり、しかしそのデータベースに格納されているデータがレプリケートされていない場合があります。このような場合は、レフェラルを返すのではなく、このデータベースを受け持つ接尾辞を無効にすることができます。接尾辞を無効にすると、クライアントアプリケーションが検索、追加、修正などの LDAP 処理を実行しても、この接尾辞に関連するデータベースのコンテンツは、クライアントアプリケーションからは見えなくなります。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画にある Data で、無効にする接尾辞を選択します。
「接尾辞の設定」タブをクリックします。「この接尾辞を有効にする」チェックボックスの選択を解除します。
「保存」をクリックします。
- 保存する必要のある変更があることを示す赤い点が、「接尾辞の設定」タブに表示されます。
- 指定した接尾辞が無効になります。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画にある Data で、削除する接尾辞を選択します。
選択した接尾辞と一緒に、その下にあるすべてのサブ接尾辞を削除する場合は、「この接尾辞とそのすべてのサブ接尾辞を削除する」を選択します。
- また、この接尾辞をマウスの右ボタンでクリックし、ポップアップメニューから「削除」を選択することもできます。
「OK」をクリックして、接尾辞を削除します。
- 選択した接尾辞だけを削除し、そのサブ接尾辞は残しておく場合は、「この接尾辞だけを削除する」を選択します。
- Console によって処理されている内容を示すダイアログボックスが表示されます。
データベースの作成と管理
接尾辞を作成してディレクトリデータを整理したあとで、ディレクトリデータを格納するためのデータベースを作成します。データベースは、ディレクトリデータを格納するために使用されます。ここでは、ディレクトリデータを格納するためのデータベースの作成、データベースの削除、および一時的にデータベースを読み取り専用にする方法について説明します。
データベースの作成
iPlanet Directory Server 5.1 では、複数のデータベースにわたって、ディレクトリツリーを分散させることができます。複数のデータベースにデータを分散させるには、次の 2 つの方法があります。
接尾辞 1 つにつき 1 つのデータベース
接尾辞 1 つに対して複数のデータベース
- 各接尾辞のデータは、別々のデータベースに格納されます。たとえば、次のようなディレクトリツリーがあるとします。
- ここで、それぞれの接尾辞に含まれるデータを格納するためのデータベースを、次のように 3 つ追加します。
- このようなツリーの分岐は、次の 3 つのデータベースに対応します。
- データベース 1 には ou=people のデータと dc=siroe,dc=com のデータが含まれるので、クライアントは dc=siroe,dc=com に基づいて検索を実行できます。データベース 2 には ou=groups のデータ、データベース 3 には ou=contractors のデータが含まれています。
- たとえば、ディレクトリツリーの ou=people 分岐にあるエントリの数が多すぎるので、これらのエントリを 2 つのデータベースに分けて格納するとします。この場合、ou=people に含まれるデータは、2 つのデータベースに分散されます。これを図に示すと次のようになります。
- データベース 1 には名前が A から K で始まる人、データベース 2 には L から Z で始まる人のデータが格納されます。データベース 3 には ou=groups のデータ、データベース 4 には ou=contractors のデータが含まれます。
- カスタム分散プラグインを使用して、1 つの接尾辞から複数のデータベースにデータを分散させる必要があります。使用している Directory Server 用に分散論理を作成する方法については、iPlanet プロフェッショナルサービスにお問い合わせください。プロフェッショナルサービスについては、http://www.iplanet.com/services/ を参照してください。
Console を使用した既存の接尾辞に対する新しいデータベースの作成
すでに作成されている接尾辞にデータベースを追加する手順は次のとおりです。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data を展開し、新しいデータベースの追加先となる接尾辞をクリックします。
この接尾辞をマウスの右ボタンでクリックし、ポップアップメニューから「新規データベース」を選択します。
「新規データベースの作成」ダイアログボックスで、データベースの一意の名前を入力します。
- 「新規データベースの作成」ダイアログボックスが表示されます。
「データベースの作成位置」フィールドに、新しいデータベースの格納先ディレクトリへのパスを入力します。「参照」をクリックすると、ローカルマシン上のディレクトリを検索できます。
- この値には、コンマ、タブ、等号 (=)、アスタリスク (*)、バックスラッシュ (\)、スラッシュ (/)、プラス記号 (+)、一重引用符 (')、二重引用符 (")、および疑問符 (?) は使用できません。たとえば、新しいデータベースに siroe2 という名前を付けることができます。
「OK」をクリックします。確認のダイアログボックスで「はい」をクリックして、新しいデータベースを作成します。
- デフォルトでは、新しいデータベースは、次のディレクトリに格納されます。
/var/ds5/slapd-serverID/db /usr/iplanet/servers/slapd-serverID/db
注 「ディレクトリ」タブに新しい接尾辞を表示するには、まず、この接尾辞に関連付けられたルートエントリを作成する必要があります。「ディレクトリエントリの作成」を参照してください。
コマンド行を使用した 1 つの接尾辞に対する新しいデータベースの作成
ldapmodify コマンド行ユーティリティを使用して、ディレクトリ構成ファイルに新しいデータベースを追加します。データベース構成情報は、cn=ldbm database,cn=plugins,cn=config エントリに格納されます。たとえば、サーバ siroe1 に新しいデータベースを追加するとします。次のように ldapmodify を実行して、構成ファイルに新しいエントリを追加します。
ldapmodify ユーティリティはサーバにバインドし、構成ファイルにエントリを追加する準備を行います。
- ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
次のように入力して、新しいデータベースにエントリを作成します。
dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix:ou=people,dc=siroe,dc=com追加されたエントリは、ルート接尾辞またはサブ接尾辞 ou=people,dc=siroe,dc=com のデータを含むデータベース UserData に対応します。
コマンド行からルート接尾辞やサブ接尾辞を作成する方法については、「コマンド行からのルート接尾辞およびサブ接尾辞の作成」を参照してください。DN 属性で指定されたデータベース名は、接尾辞エントリの nsslapd-backend 属性の値に対応する必要があります。
1 つの接尾辞に対する複数のデータベースの追加
複数のデータベース全体に、1 つの接尾辞を分散させることができます。ただし、接尾辞を分散させるには、カスタム分散関数を作成して、ディレクトリを展開する必要があります。カスタム分散関数の作成については、iPlanet プロフェッショナルサービスにお問い合わせください。プロフェッショナルサービスについては、http://www.iplanet.com/services/ を参照してください。
iPlanet プロフェッショナルサービスがカスタム分散論理プラグインの作成をお手伝いします。あとは、このプラグインをディレクトリに追加するだけです。次に、ディレクトリ内の接尾辞に分散論理を追加する手順について説明します。
接尾辞へのカスタム分散関数の追加
分散論理は、接尾辞で宣言される関数です。この関数は、この接尾辞の上から開始されるサブツリー検索操作など、この接尾辞に影響する操作すべてに関して呼び出されます。Console とコマンド行のどちらを使用しても、接尾辞に分散関数を挿入することができます。カスタム分散論理の作成については、iPlanet プロフェッショナルサービスにお問い合わせください。
Console を使用したカスタム分散の追加
Directory Server Console で、「構成」タブを選択します。
左側にあるナビゲーション区画の Data ツリーを展開します。分散関数の適用先となる接尾辞を選択します。
「追加」をクリックして、追加データベースと接尾辞を関連付けます。
「分散ライブラリ」フィールドに分散ライブラリへのパスを入力します。あるいは、「参照」をクリックして、ローカルマシン上の分散ライブラリを選択します。
コマンド行からのカスタム分散の追加
ldapmodify コマンド行ユーティリティを使用して、接尾辞エントリ自体に次の属性を追加します。nsslapd-backend: Database1
nsslapd-backend: Database2
nsslapd-backend: Database3
nsslapd-distribution-plugin: /full/name/of/a/shared/library
nsslapd-distribution-funct: distribution-function-namensslapd-backend 属性は、この接尾辞に関連付けられているすべてのデータベースを表します。また、nsslapd-distribution-plugin 属性は、プラグインで使用されるライブラリ名を表します。nsslapd-distribution-funct 属性は、分散関数自体の名前を表します。
ldapmodify コマンド行ユーティリティの使い方については、「ldapmodify を使用したエントリの追加と修正」を参照してください。
ディレクトリデータベースの管理
ここでは、ディレクトリデータベースの管理に関連する作業について、次の項目ごとに説明します。
データベースを読み取り専用モードへ設定
データベースが読み取り専用モードになっている場合、エントリの作成、変更、削除ができなくなります。たとえば、コンシューマを手作業で初期化する場合には、データベースを読み取り専用モードにしておく必要があります。Directory Server で複数のデータベースを管理している場合は、サーバ全体を読み取り専用モードにすると、すべてのデータベースを一度に読み取り専用モードにできます。詳細は、「Directory Server 全体を読み取り専用モードへ設定」を参照してください。
Console を使用したデータベースの読み取り専用モード設定
Server Console からデータベースを読み取り専用モードに設定するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data ツリーを展開します。読み取り専用モードにするデータベースが含まれる接尾辞を展開します。
コマンド行からのデータベースの読み取り専用設定
データベースを手作業で読み取り専用モードにする場合は、読み取り専用属性 nsslapd-readonly を on に変更する必要があります。この操作は、ldapmodify コマンド行ユーティリティを使用して行います。特定のデータベースの nsslapd-readonly 属性は cn=database_name,cn=ldbm database,cn=plugins,cn=configエントリにあります。ここで、database_name はデータベース名を表します。
データベースの削除
ここでは、Directory Server Console を使用してディレクトリデータベースを削除する手順について説明します。データベースを削除したときに削除されるのは、このデータベースの構成情報とエントリだけです。物理的なデータベース自体は削除されません。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画で削除するデータベースを選択します。
「はい」をクリックして、データベースの削除を確認します。
データベースリンクの作成と管理
連鎖は、サーバがクライアントアプリケーションに代わって別のサーバと通信し、結果の組み合わせを返す方法です。この方法は、データベースリンク (database link) を介して実装されます。データベースリンクは、リモートに格納されているデータをポイントします。クライアントアプリケーションにより、データベースリンクのデータが要求されると、このデータベースリンクがリモートデータベースからデータを取得し、クライアントに返します。ここでは、データベースの作成方法と設定方法について説明します。連鎖に関する全体的な説明については、 『iPlanet Directory Server 導入ガイド』の「ディレクトリトポロジの設計」を参照してください。
Directory Server Console やコマンド行を使用して、データベースリンクを作成および構成することができます。以降では、データベースリンクの作成および管理の手順について説明します。
「連鎖ポリシーの構成」
データベースリンクのアクティビティの監視については、「データベースリンクアクティビティの監視」を参照してください。
連鎖ポリシーの構成
ここでは、Directory Server が、クライアントアプリケーションからの要求を受け取り、データベースリンクを含む Directory Server に連鎖する方法の構成について説明します。この 連鎖 (chaining) ポリシーは、Directory Server に作成されたすべてのデータベースリンクに適用されます。
「コンポーネント操作の連鎖」
コンポーネント操作の連鎖
コンポーネントとは、内部処理を行うサーバ内の機能単位です。たとえば、プラグインはフロントエンドで機能するので、コンポーネントとみなされます。ただし、実際には、ACI プラグインのように、プラグインが複数のコンポーネントから構成されている場合があります。コンポーネントの中には、ローカルデータだけにアクセスするために、内部 LDAP 要求をサーバに送信するものもあります。このようなコンポーネントでは、コンポーネントが正常に操作を完了できるように、連鎖ポリシーを制御する必要があります。たとえば、証明書を確認する関数について考えてみます。証明書を検査するために、この関数からの LDAP 要求を連鎖する場合は、リモートサーバを信頼していることを暗示しています。リモートサーバを信頼していない場合は、セキュリティに問題があります。
デフォルトでは、すべての内部処理が連鎖されるわけではありません。ただし、Console やコマンド行を使用して連鎖するコンポーネントを指定することによって、このデフォルトに優先することができます。デフォルトでは、コンポーネントの連鎖は禁止されています。
また、指定したプラグインがリモートサーバで動作するように、リモートサーバで ACI を作成する必要もあります。この ACI は、データベースリンクに割り当てられた接尾辞 (suffix) で作成します。
次の表に、コンポーネント名、コンポーネントを内部操作に連鎖させたときに発生することのある不具合、およびリモートサーバに作成した ACI で必要な権限を示します。
このプラグインでは、アクセス制御機能が実装される。ローカル ACI 属性とリモート ACI 属性の混在は危険なので、ACI 属性を取得する操作と更新する操作は連鎖できない。ただし、ユーザエントリを検出する要求は連鎖可能 nsActiveChainingComponents 属性に次の値を指定する
nsActiveChainingComponents: cn=ACI
Plugin,cn=plugins,cn=configこのコンポーネント名は、Directory Server 4.0 プラグインすべてを表す。4.0 プラグインの連鎖ポリシーはすべて同じ。nsActiveChainingComponents 属性に次の値を指定する
nsActiveChainingComponents: cn=old
plugin,cn=plugins,cn=configこのコンポーネントは、ユーザのバインドした DN に応じて、サーバ制限を設定する。資源制限コンポーネントの連鎖が許可されている場合は、リモートユーザに資源制限を適用することができる。このコンポーネントの操作を連鎖させるには、次のように指定する
nsActiveChainingComponents: cn=resource
limits,cn=components,cn=configこのコンポーネントは、SASL 外部バインド方法とともに使用される。リモートサーバにあるデータベースからユーザ証明書を取得する。このコンポーネントを連鎖すると、証明書に基づく認証をデータベースリンクで行うことができる。このコンポーネントの操作を連鎖させるには、次のように指定する
nsActiveChainingComponents:
cn=certificate-based
authentication,cn=components,cn=configこのプラグインは、DN を含む属性が変更されると、その属性へのポインタを含むすべてのエントリでその変更が反映されることを保証する。たとえば、グループのメンバーであるエントリを削除すると、そのエントリは自動的にグループから削除される。連鎖でこのプラグインを使用すると、グループのメンバーが静的グループ定義に対してリモートであるときに、静的グループの管理が簡単になる。
このコンポーネントの操作を連鎖させるには、次のように指定する
nsActiveChainingComponents:
cn=referential integrity
postoperation,cn=plugins,cn=configこのプラグインでは、指定された uid 属性の値がすべて一意であるか、つまり重複する値がないかどうかが確認される。このプラグインを連鎖させると、データベースリンク経由で変更された属性でも、uid 属性値が一意であるかどうかが確認される。このコンポーネントの操作を連鎖させるには、次のように指定する
nsActiveChainingComponents:cn=uid
uniqueness,cn=plugins,cn=config
注 ACI および連鎖の制限については、「ACI の制限事項」を参照してください。
連鎖させるコンポーネントを変更したら、変更内容を有効にするためにサーバを再起動する必要があります。
次の節では、Console やコマンド行を使用して連鎖するコンポーネントを指定する方法について説明します。
Console を使用したコンポーネント操作の連鎖
コンポーネントを連鎖させたら、操作の連鎖先となるリモートサーバで接尾辞に ACI を作成する必要があります。たとえば、参照整合性プラグインのために、次の ACI を作成します。aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=siroe,dc=com")
(version 3.0; acl "RefInt Access for chaining"; allow
(read,write,search,compare) userdn = "ldap:///cn=referential
integrity postoperation,cn=plugins,cn=config";)
コマンド行からのコンポーネント操作の連鎖
構成ファイルの cn=config,cn=chaining database,cn=plugins,cn=config エントリにある nsActiveChainingComponents 属性を使用して、連鎖に含めるコンポーネントを指定することができます。たとえば、参照整合性プラグインを使用して操作を連鎖させる場合は、データベースリンク設定ファイルに次の行を追加します。
nsActiveChainingComponents:cn=referential integrity postoperation,
cn=components,cn=config連鎖できるコンポーネントのリストについては、表 3-2を参照してください。
nsActiveChainingComponents 属性を修正したら、変更内容を有効にするためにサーバを再起動する必要があります。
コンポーネントを連鎖させたら、操作の連鎖先となるリモートサーバで接尾辞に ACI を作成する必要があります。たとえば、参照整合性コンポーネントのために、次の ACI を作成します。
aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=siroe,dc=com")
(version 3.0; acl "RefInt Access for chaining"; allow
(read,write,search,compare) userdn = "ldap:///cn=referential
integrity postoperation,cn=plugins,cn=config";)
LDAP 制御の連鎖
LDAP 制御による操作要求は、連鎖させないように指定することができます。デフォルトでは、次の制御による要求は、データベースリンクによってリモートサーバに転送されます。
管理 DSA : この制御は、レフェラルに従わないで、スマートレフェラルをエントリとして返します。スマートレフェラル自体を変更または削除できます。
次の節では、Console やコマンド行を使用して、データベースリンクが転送する制御を変更する方法について説明します。ループの検出 : この制御は、あるサーバが別のサーバと連鎖する回数を記録します。この回数が設定した値に達すると、ループが検出され、クライアントアプリケーションに通知されます。
サーバ側ソート : この制御は、属性値に従ってエントリをソートします。
- この制御の使い方については、「ループの検出」を参照してください。
VLV (仮想リスト表示) : この制御は、検索結果としてすべてのエントリ情報を一度に返すのではなく、部分的な結果リストを提供します。
注 サーバ側ソート制御と VLV 制御は、検索範囲が 1 つのデータベースである場合にのみ、連鎖を介してサポートされます。クライアントアプリケーションからの要求が複数のデータベースに対して行われた場合は、データベースリンクでは、VLV 制御はサポートされません。
Console を使用した LDAP 制御の連鎖
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data フォルダを展開し、「データベースリンクの設定」をクリックします。
右側のウィンドウで「設定」タブを選択します。リストに LDAP 制御を追加するには、「追加」をクリックします。
リストから制御を削除するには、該当する制御を「リモートサーバに転送された LDAP 制御」リストから選択し、「削除」をクリックします。
コンポーネントリストを修正すると、タブに赤い点が表示され、コンポーネントのフィールド名がグレーに変わります。「保存」をクリックして、変更内容を保存します。
コマンド行からの LDAP 制御の連鎖
データベースリンクによって転送される制御を変更するには、cn=config,cn=chaining database, cn=plugins,cn=config エントリの nsTransmittedControls 属性を変更します。たとえば、VLV 制御を転送するには、構成ファイルのデータベースリンクエントリに、次の行を追加します。nsTransmittedControls: 2.16.840.1.113730.3.4.9
さらに、Directory Server のクライアントによって、独自の制御が作成されているときに、これらの処理をリモートサーバに連鎖させる必要がある場合は、カスタム制御の OID を nsTransmittedControls 属性に追加する必要があります。
次の表に、連鎖可能な LDAP 制御と、その OID を示します。
LDAP 制御については、http://docs.iplanet.com/docs/manuals/directory.html にある LDAP C-SDK に関するドキュメントを参照してください。
新しいデータベースリンクの作成
データベースリンクの基本構成には、次の情報が必要です。接尾辞情報 :ディレクトリツリーに、通常のデータベースではなく、データベースリンクによって管理される接尾辞を作成します。この接尾辞は、データが含まれるリモートサーバの接尾辞に対応します。
バインド資格 :データベースリンクがリモートサーバにバインドするときに、データベースリンクはユーザであるかのように動作します。リモートサーバへのバインド操作のために、データベースリンクで使用される DN と資格を指定する必要があります。
LDAP URL :データベースリンクの接続先リモートサーバの LDAP URL を指定します。
フェイルオーバサーバのリスト :不具合が発生したときに、データベースリンクの接続先となる代替サーバのリストを指定できます。この構成項目は省略可能です。
次の節では、Directory Server Console およびコマンド行から新しいデータベースリンクを作成する方法について説明します。
Console を使用した新しいデータベースリンクの作成
Directory Server Console を使用して新しいデータベースリンクを作成するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画で Data をマウスの右ボタンでクリックし、ポップアップメニューから「新規ルート接尾辞」または「新規サブ接尾辞」を選択します。
「新規接尾辞」フィールドに、連鎖先となるリモートサーバの接尾辞名を入力します。
「関連するデータベースの自動作成」チェックボックスの選択を解除します。
「OK」をクリックして、新しい接尾辞を作成します。
左側の区画で、作成した接尾辞をマウスの右ボタンでクリックし、ポップアップメニューから「新規データベースリンク」を選択します。
「データベースリンク名」フィールドに新しいデータベースリンク名を入力します。
「バインド DN」フィールドに、データベースリンクがリモートサーバにバインドするときに使用する DN を入力します。
- データベースリンクに名前を付ける場合に使用できる文字は、ASCII (7 ビット) 文字だけです。この値には、コンマ、タブ、等号 (=)、アスタリスク (*)、バックスラッシュ (\)、スラッシュ (/)、プラス記号 (+)、一重引用符 (')、二重引用符 (")、および疑問符 (?) は使用できません。たとえば、新しいデータベースリンクに siroelink1 という名前を付けることができます。
「パスワード」フィールドに、データベースリンクがリモートサーバにバインドするときに使用するパスワードを入力します。
データベースリンクで、リモートサーバとの通信に SSL を使用する場合は、「サーバ間のセキュリティ保護された LDAP 接続を使用する」チェックボックスを選択します。
「リモートサーバ」フィールドにリモートサーバ名を入力します。バインドに使用するサーバのポート番号を、「リモートサーバのポート」フィールドに入力します。デフォルトは 389 です。
フェイルオーバサーバの名前を「サーバをフェイルオーバする」フィールドに入力し、ポート番号を「ポート」フィールドに指定します。デフォルトは 389 です。「追加」をクリックすると、フェイルオーバサーバがリストに追加されます。
「OK」をクリックして、新しいデータベースリンクを作成します。データベースリンクの作成が終了したことを示すダイアログボックスが表示されたら、「OK」をクリックしてこのダイアログボックスを閉じます。
- この項目には、複数のフェイルオーバサーバを指定することができます。プライマリリモートサーバで不具合が発生した場合は、データベースリンクは「フェイルオーバサーバ」リストの最初のサーバに接続します。このサーバにも接続できない場合、リスト上のサーバに対して、リストの上から順番に接続していきます。
コマンド行からのデータベースリンクの作成
ldapmodify コマンド行ユーティリティを使用して、コマンド行から新しいデータベースリンクを作成します。新しいインスタンスは、cn=chaining database,cn=plugins, cn=config エントリにある必要があります。
デフォルトの構成属性は、cn=default config, cn=chaining database,cn=plugins,cn=config エントリに含まれています。これらの構成属性は、すべてのデータベースリンクに対して、作成時に適用されます。デフォルト構成に対する変更は、新しく作成されるデータベースリンクだけに反映されます。既存のデータベースリンクにあるデフォルトの構成属性を変更することはできません。
データベースリンクにはそれぞれ、独自の構成情報が含まれています。この情報は、cn=database_link_name,cn=chaining database,cn=plugins,cn=config のようなデータベースリンクエントリ自体に格納されています。構成属性については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。
ここでは、コマンド行からデータベースリンクを構成する次の手順について説明します。
接尾辞情報の指定
データベースリンクで管理される接尾辞を定義するには、nsslapd-suffix 属性を使用します。たとえば、社内のリモートサイトにある people の情報をポイントするデータベースリンクが必要な場合は、次の接尾辞情報を入力します。nsslapd-suffix: l=Zanzibar,ou=people,dc=siroe,dc=com
接尾辞情報は、cn=database_link_name,cn=chaining database,cn=plugins,cn=config エントリに格納されます。
注 nsslapd-suffix 属性の作成後にこの属性に加えた変更を有効にするには、データベースリンクを含むサーバの再起動が必要です。
バインド資格の指定
リモートサーバに連鎖されるクライアントアプリケーションからの要求については、クライアントアプリケーションに対して特別なバインド資格を指定する必要があります。この指定によって、操作を連鎖させるために必要なプロキシ認証権限がリモートサーバに与えられます。バインド資格を指定しない場合は、データベースリンクは匿名でリモートサーバにバインドします。
リモートサーバで、次の手順を実行します。
たとえば、クライアントアプリケーションがサーバ A に要求を送信するとします。サーバ A には、サーバ B にあるデータベースに対して要求を連鎖するデータベースリンクが含まれています。
データベースリンクの管理ユーザを作成します。
データベースリンクが含まれるサーバで、次の手順を実行します。
データベースリンクによって連鎖されたサブツリーで、手順 1-a で作成した管理ユーザにプロキシ権限を指定します。
- エントリの追加については、「ディレクトリエントリの作成」を参照してください。
- ACI の構成については、「アクセス制御の管理」を参照してください。
サーバ A のデータベースリンクが、nsMultiplexorBindDN 属性で定義された特別なユーザと、nsMultiplexorCredentials 属性で定義されたユーザパスワードを使用して、サーバ B にバインドします。この例でサーバ A が使用するバインド資格は次のとおりです。
nsMultiplexorBindDN: cn=proxy admin,cn=config
nsMultiplexorCredentials: secret
サーバ B には nsMultiplexorBindDN に対応するユーザエントリが必要であり、このユーザに対してプロキシ認証権限を設定する必要があります。プロキシ認証権限を設定するには、ほかの ACI と同様、「プロキシ」ACI を設定する必要があります。
ACI については、「アクセス制御の管理」を参照してください。プロキシ認証制御については、http://developer.iplanet.com/docs/manuals/directory.html にある C-SDK に関するマニュアルを参照してください。
注 クライアントアプリケーションからデータベースリンクを使用して、エントリの作成や変更をした場合、属性 creatorsName と modifiersName には、エントリを実際に作成または変更したユーザの識別名は反映されません。これらの属性には、リモートデータサーバでのプロキシ認証権限を持つ管理者名が反映されます。
LDAP URL の指定
データベースリンクを含むサーバで、このデータベースリンクが LDAP URL を使用して接続するリモートサーバを識別する必要があります。標準の LDAP URL 形式とは異なり、リモートサーバの URL では、接尾辞は指定されません。この形式は次のようになります。リモートサーバの URL を指定するには、設定ファイルの cn=database_link_name,cn=chaining database,cn=plugins,cn=config エントリの nsFarmServerURL 属性を使用します。たとえば、nsFarmServerURL は次のようになります。
nsFarmServerURL: ldap://siroe.com:389/
URL の末尾には必ずスラッシュ (/) を付けてください。
SSL を介して LDAP を使用することによって、データベースリンクをリモートサーバに接続させる場合は、リモートサーバの LDAP URL は次の形式になります。
ldaps://servername:portnumber/
連鎖と SSL については、「SSL を使用した連鎖」を参照してください。
フェイルオーバサーバのリストの指定
障害の発生に備えて、サーバに対して LDAP URL を追加で指定することができます。このためには、nsFarmServerURL 属性に代替サーバを追加します。代替サーバ間はスペースで区切ります。たとえば、次のように入力します。nsFarmServerURL: ldap://siroe.com us.siroe.com:389 africa.siroe.com:1000/
この LDAP URL の例では、データベースリンクは、まず操作をサービスする siroe.com 標準ポートにあるサーバに接続します。このサーバが応答しない場合は、ポート 389 にあるサーバ us.siroe.com に接続します。これにも失敗した場合は、ポート 1000 にあるサーバ africa.siroe.com に接続します。
データベースリンク構成属性のまとめ
次の表に、データベースリンクの構成で使用可能な属性を示します。これらの属性の一部については、これまでの節で説明しました。アスタリスク (*) が付いている属性は、グローバル属性およびインスタンス属性の両方にすることができます。インスタンス属性はすべて、cn=database_link_name,cn=chaining database,cn=plugins,cn=config エントリで定義されています。
2 つのグローバル構成属性は、cn=config,cn=chaining database,cn=plugins,cn=config エントリにあります。グローバル属性は動的です。つまり、グローバル属性を変更すると、ディレクトリにあるデータベースリンクのすべてのインスタンスが、自動的に変更されます。
特定のデータベースリンクについて定義された値は、グローバル属性値よりも優先します。
データベースリンクによって管理される接尾辞。エントリの作成後にこの属性に加えた変更を有効にするには、データベースリンクを含むサーバの再起動が必要
データを含むリモートサーバ (ファームサーバ) の LDAP URL。この属性には、フェイルオーバ用のオプションサーバを、スペースで区切って指定することができます。カスケード型連鎖を使用している場合は、この URL で別のデータベースリンクをポイントできる。
リモートサーバとの通信に使用される管理エントリの DN。属性名にある multiplexor (マルチプレクサ) という単語は、データベースリンクを含み、リモートサーバと通信するサーバを意味する。
このバインド DN にディレクトリマネージャを指定することはできない。この属性が指定されていない場合は、データベースリンクは匿名でバインドする。
管理ユーザ用パスワードを、プレーンテキストで指定します。パスワードが指定されていない場合は、ユーザは匿名でバインドできる。パスワードは構成ファイルで暗号化される
拡張機能のために予約されています。リモートデータサーバと同様に、データベースリンクでも ACI が評価されるかどうかを制御します。値として、on または off を指定できる。
拡張機能のために予約されています。プロキシ認証を無効にすることができる。値が off の場合は、プロキシ認証が無効であることを示す。デフォルト値は on
連鎖を使用するコンポーネントのリスト。コンポーネントとは、サーバ内の機能単位を指す。データベースリンクインスタンスにおけるこの属性値は、グローバル構成属性よりも優先する。特定のデータベースインスタンスで連鎖を無効にするには、値 none を使用する。
デフォルトのポリシーでは、連鎖は禁止。詳細は、「コンポーネント操作の連鎖」を参照
範囲検索でレフェラルが返されるかどうかを制御する。範囲検索に対してレフェラルを返す方が効率的なため、この属性はディレクトリを最適化するために使用される。値として、on または off を指定できる。デフォルト値は off
データベースリンク構成例
たとえば、us.siroe.com ドメイン内のサーバにあるデータベースに、サブツリー l=Walla Walla,ou=people,dc=siroe,dc=com があるとします。このとき l=Zanzibar,ou=people,dc=siroe,dc=com に対する操作要求を、 africa.siroe.com ドメインにある別のサーバに連鎖させるとします。この操作を図に示すと、次のようになります。
はじめに ldapmodify コマンド行ユーティリティを使用してデータベースリンクをサーバ A に追加します。次のユーティリティを含むディレクトリに移動します。
% cd /usr/iplanet/ds5/shared/bin % cd installDir/shared/bin ldapmodify -a -h us.siroe.com -p port \
-D "cn=Directory Manager" -w passworddn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: l=Zanzibar,ou=people,dc=siroe,dc=com
nsfarmserverurl: ldap://africa.siroe.com:389/
nsmultiplexorbinddn: cn=proxy admin,cn=config
nsmultiplexorcredentials: secret
cn: DBLink1dn: cn="l=Zanzibar,ou=people,dc=siroe,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend:DBLink1
nsslapd-parent-suffix: "ou=people,dc=siroe,dc=com"
cn: l=Zanzibar,ou=people,dc=siroe,dc=com最初のセクションでは、 nsslapd-suffix 属性に、サーバ A からの連鎖先であるサーバ B にある接尾辞が含まれています。nsFarmServerURL 属性には、サーバ B の LDAP URL が含まれています。
2 番目のセクションでは新しい接尾辞が作成されるので、サーバが新しいデータベースリンクに対する要求を送信できるようになります。cn 属性には、データベースリンクの nssalpd-suffix 属性で指定されているのと同じ接尾辞が含まれています。nsslapd-backend 属性には、データベースリンク名が含まれています。nsslapd-parent-suffix 属性は、この新しい接尾辞の親 ou=people,dc=siroe,dc=com を表します。
dn: cn=proxy admin,cn=config
objectclass:person
objectclass: organizationalPerson
objectclass:inetOrgPerson
cn: proxy admin
sn: proxy admin
userPassword: secret
description: Entry for use by database links
リモートサーバのプロキシ管理ユーザには、ディレクトリマネージャのユーザを使用しないでください。ディレクトリマネージャのユーザを使用すると、セキュリティホールが発生します。
次のプロキシ認証 ACI を、サーバ B の l=Zanzibar,
ou=people,dc=siroe,dc=com エントリに追加します。aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";)
この ACI によって、プロキシ管理ユーザに対して、l=Zanzibar,ou=people,dc=siroe,dc=com サブツリー内のみにあるリモートサーバに含まれるデータへの読み取り専用アクセス権が与えられます。
注 ユーザがデータベースリンクにバインドすると、ユーザの ID がリモートサーバに送られます。ここでのアクセス制御は、常にリモートサーバで評価されます。ユーザが正常にリモートサーバのデータを修正したり、リモートサーバにデータを書き込んだりできるようにするには、リモートサーバに正確なアクセス制御を設定する必要があります。
連鎖操作のコンテキストでアクセス制御がどのように評価されるかについては、「データベースリンクとアクセス制御の評価」を参照してください。
SSL を使用した連鎖
SSL を使用して、リモートサーバと通信するようにデータベースリンクを構成することができます。SSL を使用した連鎖は、次のステップで行います。
リモートサーバで、SSL を有効にする
データベースリンクとリモートサーバに対して SSL を使用して通信するように設定しても、操作を要求しているクライアントアプリケーションは、必ずしも SSL を使用して通信する必要はありません。クライアントは、通常のポートを使用してバインドすることもできます。
リモートサーバの LDAP URL を SSL 形式で指定する
- SSL の有効化については、「SSL の有効化 : 手順の概要」を参照してください。
データベースリンクが含まれるサーバで SSL を有効にする
- nsFarmServerURL 属性に LDAP URL を指定します。この属性については、「LDAP URL の指定」を参照してください。
- たとえば、次のように LDAP URL を指定します。
- nsFarmServerURL: ldaps://africa.siroe.com:636/
- SSL の有効化については、「SSL の有効化 : 手順の概要」を参照してください。
データベースリンクの管理
ここでは、既存のデータベースリンクの更新方法と削除方法について説明します。次の手順ごとに説明します。
「リモートサーバ認証情報の更新」
リモートサーバ認証情報の更新
リモートサーバに接続するためにデータベースリンクで使用されるバインド DN とパスワードを更新するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画で Data を展開し、該当する接尾辞の更新対象のデータベースリンクを特定して選択します。
リモートサーバ情報を更新するには、「リモートサーバの URL」フィールドに新しい LDAP URL を入力します。
「データベースリンクのバインド DN」フィールドに新しい DN を入力して、リモートサーバにバインドするのにデータベースリンクで使用されるバインド DN を更新します。
- 標準の LDAP URL 形式とは異なり、リモートサーバの URL では、接尾辞は指定されません。この形式は次のようになります。
- ldap://servername:portnumber/
「データベースリンクのパスワード」フィールドに新しいパスワードを入力して、リモートサーバにバインドするのにデータベースリンクで使用されるパスワードを更新します。確認のため、「データベースリンクパスワードの確認」フィールドに同じパスワードを入力します。
「保存」をクリックして、変更内容を保存します。
- 「リモートサーバのチェックリスト」ボックスに、データベースリンクが正常にバインドするためにリモートサーバで必要とされる管理ユーザエントリ、接尾辞、および ACI が一覧表示されます。
データベースリンクの削除
データベースリンクを削除するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側のナビゲーション区画で、削除するデータベースリンクを選択します。
「はい」をクリックして、データベースリンクの削除を確認します。
- また、このデータベースリンクをマウスの右ボタンでクリックし、ポップアップメニューから「削除」を選択することもできます。
- 「データベースリンクの削除」の確認ダイアログボックスが表示されます。
- 削除中に、Directory Server がどのような処理を実行しているかが、ダイアログボックスに表示されます。
- 一度削除されたデータベースリンクは、右側の区画には表示されなくなります。
データベースリンクとアクセス制御の評価
ユーザがデータベースリンクを含むサーバにバインドすると、データベースリンクによって、ユーザの ID がリモートサーバに送られます。ここでのアクセス制御は、常にリモートサーバで評価されます。リモートサーバで評価される LDAP 操作では、プロキシ認証制御を介して渡されたクライアントアプリケーションのオリジナル ID が使用されます。ユーザが、リモートサーバに含まれるサブツリーに対して正しいアクセス制御を持っている場合にだけ、リモートサーバで操作が成功します。つまり、リモートサーバには、通常のアクセス制御を追加しておく必要があります。これには次のような制約があります。
すべてのタイプのアクセス制御を使用できるとは限らない
データベースリンクとともに使用するために作成する ACI には、次の制約があります。
クライアントのオリジナルドメインが連鎖中に失われるので、クライアントの IP アドレスや DNS ドメインに基づくアクセス制御の一部が動作しないことがある。
- たとえば、ロールベースの ACI やフィルタベースの ACI では、ユーザエントリへのアクセス権が必要です。データベースリンクを介してデータにアクセスしているので、プロキシ制御にあるデータだけが検証されます。つまり、ユーザエントリがユーザのデータと同じデータベースに必ず置かれるように、ディレクトリを設計しておく必要があります。
- リモートサーバからは、クライアントアプリケーションはデータベースリンクと同じ IP アドレスにあり、同じ DNS ドメインに存在するものとみなされます。
ACI は、ACI が使用するグループと同じ場所にある必要がある。これらのグループが動的である場合は、グループのすべてのユーザが、ACI および ACI が使用するグループと同じ場所にある必要がある。静的グループの場合は、リモートユーザが参照される場合がある。
アクセス制御は常にリモートサーバで評価されますが、データベースリンクを含むサーバとリモートサーバの両方でアクセス制御が評価されるように選択することもできます。これにはいくつかの制約があります。ACI は、使用する ロール (role) 定義、およびこれらのロールを持つ予定のユーザと同じ場所に存在する必要がある。
ユーザのエントリ値を参照する ACI (たとえば、userattr サブジェクト規則) は、ユーザがリモートの場合に機能する。
アクセス制御の評価中に、ユーザエントリのコンテンツが使用できるとは限らない (データベースリンクが含まれるサーバでアクセス制御が評価され、エントリがリモートサーバにある場合など)。
クライアントアプリケーションによって修正されているエントリへのアクセス権がデータベースリンクにあるとは限らない。
- 性能上の理由から、クライアントがリモート問い合わせやアクセス制御の評価を行うことはできません。
- 修正操作を実行するときに、リモートサーバに格納されているすべてのエントリへのアクセス権が、データベースリンクにあるとは限りません。削除操作を実行する場合は、データベースリンクが認識しているのはエントリの DN だけです。アクセス制御で特定の属性が指定されている場合は、データベースリンクを介して削除操作を実行すると失敗します。
拡張機能 : データベースリンクの性能の調整
ここでは、接続とスレッド管理によって、データベースリンクの性能を調節する方法について、次の項目ごとに説明します。
「リモートサーバへの接続の管理」
リモートサーバへの接続の管理
各データベースリンクは、リモートサーバへの接続のプールを維持します。使用しているディレクトリで資源が最適化されるように、接続を構成することができます。Directory Server Console やコマンド行を使用して、接続属性を変更することができます。
Console を使用したリモートサーバへの接続の管理
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data フォルダを展開し、変更の対象となるデータベースリンクを特定します。このデータベースリンクをクリックして、右側のナビゲーション区画で「制限と制御」タブをクリックします。
「保存」をクリックして、変更内容を保存します。
- 最大 TCP 接続数 :データベースリンクがリモートサーバとの間で確立する TCP 接続の最大数。デフォルトは 3 です。
- バインドタイムアウト : データベースリンクのバインド処理の試行がタイムアウトになるまでの時間 (秒)。デフォルトは 15 秒です。
- 接続ごとの最大バインド数 :TCP 接続ごとの未処理のバインド処理の最大数を指定します。デフォルト値は、接続ごとに 10です。
- 中断までのタイムアウト時間 (秒) :サーバがタイムアウトされた接続を放棄するかどうかを確認するまでの秒数。デフォルトは 2 秒です。
- 最大 LDAP 接続数 :データベースリンクがリモートサーバとの間で確立する LDAP 接続の最大数。デフォルトは 10 です。
- 最大バインド再試行数 :データベースリンクがリモートサーバとのバインドを試行する回数。「0」を指定すると、データベースリンクによって 1 回だけバインドが試行される。デフォルトは 3 です。
- 接続ごとの最大操作数 :LDAP 接続ごとの未処理操作の最大数。デフォルト値は 1 接続あたり 10です。
- 接続継続時間 (秒) :データベースリンクとリモートサーバの間の、継続した接続時間の制限。データベースリンクとリモートサーバの間の接続を無制限に開いたままにしておくことも、あるいは特定の時間が経過したら接続を閉じることもできます。
- 接続したままにすると、処理は速くなりますが、資源が多く使用されます。特に、ダイヤルアップ接続を使用している場合は、接続時間を制限する必要がある。
- 「0」は、時間制限を設けないことを示す。デフォルトは 0 です。
コマンド行からのリモートサーバへの接続の管理
ldapmodify を使用して、データベースリンクエントリに接続属性を追加します。デフォルトの接続管理属性は、エントリ cn=default instance config, cn=chaining database,cn=plugins,cn=config に格納されます。
特定のデータベースリンクで使用される接続管理属性は、エントリ cn=database_link_name,cn=chaining database,cn=plugins,cn=config に格納されます。ここで、database_link_name はデータベースリンク名です。このエントリで指定された接続管理属性は、cn=default instance config エントリで指定された属性よりも優先します。
データベースリンク構成属性のリストについては、「データベースリンク構成の属性」を参照してください。
標準処理時のエラーの検出
データベースリンクとリモートサーバの間で、標準の連鎖処理が行われている間にエラーを検出できると、サーバの性能の保護が容易になります。データベースリンクには 2 つの属性があり、それらを組み合わせて、リモートサーバが応答しなくなったかどうかが判断されます。1 つめの属性は nsMaxResponseDelay で、LDAP 操作が完了するまでの最高持続時間を設定します。操作時間がこの属性に指定された時間数を超えると、データベースリンクのサーバでは、リモートサーバがオンラインの状態ではないと認識します。
nsMaxResponseDelay で設定された時間が経過すると、データベースリンクは、リモートサーバに対して ping を実行します。この ping の間、データベースリンクは別の LDAP 要求 (このリモートサーバに存在しないオブジェクトの検索要求) を発行します。ping の持続期間を設定するには、nsMaxTestResponseDelay を使用します。
nsMaxResponseDelay 期間が終了する前に、リモートサーバが応答しなくなった場合は、エラーが返され、接続が切断されたことを示すフラグが立ちます。このとき、サーバの性能が低下しないように、データベースリンクとリモートサーバの間のすべての接続は、30 秒間ブロックされます。30 秒が経過すると、データベースリンクからリモートサーバに対する操作要求は、通常どおりに続けられます。
どちらの属性も cn=config,cn=chaining database,cn=plugins,cn=config エントリに格納されます。次の表に、これらの属性を詳しく説明します。
スレッド操作の管理
一般に、Directory Server では、各操作の処理のために、限られた数のスレッドを使い最高の効率で働きます。スレッドの数を制限していることによって、一般的な操作を、高速に処理することができるため、キューの中で空きスレッドを待つ時間が長くなりすぎるのを防止できます。ただし、データベースリンクはリモートサーバが処理できるよう、操作を転送します。データベースリンクはリモートサーバに接続し、操作を転送して、結果を待ってから、この結果をクライアントアプリケーションに戻します。この操作全体では、ローカル操作と比較してかなり長く時間がかかることがあります。
リモートサーバからの結果を待っている間、データベースリンクは追加の操作を処理することができます。デフォルトでは、サーバが使用できるスレッド数は 20 です。ただし、データベースリンクを使用する場合は、操作の処理で使用可能なスレッドの数を増やすことによって、性能を向上させることができます。リモートサーバからの応答を待っている間、ローカル CPU をアイドル状態で待機させるのではなく、ほかの操作を処理させることができます。
操作の処理で使用されるスレッド数を変更するには、cn=config エントリの nsslapd-threadnumber グローバル構成属性を変更します。デフォルトのスレッド数は 20 です。たとえば、性能向上のために、スレッド数を 50 に増やすことができます。スレッド数を変更したら、サーバを再起動して、変更を反映させます。
拡張機能 : カスケード型連鎖の構成
あるデータベースリンクが別のデータベースリンクをポイントするよう構成して、カスケード型連鎖の操作を作成できます。ディレクトリツリーの全データにアクセスするために、複数のホップが必要な場合、カスケード型連鎖が発生します。
カスケード型連鎖の概要
カスケード型連鎖は、クライアントアプリケーションからの要求を処理するために、ディレクトリで複数のホップが必要な場合に発生します。
クライアントアプリケーションはサーバ 1 に修正要求を送信します。サーバ 1 には、サーバ 2 に操作を転送するためのデータベースリンクが含まれています。さらに、サーバ 2 には別のデータベースリンクがあります。サーバ 2 のデータベースリンクは操作をサーバ 3 に転送します。サーバ 3 にあるデータベースには、クライアントによる修正の対象となるデータが格納されています。このクライアントが修正するデータにアクセスするには、2 回のホップが必要です。
標準の操作要求時に、クライアントはサーバにバインドし、このクライアントに適用されている ACI がすべて評価されます。カスケード型連鎖を使用すると、クライアントのバインド要求はサーバ 1 で評価されますが、クライアントに適用されている ACI は、要求が目的のサーバ (上記の例ではサーバ 2) に連鎖されたときに初めて評価されます。
次のような例を想定します。サーバ A では、ディレクトリツリーは次のように分割されています。
ルート接尾辞 dc=siroe,dc=com、サブ接尾辞 ou=people と ou=groups はサーバ A に格納されています。l=europe,dc=siroe,dc=com および ou=groups 接尾辞は、サーバ B に格納され、l=europe,dc=siroe,dc=com 接尾辞の ou=people 分岐は、サーバ C に格納されています。
ここで、サーバ A、B、C に設定されたカスケード型連鎖を使用すると、ou=people,l=europe,dc=siroe,dc=com エントリをターゲットとするクライアント要求は、ディレクトリによって次のようにルーティングされます。
まず、クライアントがサーバ A にバインドし、データベースリンク 1 を使用してサーバ B に連鎖します。次に、サーバ B はデータベースリンク 2 を使用して ou=people,l=europe,dc=siroe,dc=com 分岐のデータにアクセスするために、サーバ C 上のターゲットデータベースに連鎖します。ディレクトリがクライアント要求を実行するには、少なくとも 2 回のホップが必要なので、この場合もカスケード型連鎖とみなされます。
Console を使用したカスケード型連鎖のデフォルト構成
Directory Server で、すべてのデータベースリンクを対象とするカスケード型連鎖のデフォルト値を作成するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data フォルダを展開し、「データベースリンクの設定」をクリックします。「デフォルト作成パラメタ」タブをクリックします。
カスケード型連鎖に関連する中間データベースリンクにあるローカル ACI の評価を有効にするには、「ローカル ACI をチェックする」チェックボックスを選択します。このチェックボックスを選択する場合は、中間データベースリンクが含まれるサーバのデータベースに適切なローカル ACI を追加する必要があります。
このデータベースリンクが別のデータベースリンクをポイントできる回数の最大値を、「最大ホップ」フィールドに入力します。
- これは拡張機能です。詳細は、「ローカル ACI の評価の有効化」を参照してください。
「保存」をクリックして、変更内容を保存します。
注 データベースリンクのデフォルト設定に対する変更は、過去にさかのぼって適用されることはありません。デフォルト設定への変更を保存したあとに作成されたデータベースリンクだけで、変更が反映されます。
Console を使用したカスケード型連鎖の構成
特定のデータベースリンクに対するカスケード型連鎖を設定するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data フォルダを展開し、カスケード型連鎖に含めるデータベースリンクを特定します。このデータベースリンクをクリックして、右側のナビゲーション区画で「制限と制御」タブをクリックします。
カスケード型連鎖に関連する中間データベースリンクにあるローカル ACI の評価を有効にするには、「ローカル ACI をチェックする」チェックボックスを選択します。このチェックボックスを選択する場合には、データベースリンクに適切なローカル ACI を追加しておく必要があります。
このデータベースリンクが別のデータベースリンクをポイントできる回数の最大値を、「最大ホップ」フィールドに入力します。
- これは拡張機能です。詳細は、「ローカル ACI の評価の有効化」を参照してください。
「保存」をクリックして、変更内容を保存します。
コマンド行からのカスケード型連鎖の構成
コマンド行を使用したデータベース連鎖の構成は、次のステップで行います。ここでは、次の項目について説明します。
「ほかのデータベースリンクへのポイント」
ほかのデータベースリンクへのポイント
カスケード型連鎖を作成するには、あるデータベースリンクの nsFarmServerURL 属性に、別のデータベースリンクを含むサーバの URL を含める必要があります。たとえば、サーバ siroe1.com にあるデータベースリンクに、africa.siroe.com というサーバにあるデータベースリンクへのポイントを設定するとします。サーバ 1 にあるデータベースリンクの cn=database_link_name,cn=chaining database, cn=plugins,cn=config エントリの内容は、次のようになります。nsFarmServerURL: ldap://africa.siroe.com:389
プロキシ認証制御の送信
デフォルトでは、データベースリンクはプロキシ認証制御を送信しません。ただし、データベースリンクが別のデータベースリンクに接続するときには、この制御を使用して、最終連鎖先サーバで必要となる情報を送信することができます。中間データベースリンクもまた、この制御を送信する必要があります。プロキシ認証制御が送信されるようにデータベースリンクを構成するには、中間データベースリンクの cn=config,cn=chaining database,cn=plugins,cn=config エントリに次の行を追加します。nsTransmittedControls: 2.16.840.1.113730.3.4.12
OID 値はプロキシ認証制御を表します。LDAP 制御の連鎖については、「LDAP 制御の連鎖」を参照してください。
プロキシ管理ユーザ ACI の作成
中間データベースリンクを含むサーバでは、次のサーバにリンクが転送される前に、最初のデータベースリンクの権限を確認するための ACI を作成する必要があります。これは、サーバ 2 でサーバ 1 の資格が確認されない場合、誰でも匿名でバインドすれば、プロキシ認証制御を通過することができるので、必要以上の管理権限が付与されれてしまう可能性があるためです。このようなセキュリティホールの発生を防ぐには、中間データベースリンクを含むサーバ上に ACI を作成しておく必要があります。ACI を作成するには、次の手順を実行します。
中間データベースリンクを含むサーバにデータベースが存在しない場合は、これを作成します。このデータベースには、管理ユーザエントリと ACI が含まれます。データベースの作成については、「データベースの作成」を参照してください。
適切な接尾辞をターゲットにする管理ユーザ用の ACI を作成します。これによって、管理者はこのデータベースリンクの接尾辞だけにアクセスできるようになります。管理ユーザエントリに、次の ACI を追加します。
- aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";)
- この ACI は、単純な連鎖を構成するときにリモートサーバで作成する ACI に似ています。
ローカル ACI の評価の有効化
プロキシ管理 ACI を常に確認するには、連鎖に関連するすべての中間データベースリンクで、ローカル ACI の評価を有効にする必要があります。このためには、すべての中間データベースリンクの cn=database_link_name,cn=chaining database,cn=plugins,cn=config エントリに、次の属性を追加します。cn=default instance config,cn=chaining database,cn=plugins,cn=config エントリでこの属性を on にすると、すべてのデータベースリンクインスタンスでその cn=database_link_name,cn=chaining database,cn=plugins,cn=config エントリの nsCheckLocalACI 属性が on に設定されます。
クライアント ACI の作成
ローカル ACI の評価を有効にしたので、中間データベースリンクと最終連鎖先データベースの両方に、適切なクライアントアプリケーション ACI を作成する必要があります。中間データベースリンクに ACI を作成するには、まず最終連鎖先接尾辞のルート接尾辞を表す接尾辞を含むデータベースを作成します。
たとえば、リモートサーバの c=africa,ou=people,dc=siroe,dc=com 接尾辞に対するクライアント要求を連鎖させる場合は、関連するすべての中間データベースリンクに dc=siroe,dc=com 接尾辞に関連するデータベースを含める必要があります。
次に、この上位接尾辞エントリにクライアント ACI を追加する必要があります。たとえば、次のように追加します。
aci: (targetattr = "*")(version 3.0; acl "Client authentication for database link users"; allow (all) userdn = "ldap:///uid=* ,cn=config";)
この ACI によって、サーバ 1 の cn=config エントリに uid を持つクライアントアプリケーションが、サーバ 3 の ou=people,dc=siroe,dc=com 接尾辞の下にあるデータに対して、任意のタイプの操作を実行できるようになります。
ループの検出
Directory Server に含まれている LDAP 制御でループを防ぐことができます。最初に連鎖を試みたときに、この制御に使用可能な最大ホップ (連鎖接続) 数がサーバによって設定されます。これ以降、別のサーバへ連鎖されるたびに、この数が 1 つずつ減らされます。カウントが 0 になると、サーバはループが検出されたと判断し、クライアントアプリケーションに通知します。使用可能なホップの数は、nsHopLimit 属性を使用して指定されます。指定されていない場合は、デフォルト値の 10 になります。
この制御を使用するには、cn=config,cn=chaining database,cn=plugins,cn=config エントリの nsTransmittedControl 属性に次の OID を追加します。
nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12
各データベースリンクの構成ファイルにこの制御が存在していなければ、ループ検出は実装されません。
カスケード型連鎖構成属性のまとめ
次の表に、カスケード型連鎖における中間データベースリンク構成に使用される属性を示します。
カスケード型連鎖構成の例
次の図のように、3 つのサーバが関連するカスケード型連鎖を作成するには、3 つのサーバすべてに連鎖コンポーネントを構成する必要があります。ここでは、3 つのサーバが関連するカスケード型連鎖の作成手順について、次の項目にわけて説明します。
「サーバ 1 の構成」
サーバ 1 の構成
まず、ldapmodify コマンド行ユーティリティを使用して、データベースリンクをサーバ 1 に追加します。次のユーティリティを含むディレクトリに移動します。
% cd /usr/iplanet/ds5/shared/bin % cd installDir/shared/bin ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
次に、サーバ 1 で、データベースリンク DBLink1 の構成情報を指定します。
dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com
nsfarmserverurl: ldap://africa.siroe.com:389/
nsmultiplexorbinddn: cn=server1 proxy admin,cn=config
nsmultiplexorcredentials: secret
cn:DBLink1
nsCheckLocalACI:offcn="l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com",cn=mapping tree,cn: config
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: DBLink1
nsslapd-suffix: l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com
cn: l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com最初のセクションでは DBLink1 に関連するエントリが作成されます。2 番目のセクションでは新しい接尾辞が作成されるので、サーバでは、データベースリンクに対する要求を正しいサーバに送信できるようになります。ローカル ACI をチェックするためにnsCheckLocalACI 属性を構成する必要はありません。これはサーバ 2 の DBLink2 データベースリンクでのみ必要です。
ループ検出を実装する必要があるので、サーバ 1 の cn=config,cn=chaining database,cn=plugins,cn=config エントリに格納された nsTransmittedControl 属性にループ検出制御の OID を指定する必要があります。OID は次のように指定します。
dn:cn=config,cn=chaining database,cn=plugins, cn=config
changeType: modify
add: nsTransmittedControl
nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12nsTransmittedControl 属性は、通常デフォルトで、ループ検出制御 OID 1.3.6.1.4.1.1466.29539.12 値によって構成されるため、この値が存在するかどうか前もって確認することをお勧めします。この値が存在しない場合には、この構成手順を実行する必要はありません。
サーバ 2 の構成
次に、サーバ 2 にプロキシ管理ユーザを作成します。この管理ユーザは、サーバ 1 によるサーバ 2 へのバインドと認証のために使用されます。サーバ 1 に一意のプロキシ管理ユーザ名を選択すると便利です。このプロキシ管理ユーザは、サーバ 1 にサーバ 2 へのバインドを許可することができます。次のように入力して、プロキシ管理ユーザを作成します。dn: cn=server1 proxy admin,cn=config
objectclass:person
objectclass: organizationalPerson
objectclass:inetOrgPerson
cn: server1 proxy admin
sn: server1 proxy admin
userPassword: secret
description: Entry for use by database links
リモートサーバのプロキシ管理ユーザには、ディレクトリマネージャのユーザを使用しないでください。ディレクトリマネージャのユーザを使用すると、セキュリティホールが発生します。
次に、サーバ 2 でデータベースリンク DBLink2 を構成します。ldapmodify を使用して、DBLink2 の構成情報を次のように指定します。
dn: cn=DBLink2,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com
nsfarmserverurl: ldap://zanz.africa.siroe.com:389/
nsmultiplexorbinddn: cn=server2 proxy admin,cn=config
nsmultiplexorcredentials: secret
cn:DBLink2
nsCheckLocalACI:ondn:cn="l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend:DBLink2
nsslapd-parent-suffix:"c=africa,ou=people,dc=siroe,dc=com"
cn: l=Zanzibar,c=africa,ou=people,dc=siroe,dc=comデータベースリンク DBLink2 は、カスケード型連鎖構成の中間データベースリンクであるため、サーバがクライアントおよびプロキシ管理ユーザがデータベースリンクにアクセスを許可するかどうかをチェックできるように、nsCheckLocalACI を on に設定する必要があります。
サーバ 2 のデータベースリンクは、プロキシ認証制御およびループ検出制御を送信できるように構成されている必要があります。プロキシ認証制御およびループ検出制御を実装するには、両方の対応する OID を指定する必要があります。cn=config,cn=chaining database, cn=plugins,cn=config エントリに次の情報を追加します。
dn:cn=config,cn=chaining database,cn=plugins, cn=config
changeType: modify
add: nsTransmittedControl
nsTransmittedControl: 2.16.840.1.113730.3.4.12
nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12ここで、nsTransmittedControl: 2.16.840.1.113730.3.4.12 はプロキシ認証制御の OID で、nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12 はループ検出制御の OID です。
ループ検出制御が構成済みかどうかを確認し、それに応じて上のコマンドを適用してください。
次の手順では、ACI を設定します。次の操作ができるように、サーバ 2 で l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com 接尾辞の上位に 1 つの接尾辞が存在することを確認する必要があります。
データベースリンク接尾辞の追加
両方の ACI が c=africa,ou=people,dc=siroe,dc=com 接尾辞を含むデータベースに置かれます。ローカルプロキシ認証 ACI を追加。これを使用すると、サーバ 1 は、サーバ 2 で作成されるプロキシ認証管理ユーザを使って接続できる
ローカルクライアント ACI を追加。これによりクライアント操作がサーバ 2 で正常に実行され、サーバ 3 に転送できる。DBLink2 データベースリンクの ACI のチェックをオンにしているため、このローカル ACI が必要
ローカルプロキシ認証 ACI を c=africa,ou=people,dc=siroe,dc=coml エントリに追加します。
aci:(targetattr="*")(target="l=Zanzibar,c=africa,ou=people,
dc=siroe,dc=com")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=server1 proxy admin,cn=config";)次にローカルクライアント ACI を追加し、ACI 検査がオンになった状態のサーバ 2 でクライアント操作が正常に実行されるようにします。この ACI は、l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com 分岐へのアクセス用に連鎖先のサーバで作成する ACI と同じです。c=us,ou=people,dc=siroe,dc=com 内のすべてのユーザにサーバツリーの l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com 内のエントリへの更新アクセスを許可することもできます。上の文を指している次の ACI は、サーバ 2 の c=africa,ou=people,dc=siroe,dc=com 接尾辞にそれを許可するのに (実現するのに) 作成する必要がある ACI です。
aci:(targetattr="*")(target="l=Zanzibar,c=africa,ou=people,
dc=siroe,dc=com")(version 3.0; acl "Client authorization for database links"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=siroe,dc=com";)この ACI によって、サーバ 1 の c=us,ou=people,dc=siroe,dc=com に uid を持つクライアントは、サーバ 3 の l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com 接尾辞ツリーに対して、任意のタイプの操作を実行できるようになります。サーバ 2 に接尾辞の異なるユーザが存在する場合、サーバ 3 にさらに別の権限が必要になるため、サーバ 2 に別のクライアント ACI を追加する必要があります。
サーバ 3 の構成
カスケード型連鎖の使用例の構成手順の最後は、サーバ 3 の構成です。最初に、サーバ 2 がプロキシ認証で使用する管理ユーザをサーバ 3 に作成します。dn: cn=server2 proxy admin,cn=config
objectclass:person
objectclass: organizationalPerson
objectclass:inetOrgPerson
cn: server2 proxy admin
sn: server2 proxy admin
userPassword: secret
description: Entry for use by database links次にサーバ 2 と同様に、サーバ 3 に対して、同じローカルプロキシ認証 ACI を追加します。次のプロキシ認証 ACI を l=Zanzibar,ou=people,dc=siroe,dc=com エントリに追加します。
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=server2 proxy admin,cn=config";)
この ACI によって、サーバ 2 のプロキシ管理ユーザに対して、l=Zanzibar,ou=people,dc=siroe,dc=com サブツリー内にあるリモートサーバであるサーバ 3 に含まれるデータへの読み取り専用アクセス権が与えられます。
次に、l=Zanzibar,ou=people,dc=siroe,dc=com サブツリー、つまりもとのクライアントアプリケーションに対応する場所に、ローカルクライアント ACI を作成する必要があります。次のように、サーバ 2 のクライアント用に作成した ACI と同じ ACI を使用します。
aci: (targetattr = "*")(target="l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com")(versio n 3.0; acl "Client authentication for database link users"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=siroe,dc=com";)
これらの手順すべてを完了すると、カスケード型の連鎖構成が設定されます。このカスケード型構成では、サーバ 1 にバインドし、サーバ 3 の l=Zanzibar,c=africa,ou=people,dc=siroe,dc=com 分岐情報を変更できます。セキュリティ要件に応じて、さらに詳細なアクセス制御を提供するかどうかを決定してください。
レフェラルの使い方
レフェラルを使用して、指定された情報を取得するためにどのサーバに接続すべきかを、クライアントアプリケーションに通知することができます。このリダイレクトは、ローカルサーバには存在しないディレクトリエントリをクライアントアプリケーションが要求した場合、または保守のためにデータベースがオフラインになっている場合に発生します。ここでは、レフェラルに関する次の項目について説明します。
デフォルトレフェラルの設定
ディレクトリにおけるレフェラルの使用の概念については、『iPlanet Directory Server 導入ガイド』を参照してください。
デフォルトレフェラルの設定
デフォルトレフェラルは、ディレクトリで管理されている接尾辞のいずれにも含まれない DN に対して、操作を送信するクライアントアプリケーションに返されます。ここでは、Console とコマンド行ユーティリティを使用して、ディレクトリにデフォルトレフェラルを設定する手順を示します。
Console を使用したデフォルトレフェラルの設定
ディレクトリにデフォルトレフェラルを設定するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
LDAP URL については、付録 C「LDAP URLs」 を参照してください。左側の区画のナビゲーションツリーで、トップのエントリを選択します。
「転送先」テキストボックスに LDAP URL を入力し、「OK」をクリックします。
- たとえば、次のようにします。
- ldap://directory.siroe.com:389/dc=siroe,dc=com
- 複数のレフェラル URL を入力するには、次のようにスペースで区切って、それぞれを引用符で囲みます。
- "ldap://d1.siroe.com:389/dc=siroe,dc=com" "ldap://d2.siroe.com/"
コマンド行からのデフォルトレフェラルの設定
ldapmodify コマンド行ユーティリティを使用して、ディレクトリ構成ファイルの cn=config エントリにデフォルトレフェラルを追加します。たとえば、Directory Server である siroe.com から、サーバ Zanzibar.com に新しいデフォルトレフェラルを追加するには、cn=config エントリに行を追加します。最初に次のユーティリティを含むディレクトリに移動します。
% cd /usr/iplanet/ds5/shared/bin % cd installDir/shared/bin
ldapmodify ユーティリティはサーバにバインドし、構成ファイルのエントリを変更する準備を行います。
- ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
次に、Zanzibar.com サーバにデフォルトレフェラルを追加します。
dn:cn=config
changetype: modify
replace:nsslapd-referral
nsslapd-referral: ldap://zanzibar.com/ディレクトリの cn=config エントリにデフォルトレフェラルを追加すると、クライアントアプリケーションからの要求に対して、このディレクトリからデフォルトレフェラルが返されるようになります。サーバを再起動する必要はありません。
スマートレフェラルの作成
スマートレフェラルを使用して、ディレクトリエントリおよびディレクトリツリーを、特定の LDAP URL に割り当てることができます。スマートレフェラルを使用すると、クライアントアプリケーションに、特定のサーバや特定のサーバにある特定のエントリを参照させることができます。たとえば、クライアントアプリケーションがディレクトリエントリ uid=bjensen,ou=people,dc=siroe,dc=com. を要求したとします。サーバ directory.europe.siroe.com にあるエントリ cn=Babs Jensen,o=people,l=europe,dc=siroe,dc=com をポイントするスマートレフェラルをクライアントに返します。
ディレクトリでのスマートレフェラルの使い方は、RFC 2251 セクション 4.1.11 で指定されている規格に準拠しています。詳細については、RFC テキスト http://www.ietf.org/rfc/rfc2251.txt を参照してください。
次に、Console とコマンド行ユーティリティの両方を使用して、スマートレフェラルを作成する手順について説明します。
Directory Server Console を使用したスマートレフェラルの作成
Directory Server Console で「ディレクトリ」タブを選択します。
エントリをマウスの右ボタンでクリックし、ドロップダウンメニューから「レフェラルの設定」を選択します。
「レフェラルを有効にする」チェックボックスを選択します。
- 「レフェラルの編集」ダイアログボックスが表示されます。レフェラルをこのエントリではじめて作成する場合、「レフェラルリスト」は空白になっています。
「新規レフェラルの入力」フィールドに LDAP URL を入力します。または「構築」をクリックすると、正しい URL の作成を支援するダイアログボックスが表示されます。
「レフェラルの編集」ダイアログボックスで「追加」をクリックし、レフェラルのリストに新しい LDAP URL を追加します。
- URL の要素には、レフェラルエントリを保持する Directory Server のホスト名およびLDAP ポート番号、さらにレフェラルエントリの DN (ターゲット DN) が含まれています。この DN は、接尾辞、サブツリー、または最下位のエントリにすることができます
同じ「レフェラルの編集」ダイアログボックスの「認証」をクリックしてダイアログボックスを表示します。このダイアログボックスで、リモートサーバに対するレフェラルに続くため、現在のサーバがバインド操作で使用する資格を指定します。
レフェラル DN に対するアクセスを許可されたユーザの DN およびパスワードを入力します。「OK」をクリックしてこのダイアログボックスを閉じます。
「レフェラルの編集」ダイアログボックスの「OK」をクリックしてウィンドウを閉じます。
- ナビゲーションツリーで、レフェラルを作成した元のエントリの代わりにレフェラルサブツリーまたはレフェラルエントリが表示されていることを確認します。元のエントリが表示されている場合は、その隣に警告アイコンが表示されます。このアイコンは、手順 7 を実行していないか、または指定したバインド DN およびパスワードにレフェラル DN にアクセスする権限がない場合に表示されます。
コマンド行を使用したスマートレフェラルの作成
ldapmodify コマンド行ユーティリティを使用して、コマンド行からスマートレフェラルを作成します。スマートレフェラルを作成するには、関連するディレクトリエントリを作成し、Referral オブジェクトクラスを追加します。このオブジェクトクラスでは、単一の属性 ref を使用できます。ref 属性には、LDAP URL が含まれているとみなされます。
たとえば、既存のエントリ uid=bjensen に対するスマートレフェラルを返すには、次の行を追加します。
dn:uid=bjensen,ou=people,dc=siroe,dc=com
objectclass:referral
ref: ldap://directory.europe.siroe.com/cn=babs%20jensen,ou=people,
l=europe,dc=siroe,dc=com
注 サーバでは、LDAP URL で空白のあとに続く情報はすべて無視されます。このため、レフェラルとして使用する予定のある LDAP URL では、スペースの代わりに %20 を使用する必要があります。
directory.europe.siroe.com へのレフェラルを持つエントリ uid=ssarette,ou=people,dc=siroe,dc=com を追加するには、インポート前に、LDIF ファイルに次の行を追加します。
dn: uid=ssarette, ou=people, dc=siroe,dc=com
objectclass: top
objectclass:person
objectclass: organizationalperson
objectclass:inetOrgPerson
objectclass:referral
cn: somi sarette
sn: sarette
uid: ssarette
ref: ldap://directory.europe.siroe.com/cn=somi%20sarette,ou=people,
l=europe,dc=siroe,dc=comDN パスにすでにレフェラルがある場合は、ldapmodify で -M オプションを使用します。-M オプションについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。
スマートレフェラルについては、『iPlanet Directory Server 導入ガイド』を参照してください。ldapmodify ユーティリティについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。
接尾辞レフェラルの作成
次に、接尾辞 (suffix) でレフェラルを作成する手順について説明します。つまり、データベースまたはデータベースリンクではなく、レフェラルを使用して、接尾辞が処理を行います。レフェラルについては、『iPlanet Directory Server 導入ガイド』を参照してください。
レフェラルが返されるように接尾辞が構成されている場合は、接尾辞と関連付けられているデータベースに含まれる ACI は無視されます。
Console を使用した接尾辞フェラルの作成
Console を使用して接尾辞レフェラルを作成するには、次の手順を実行します。
Directory Server Console で、「構成」タブを選択します。
左側の区画にある Data で、レフェラルの追加先となる接尾辞をクリックします。
「接尾辞の設定」タブで、次のラジオボタンの 1 つを選択します。
「レフェラル」タブをクリックします。「新規レフェラルの入力」フィールドに LDAP URL を入力します。あるいは、「構築」をクリックすると、LDAP URL の作成がガイドされます。
- レフェラルを使用する : この接尾辞がクライアントアプリケーションから何らかの要求を受け取ったときに、レフェラルが返されます。
- 更新したレフェラルを使用する : この接尾辞がクライアントアプリケーションから更新要求を受け取ったときに、レフェラルが返されます。このオプションは、クライアントアプリケーションからの更新要求および書き込み要求を読み取り専用データベースにリダイレクトするために使用されます。
レフェラルをリストに追加するには、「追加」をクリックします。
- LDAP URL の構造については、付録 C「LDAP URLs」を参照してください。
「保存」をクリックします。
- 複数のレフェラルを入力できます。クライアントアプリケーションからの要求に対応して、ディレクトリがレフェラルのリスト全体を返します。
コマンド行からの接尾辞レフェラルの作成
ldapmodify コマンド行ユーティリティを使用して、ディレクトリ構成ファイルのエントリに接尾辞レフェラルを追加します。接尾辞レフェラル情報が、cn=mapping tree,cn=config 分岐の下にあるルート接尾辞またはサブ接尾辞に追加されます。たとえば、ou=people,dc=siroe,dc=com ルート接尾辞に新しい接尾辞レフェラルを追加するには、ldapmodify を実行します。最初に次のユーティリティを含むディレクトリに移動します。
% cd /usr/iplanet/ds5/shared/bin % cd installDir/shared/bin
ldapmodify ユーティリティはサーバにバインドし、構成ファイルに情報を追加する準備をします。
- ldapmodify -a -h host -p port -D "cn=directory manager" -w password
次に、接尾辞レフェラルを ou=people,dc=siroe,dc=com ルート接尾辞に追加します。
dn: cn="ou=people,dc=siroe,dc=com",cn=mapping tree,cn=config
objectclass: extensibleObject
objectclasss: nsmappingtree
nsslapd-state:referral
nsslapd-referral: ldap://zanzibar.com/nsslapd-state 属性が referral に設定されます。これは、この接尾辞への要求に対してレフェラルが返されることを表します。nsslapd-referral 属性には、接尾辞によって返されたレフェラル (前述の例では Zanzibar.com サーバへのレフェラル) の LDAP URL が含まれます。
また、nsslapd-state 属性に referral on update を設定することもできます。つまり、更新要求以外のすべての操作に対して、このデータベースが使用されます。クライアントアプリケーションが referral on update に設定された接尾辞に更新を要求したときに、クライアントはレフェラルを受け取ります。
接尾辞構成属性については、「接尾辞の属性」を参照してください。
前へ 目次 索引 DocHome 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated February 26, 2002