Configuration LDAP sur les clients (Notes de version de Sun Java System Communications Services 2005Q4)

Notes de version de Sun Java System Communications Services 2005Q4

Configuration LDAP sur les clients

Tous les produits suivants publiés avec Sun Java System Communications Services permettent aux utilisateurs d'effectuer des recherches dans l'annuaire de l'entreprise et dans leurs propres carnets d'adresses. Bien que ceci fonctionne, un réglage LDAP peut améliorer ces recherches.

Cette section traite des points suivants :

Configuration des recherches internationales

Que vous utilisiez Communications Express ou Connector pour Microsoft Outlook, la recherche d'une chaîne particulière effectuée dans votre carnet d'adresses personnel ou dans le carnet d'adresses public est une opération spécifique à la langue. Par exemple, un utilisateur français recherchant “Gaelle” s'attend à obtenir des réponses contenant la chaîne “Gaelle” mais également toute chaîne contenant “Gaëlle”.

Les diverses règles définissant le mode de présentation des entrées à un utilisateur en fonction de la langue sont appelées règles d'interclassement ou ordre de classement. L'ordre de classement fournit des informations spécifiques à la langue et à la culture concernant le mode de tri des caractères d'une langue donnée. Il identifie des éléments tels que la séquence des lettres de l'alphabet, le mode de comparaison entre lettres accentuées et non accentuées, et détecte si des caractères peuvent être ignorés lors de la comparaison de chaînes. L'ordre de classement prend également en compte les informations spécifiques à la culture concernant la langue, telles que le sens de lecture (gauche à droite, droite à gauche ou verticalement).

Sun Java System Directory Server prend en charge de nombreuses langues et règles d'interclassement (voir “Identifying Supported Locales” dans le manuel Sun Java System Directory Server 5 2005Q1 Administration Reference). En fonction de votre base utilisateur, vous devez d'abord choisir la langue qui est la plus significative dans votre environnement. Nous utilisons ici l'anglais (É.U.) (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1) comme exemple.

Pour spécifier la langue à utiliser pour une recherche, utilisez la syntaxe de filtre de règle de concordance, décrite dans la section “Searching an Internationalized Directory” du manuel Sun Java System Directory Server 5 2005Q1 Administration Reference. Cette syntaxe permet d'indiquer la langue ainsi que le type de recherche (égalité, sous-chaîne, etc.).

Par exemple, le filtre suivant effectue une comparaison de sous-chaîne (.6) sur l'attribut CN, à l'aide des règles d'interclassement de l'anglais (É.U.) (1.3.6.1.4.1.42.2.27.9.4.34.1). Le filtre recherche dans le CN les chaînes commençant par “Gae”

cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*

Mise à jour des index

Lors d'une recherche LDAP, la plupart des problèmes de performances proviennent du fait que les index sont absents ou ne sont pas configurés correctement. Par défaut, Directory Server est configuré de sorte que les recherches émises par Communications Express ou par Connector pour Microsoft Outlook sont indexées et doivent renvoyer les réponses dans un délai acceptable. Toutefois, Directory Server n'est pas configuré pour les recherches internationales. Les index existants doivent par conséquent être modifiés de sorte qu'ils prennent en compte les règles d'interclassement choisies. Ceci est expliqué dans la section “Managing Indexes” du manuel Sun Java System Directory Server 5 2005Q1 Administration Guide.

Par exemple, l'attribut CN est indexé par défaut dans le suffixe 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

Pour l'activer pour les recherches internationales à l'aide des règles d'interclassement Anglais (É.U.), ajoutez un attribut nsMatchingRule à l'OID Anglais (É.U.). Le client effectue des recherches dans les sous-chaînes, il est donc indispensable d'ajouter le suffixe de sous-chaîne (“.6”) à l'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

Remarque –

N'ajoutez ni espace, ni tabulation, ni tout autre caractère invisible au début ou à la fin de la valeur.

Remarque –

nsMatchingRule est un attribut à valeurs multiples. Vous pouvez ajouter différents types de recherche pour le même OID ou différents OID.

Le script db2index.pl qui se trouve dans serverroot/slapd-instance doit ensuite être exécuté :

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

Cette opération est exécutée en ligne et peut prendre un certain temps. Vous pouvez aussi réinitialiser le suffixe. Voir la section “Reinitializing a Suffix” dans le manuel Sun Java System Directory Server 5 2005Q1 Administration Guide.

La console peut être utilisée pour ajouter l'attribut nsMatchingRule (voir la section “Managing Indexes” du manuel Sun Java System Directory Server 5 2005Q1 Administration Guide).

Les sections suivantes contiennent la liste des index à modifier. Assurez-vous qu'aucune recherche non indexée n'est effectuée. Pour ce faire, consultez le fichier journal des accès de Directory Server (et recherchez notes=U dans les entrées de résultats).

Configuration du filtre de recherche dans Communications Express

Le filtre de recherche utilisé par Communications Express doit être modifié pour respecter la syntaxe de règle de concordance. Pour ce faire, vous devez activer les paramètres de règles d'interclassement spécifiés dans le fichier db_config.properties (qui se trouve dans deployed-path/WEB-INF/ldappstore (pour le stockage personnel) et dans deployed-path/WEB-INF/corp-dir (pour le stockage de l'entreprise).

Les paramètres sont les suivants :

# 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

Annulez la mise en commentaire des paramètres collation_rule et search_fields pour activer la règle d'interclassement. Pour spécifier un ensemble de champs distinct dans la recherche, remplacez la valeur de search_fields par les valeurs souhaitées. collation_rule peut contenir soit la balise de langue soit l'OID correspondant à cette langue (dans l'exemple 1.3.6.1.4.1.42.2.27.9.4.34.1) sans le suffixe qui spécifie le type de recherche. L'instance du conteneur Web doit être démarrée une fois la modification effectuée.

Les attributs suivants doivent être indexés sur le serveur LDAP pour la recherche internationale dans Communications Express :

cn (sous le suffixe ou=people/ou=groups)
displayname (sous le suffixe o=piServerDb)

Autorisation d'accès anonyme à l'annuaire de l'entreprise

Connector pour Microsoft Outlook peut être configuré pour des connexions à l'aide d'un DN et d'un mot de passe, ou pour des connexions anonymes. Pour activer l'accès anonyme à l'annuaire de l'entreprise, ajoutez un ACL à la racine des sous-arborescences ou=people/ou=group.

Par exemple, si le niveau racine est dc=red,dc=sesta,dc=com, procédez comme suit :

#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");)

Autorisation de parcours de l'annuaire

Une des nouveautés de la version 7 2005Q4, Connector pour Microsoft Outlook permet désormais aux utilisateurs de parcourir l'annuaire. Lors de l'ouverture de la page du carnet d'adresses, les 10 premières entrées de l'annuaire sont affichées. L'utilisateur peut faire défiler la page vers le bas et vers le haut, ou entrer quelques caractères et consulter les résultats actualisés automatiquement. Ceci est différent des versions précédentes de Connector pour Microsoft Outlook où l'utilisateur pouvait rechercher uniquement un utilisateur particulier.

Pour activer cette fonction tout en conservant des performances optimales, Connector s'appuie sur des extensions de contrôles LDAP, appelées Affichage de la liste virtuelle, et le tri côté serveur des résultats de la recherche (RFC 2891). L'exemple ldapsearch suivant renvoie la liste des contrôles pris en charge :

# 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 prend en charge les deux contrôles. Toutefois, le contrôle d'affichage de la liste virtuelle est disponible par défaut uniquement pour les utilisateurs authentifiés :

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";)

Pour autoriser l'accès anonyme au contrôle d'affichage de la liste virtuelle, ajoutez l'ACI correspondante :

#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"; )

Pour améliorer les performances des recherches qui requièrent l'affichage de la liste virtuelle et le tri, créez un index de navigation dans Directory Server (comme expliqué dans la section “Managing Browsing Indexing” du manuel Sun Java System Directory Server 5 2005Q1 Administration Guide). Chaque index de navigation est spécifique à un DN de base, un filtre de recherche, une étendue et un attribut de tri. Les paramètres d'affichage de la liste virtuelle peuvent être réglés côté client à l'aide de l'outil de configuration du déploiement.

Dans ce cas précis, un index de navigation doit être créé pour un dn de base égal à dc=red,dc=iplanet,dc=com, un filtre égal à (&(mail=*)(cn=*)), à l'aide d'un tri sur l'attribut cn. Les informations d'index de navigation sont ajoutées à la configuration contenant le dn de base (dans ce cas 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

Exécutez ensuite la commande vlvindex qui se trouve dans serverroot/slapd-instance :

# ./vlvindex -n userRoot -T "Sort by cn"