Sun Java System Communications Services と共にリリースされているすべてのクライアント製品では、ユーザーは企業ディレクトリと自分のアドレス帳を検索できます。この状態でも機能しますが、LDAP をいくらか調整することにより、ユーザーの操作性を向上させることができる場合があります。
ここでは、次の機能について説明します。
Communications Express と Microsoft Outlook 版 Connector のどちらを使用していても、個人用連絡先や公開アドレス帳で特定の文字列を検索するのは、ロケール固有の処理となります。たとえば、フランス語のユーザーが「Gaelle」を検索して「Gaelle」という文字列を含むエントリを取得しようとすると、「Gaëlle」という文字列を含むエントリまで取得されます。
ユーザーに対するロケールに基づいたエントリの表示方法を規定するさまざまな規則を、照合規則または照合順序と呼びます。照合順序によって、該当の言語の文字をソートする方法についての言語と文化に固有の情報が提供されます。アルファベット文字の並び順のような規則、アクセントを持つ文字とアクセントを持たない文字の比較方法、および文字列の比較時に無視できる文字の有無が定められます。また照合順序には、言語に関して文化に固有の情報が考慮されています。たとえば、文字方向 (左から右へ、右から左へ、または上から下へ) などです。
Sun Java System Directory Server では広範囲のロケールと照合規則をサポートしています (『Sun Java System Directory Server 5 2005Q1 Administration Reference』の「Identifying Supported Locales」を参照)。ユーザーベースによっては、使用環境のほとんどの部分に影響を与えるロケールを最初に選択する必要があります。次に示す例では、英語 (US) ロケール (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1) を使用します。
検索の実行時に使用するロケールを指定するには、『Sun Java System Directory Server 5 2005Q1 Administration Reference』の「Searching an Internationalized Directory」に記載されているマッチングルールフィルタ構文を使用します。この構文を使用すると、ローケルだけでなく検索の種類 (等価、部分文字列など) も指定できます。
たとえば、次のフィルタを使用すると、英語 (US) の照合規則 (1.3.6.1.4.1.42.2.27.9.4.34.1) を使い、CN 属性に対して部分文字列の比較 (.6) が実行されます。このフィルタは、「Gae」で始まる文字列を CN で検索します。
cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*
LDAP 検索の実行時に発生するパフォーマンスに関する問題のほとんどは、インデックスが存在しないか、正しく設定されていないことが原因です。デフォルトでは、Directory Server は Communications Express または Microsoft Outlook 版 Connector が発行した検索ではインデックスを使用するように設定されているため、妥当な時間内に結果が返されます。しかし、Directory Server はインターナショナル検索に対応するように設定されていません。そのため、選択されている照合規則に対応するように既存のインデックスを変更する必要があります。これについては、『Sun Java System Directory Server 5 2005Q1 Administration Guide』の「インデックスの管理」に説明されています。
たとえば、CN 属性はデフォルトで userRoot サフィックスにインデックス設定されています。
# ldapsearch -D "cn=Directory manager" -b "cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" "objectclass=*" cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass=top objectClass=nsIndex cn=cn nsSystemIndex=false nsIndexType=pres nsIndexType=eq nsIndexType=sub
これを英語 (US) の照合規則を使用したインターナショナル検索で有効にするには、英語 (US) の OID を持つ nsMatchingRule 属性を 1 つ追加します。クライアントは部分文字列検索を実行するので、次のように部分文字列サフィックス (「.6」) を OID に追加する必要があります。
#ldapmodify -D "cn=Directory manager" dn: cn=cn,cn=index,cn=userRoot,cn=ldbm database, cn=plugins,cn=config changetype: modify add: nsMatchingRule nsMatchingRule: 1.3.6.1.4.1.42.2.27.9.4.34.1.6
値の先頭または末尾に、スペース、タブ、その他表示されない文字を追加しないでください。
nsMatchingRule は、複数の値を設定できる属性です。同一の OID に対して異なる種類の検索を追加することや、異なる OID を追加することができます。
その後、 serverroot/slapd-instance に格納されている db2index.pl スクリプトを実行する必要があります。
# perl db2index.pl -D "cn=Directory Manager" -w \ secret -n userRoot -t cn
この操作はオンラインで実行されますが、終了までに時間がかかることがあります。または、サフィックスを再初期化することもできます。詳細については、『Sun Java System Directory Server 5 2005Q1 Administration Guide』の「サフィックスの再初期化」を参照してください。
コンソールを使用して nsMatchingRule を追加することもできます (『Sun Java System Directory Server 5 2005Q1 Administration Guide』の「インデックスの管理」を参照)。
修正の必要があるインデックスのリストを次に掲載します。インデックスを使用しない検索は実行されないことを確認してください。これは、Directory Server のアクセスログファイルを参照し、検索結果のエントリで notes=U を探すことで確認できます。
Communications Express が使用する検索フィルタを、マッチングルールの構文に適合するように変更する必要があります。それには、db_config.properties ファイルで指定される照合規則のパラメータを有効にします。このファイルは、 deployed-path/WEB-INF/ldappstore (個人ストア用) および deployed-path/WEB-INF/corp-dir (企業ディレクトリ用) に格納されています。
パラメータの内容は次のとおりです。
# Collation Rule # Uncomment below to apply collation rule # collation_rule=en-US # Search Fields for which collation rule should be applied. # The fields provided here should be disambiguator formatted fields # e.g. entry/displayname, person/givenname etc. # Uncomment below to supply the comma-separated fields # search_fields=entry/displayname
照合規則を有効にするには、collation_rule パラメータと search_fields パラメータをアンコメントにします。検索で個別のフィールドやフィールドセットを指定するには、search_fields の値を適切な値に変更します。collation_rule には、検索の種類を示すサフィックスなしで、言語タグまたはその言語に対応する OID (例では 1.3.6.1.4.1.42.2.27.9.4.34.1) のどちらかを格納できます。変更後に Web コンテナインスタンスを起動する必要があります。
Communications Express に対するインターナショナル検索には、LDAP サーバー上で次の属性のインデックスを作成してください。
cn (ou=people/ou=groups サフィックスの下)
displayname (o=piServerDb サフィックスの下)
Microsoft Outlook 版 Connector は、DN とパスワードを使用してバインドすることも、匿名としてバインドすることもできます。企業ディレクトリへの匿名のアクセスを有効にするには、ou=people/ou=group サブツリーのルートレベルで ACL を追加します。
たとえば、ルートレベルが dc=red,dc=sesta,dc=com であれば、次のように設定します。
#ldapmodify -D "cn=Directory manager" dn: dc=red,dc=sesta,dc=com changetype: modify add: aci aci: (targetattr != "userPassword") (version 3.0;acl "Anonymous access"; allow (read,compare,search) (userdn = "ldap:///anyone");)
この 7 2005Q4 リリースから、Microsoft Outlook 版 Connector では一般ユーザーがディレクトリを参照できるようになりました。アドレス帳のページを呼び出すと、ディレクトリ内の先頭から 10 個のエントリが表示されます。ユーザーは上下にスクロールしたり、数文字を入力して、自動的に表示される結果を参照することができます。これは、ユーザーが特定の 1 ユーザーしか検索できなかった Microsoft Outlook 版 Connector の以前のバージョンからの変更点です。
パフォーマンスを維持しつつこの機能を有効にするために、Connector には仮想リスト表示 (VLV) および検索結果の server-side sorting (RFC 2891) という 2 つの LDAP 制御の拡張機能が備えられています。次の ldapsearch の例では、サポートされる制御のリストが返されます。
# ldapsearch -s base "objectclass=*" supportedControl supportedControl=2.16.840.1.113730.3.4.2 supportedControl=2.16.840.1.113730.3.4.3 supportedControl=2.16.840.1.113730.3.4.4 supportedControl=2.16.840.1.113730.3.4.5 supportedControl=1.2.840.113556.1.4.473 ------> Server Side Sort Control supportedControl=2.16.840.1.113730.3.4.9 ------> VLV Control supportedControl=2.16.840.1.113730.3.4.16 supportedControl=2.16.840.1.113730.3.4.15 supportedControl=2.16.840.1.113730.3.4.17 supportedControl=2.16.840.1.113730.3.4.19 supportedControl=1.3.6.1.4.1.42.2.27.9.5.2 supportedControl=1.3.6.1.4.1.42.2.27.9.5.6 supportedControl=2.16.840.1.113730.3.4.14 supportedControl=1.3.6.1.4.1.1466.29539.12 supportedControl=2.16.840.1.113730.3.4.12 supportedControl=2.16.840.1.113730.3.4.18 supportedControl=2.16.840.1.113730.3.4.13
Sun Java System Directory Server は、どちらの制御もサポートしています。しかしデフォルトでは、VLV 制御は認証されたユーザーしか利用できません。
ldapsearch -D "cn=Directory Manager" -b \ "oid=2.16.840.1.113730.3.4.9,cn=features,cn=config" \ "objectclass=*" aci oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \ aci=(targetattr != "aci")(version 3.0; acl "VLV Request Control"; \ allow( read, search, compare, proxy ) userdn = "ldap:///all";)
VLV 制御への匿名アクセスを許可するには、対応する ACI を追加します。
#ldapmodify -D "cn=Directory Manager" \ dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \ changetype: modify add: aci aci: (targetattr !="aci")\ (version 3.0; acl "VLV Request Control"; allow (compare,read,search) \ userdn = "ldap:///anyone"; )
VLV と Sort を必要とする検索のパフォーマンスを向上させるには、Directory Server にブラウズインデックスを作成します (『Sun Java System Directory Server 5 2005Q1 Administration Guide』の「ブラウズインデックスの管理」参照)。各ブラウズインデックスは、ベース DN、検索フィルタ、スコープ、およびソート属性ごとに固有です。VLV 設定は、クライアント側で配備設定ツールを使用して調整できます。
ここでは、CN 属性にソートを使用し、dc=red,dc=iplanet,dc=com と等しいベース DN および (&(mail=*)(cn=*)) と等しいフィルタに対してブラウズインデックスを作成する必要があります。ブラウズインデックスの情報は、ベース DN (この場合 userRoot) を含む設定に追加されます。
#ldapmodify -D "cn=Directory Manager" dn: cn=Browsing red.sesta.com,cn=userRoot, cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: vlvSearch cn: Browsing red.sesta.com vlvbase: dc=red,dc=sesta,dc=com vlvscope: 2 vlvfilter: (&(mail=*)(cn=*)) aci: (targetattr="*") (version 3.0; acl "VLV for Anonymous"; allow (read,search,compare) userdn="ldap:///anyone";) dn: cn=Sort by cn, cn=Browsing red.sesta.com,cn=userRoot, cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: vlvIndex cn: Sort by cn vlvSort: cn
次に、 serverroot/slapd-instance の下にある vlvindex コマンドを実行します。
# ./vlvindex -n userRoot -T "Sort by cn"