test

Tuning LDAP to Improve Searches in Communications Services Clients

Setting up International Searches

Whether you use Communications Express or Connector for Microsoft Outlook, your search in your personal contacts or the public address book for a particular string is a locale-specific operation. For example, a French user searching for “Gaelle” expects to get back entries containing the string “Gaelle” but also any entry containing the string “Gaëlle.”

The various rules driving the way entries are presented to a user based on locale are called collation rules or collation order. The collation order provides language and cultural-specific information about how the characters of a given language are to be sorted. These rules identify the sequence of the letters in the alphabet, how to compare letters with accents to letters without accents, and characters that can be ignored when comparing strings. The collation order also takes into account culture-specific information about a language, such as the direction in which the language is read (left to right, right to left, or up and down).

The Sun Java System Directory Server supports a large variety of locales and collation rules (See “Identifying Supported Locales” in the Sun Java System Directory Server 5 2005Q1 Administration Reference). Depending on your user base, you first need to choose the locale for your environment. In the example below, we use the English (US) locale (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1).

To specify which locale to use when performing a search, use the matching rule filter syntax, described in “Searching an Internationalized Directory” in the Sun Java System Directory Server 5 2005Q1 Administration Reference. This syntax lets you specify the locale as well as the type of search (equality, substring, and so on).

The following filter will perform a substring comparison (.6) on the CN attribute, using the English (US) collation rules (1.3.6.1.4.1.42.2.27.9.4.34.1). The filter looks at the CN for strings starting with Gae:

cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*

Updating the Indexes for International Searches

During an LDAP search, most performance problems occur because indexes are not present or are not properly configured. By default, the Directory Server is configured so that lookups issued by Communications Express or by Connector for Microsoft Outlook are indexed and should return in a reasonable amount of time. Nevertheless, the Directory Server is not set up for international searches. you must alter the existing indexes so that they take into account the collation rules that have been chosen. How to alter the indexes is described in the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

For example, the CN attribute is indexed by default in the userRoot suffix:

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

To enable the indexes for international searches using the English (US) collation rules, add one nsMatchingRule attribute with the English (US) OID. The clients perform substring searches, so add the substring suffix (.6) to the 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
Note –

Do not add a space, tab, or other non-visible characters at the beginning or at the end of the value.

The nsMatchingRule attribute is a multivalued attribute. Different types of searches for the same OID, or different OIDs can be added.

Run the db2index.pl script located under server-root/slapd-instance:

perl db2index.pl -D "cn=Directory Manager" -w \ 
secret -n userRoot -t cn

This script runs online and might take some time to finish. Alternatively, reinitialize the suffix. See “Reinitializing a Suffix” in the Sun Java System Directory Server 5 2005Q1 Administration Guide.

Use console to add the nsMatchingRule attribute (see the “Managing Indexes” section in the Sun Java System Directory Server 5 2005Q1 Administration Guide).

See the following sections for the indexes that need to be modified. Ensure that no non-indexed searches are performed by looking at the Directory Server access log file and for a notes=U in the search results.

Setting up the Search Filter in Communications Express

You must change the search filter used by Communications Express to accommodate the matching rule syntax through the collation rule parameters specified in the db_config.properties file. The file resides under deployed-path/WEB-INF/ldappstore for personal store and deployed-path/WEB-INF/corp-dir for corporate directory.

The parameters are:

# 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

Uncomment the collation_rule and search_fields parameters to enable the collation rule. In order to specify a separate set of field or fields in the search, change the value of search_fields to the desired values. The collation_rule can contain either the language tag or the OID corresponding to that language (in the example 1.3.6.1.4.1.42.2.27.9.4.34.1) without the suffix specifying the type of search. The Web Container instance needs to be started after making the change.

Index the following attributes on the LDAP Server for international search against Communications Express: