test

Notes de version de Sun Java System Communications Services 2005Q4

Problèmes de compatibilité

Cette section répertorie les problèmes de compatibilité existant dans Connector pour Microsoft Outlook.

Considérations relatives à Sun Java System Calendar Server

Cette section décrit les considérations relatives à Sun Java System Calendar Server pour Connector pour Microsoft Outlook.

Installation de Calendar Server

La dernière version de Calendar Server est disponible sur le site Web de téléchargement Collaboration and Communication.

Il est recommandé aux clients d'installer également le dernier jeu de patchs, disponible sur le site SunSolve.

Pour obtenir des instructions détaillées concernant l'installation, reportez-vous au manuel Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. Pour connaître les instructions de configuration, reportez-vous au manuel Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Remarque –

Si vous migrez Calendar Server 5.x vers la dernière version de Calendar Server, vous devez exécuter l'utilitaire cs5migrate_recurring pour convertir la base de données afin de la rendre compatible avec le modèle de données de Connector pour Microsoft Outlook. Consultez le support technique pour obtenir des informations sur l'utilitaire cs5migrate_recurring.

Attribut de messagerie LDAP requis

Calendar Server 6 2004Q2 (et versions ultérieures) nécessite l'attribut LDAP mail pour les calendriers d'utilisateurs et de ressources.

Pour que les clients puissent utiliser Microsoft Outlook afin de planifier les calendriers des ressources (par exemple, pour les salles de réunion ou les équipements, tels qu'un ordinateur portable ou un rétroprojecteur), chaque ressource doit posséder une adresse électronique, même si cette adresse n'est pas nécessaire en réalité. L'attribut LDAP mail spécifie cette adresse e-mail.

Vous pouvez avoir besoin d'ajouter l'attribut LDAP mail comme suit :

Installation de la version 5.x. Avant d'exécuter l'utilitaire de migrationcs5migrate_recurring, ajoutez l'attribut mail aux utilisateurs pour les calendriers d'utilisateurs et de ressources. Pour ajouter l'attribut mail, servez-vous de l'utilitaire csattribute de Calendar Server ou d'un utilitaire tel que ldapmodify de Directory Server.

Nouvelle installation (6 2004Q2 ou version ultérieure). Ajoutez l'attribut LDAP mail aux utilisateurs existants à la fois pour les calendriers d'utilisateurs et de ressources à l'aide de l'utilitaire csattribute de Calendar Server ou d'un utilitaire tel que ldapmodify de Directory Server.

Si vous créez des calendriers ou des utilisateurs après l'installation, utilisez l'option requise -m email pour spécifier une adresse e-mail lorsque vous exécutez les utilitaires de Calendar Server suivants :

Pour toute information connexe sur csattribute, csresource et csuser, reportez-vous au manuel Sun Java System Calendar Server 6 2005Q4 Administration Guide. Pour toute information connexe sur l'utilitaire ldapmodify, reportez-vous au document Sun Java System Directory Server Resource Kit Tools Reference.

ProcedureAjout de l'attribut de messagerie LDAP à un calendrier de ressources

Dans l'exemple suivant, l'attribut LDAP mail est ajouté à la salle de conférence appelée “Room100” sur le serveur sesta.com. Cet exemple configure Messaging Server. Si vous utilisez un autre serveur de messagerie, reportez-vous à la documentation du produit pour connaître la procédure équivalente.

Étapes

  1. Ajoutez l'attribut mail au serveur LDAP à l'aide de l'utilitaire csattribute :

    # ./csattribute -a mail=Room100@sesta.com add Room100

  2. Pour vérifier que l'attribut est bien défini, utilisez la commande csattribute list avec l'option -v (mode détaillé) :


    # ./csattribute -v list Room100
...
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com

ProcedureDéfinition du canal de trou noir (bitbucket) pour les e-mails de ressources (Messaging Server)

Les exemples ci-dessous définissent le canal de trou noir dans Messaging Server pour les e-mails générés pour les calendriers de ressources. Il utilise la ressource nommée “Room100” sur le serveur sesta.com. Si vous ne configurez pas le canal de trou noir (ou équivalent), vous devrez supprimer régulièrement les e-mails envoyés au calendrier de ressources.

Étapes

  1. Assurez-vous que le canal de trou noir bitbucket est défini dans le fichier imta.cnf.

  2. Pour acheminer les messages vers le canal bitbucket, créez l'adresse e-mail de la ressource à l'aide de l'utilitaire csresource :

    # ./csattribute -a mail=Room100@bitbucket.sesta.com add Room100

    Remarque –

    Pour activer ces modifications, vous devrez peut-être également reconstruire les tables d'alias ou les configurations. Consultez la documentation de Messaging Server (ou de votre logiciel de messagerie) ainsi que la documentation et les procédures de changement des services de messagerie de votre propre site.

ProcedureDéfinition du canal de trou noir (bitbucket) pour les e-mails de ressources (SendMail)

L'exemple suivant définit le canal de trou noir (bitbucket) dans Sendmail pour les e-mails générés pour les ressources de calendrier. Il utilise la ressource nommée “Room100” sur le serveur sesta.com. Si vous ne configurez pas le canal de trou noir (ou équivalent), vous devrez supprimer régulièrement les e-mails envoyés au calendrier de ressources.

Étapes

  1. Dans le fichier /etc/aliases de l'hôte approprié, ajoutez une entrée telle que :


    # Resource/Conference room aliases
Room100: /dev/null

  2. Ajoutez l'adresse e-mail de la ressource à l'annuaire LDAP à l'aide de l'utilitaire csresource :

    # ./csattribute -a mail=Room100@sesta.com add Room100

Alias de messagerie (attribut mailalternateaddress)

Si vous devez configurer un alias de messagerie pour un utilisateur de calendrier, utilisez l'attribut LDAP mailalternateaddress. L'attribut de messagerie LDAP fournit l'adresse e-mail principale et l'attribut LDAP mailalternateaddress définit les alias de messagerie. Les deux attributs associent les adresses e-mail à l'ID de calendrier de l'utilisateur (calid).

Par exemple, pour ajouter l'attribut mailalternateaddress à un utilisateur nommé John Smith, avec les valeurs suivantes :

Utilisez les commandes suivantes de l'utilitaire Calendar Server :


# ./csuser -g John -s Smith -y password -l en -m john.smith@sesta.com 
\ -c johnsmith create johnsmith
# ./csattribute -a mailalternateaddress=johns@sesta.com add johnsmith
# ./csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith

Configuration de la consultation du calendrier partagé par l'annuaire LDAP

Si Directory Server requiert une authentification pour la consultation du calendrier partagé par l'annuaire LDAP, le paramètre service.wcap.userprefs.ldapproxyauth doit être défini dans le fichier ics.conf comme suit :

Si service.wcap.userprefs.ldapproxyauth a pour valeur “yes”, vous devez également définir l'ACI LDAP appropriée pour l'entrée calmaster. Par exemple, pour définir l'ACI calmaster afin de définir l'authentification par proxy pour le domaine sesta.com, utilisez l'outil ldapmodify comme suit :

dn:  o=usergroup
changetype: modify
add: aci
aci: (targetattr="icscalendar || cn || givenName || sn || uid ||
mail")(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl
"Allow calendar administrators to proxy -
product=ics,class=admin,num=2,version=1"; allow (proxy) groupdn =
"ldap:///cn=Calendar Administrators,ou=Groups,o=usergroup";)

Pour le noeud de domaine basedn, l'exemple suivant montre l'ACI correct :

dn:  o=sesta.com,o=usergroup
changetype: modify
add: aci
aci:(targetattr="icscalendar || cn || givenName || sn || uid || mail")
(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl "Allow 
calendar users to read and search other users - 
product=ics,class=admin,num=3,version=1"; allow (search,read)
userdn = "ldap:///uid=*, ou=People, o=sesta.com, o=usergroup";)

S'il n'existe aucun domaine, ajoutez l'ACI au suffixe racine lui-même en supprimant la partie o=sesta.com de la ligne dn:.

Le programme de configuration de Calendar Server, csconfigurator.sh, ajoute ces ACI. Si vous effectuez une mise à niveau à partir de Java Enterprise System version 1, vous devez relancer le programme de configuration pour obtenir ces ACI modifiés.

Consultation de l'état libre/occupé d'Outlook et SSL

L'option de consultation de l'état libre/occupé d'Outlook n'est pas prise en charge pour les utilisateurs qui accèdent à Calendar Server en mode SSL. Pour utiliser à la fois le mode SSL et non-SSL de la même instance de Calendar Server, les utilisateurs doivent spécifier différents numéros de port, comme ci-dessous :

Pour plus d'informations sur SSL, reportez-vous au Chapitre 8, Configuring SSL du Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Base de données Delete Log de Calendar Server

Calendar Server 6 2004Q2 (ou version ultérieure) contient la base de données Delete Log ( ics50deletelog.db) qui stocke les événements et les tâches à réaliser ayant été supprimés. Pour plus d'informations, reportez-vous au Chapitre 18, Administering the Delete Log Database du Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Interopérabilité de mappage des dossiers système avec Communications Express

Alors que le protocole IMAP ne définit qu'un seul dossier système pour le courrier entrant (boîte de réception), les clients de messagerie tels qu'Outlook et Sun Java System Communications Express définissent leurs propres dossiers système pour les brouillons, le courrier envoyé et le courrier supprimé. Les clients de messagerie ne peuvent distinguer les différents dossiers. Ces dossiers système sont créés et nommés différemment selon l'environnement linguistique et le logiciel client. Cela entraîne la création de plusieurs dossiers IMAP physiques pour un dossier système si plusieurs clients de messagerie accèdent à un seul compte de messagerie (ou si un même client de messagerie accède à un seul compte, mais à partir d'un environnement linguistique différent).

Dans Outlook, les dossiers sont nommés :

Dans Communications Express, les dossiers sont nommés comme suit :

Définition des dossiers système d'Outlook

Un nouveau fichier de mappage du système de messagerie de Sun Java System Connector pour Microsoft Outlook est disponible pour fournir une meilleur interopérabilité entre Outlook et Communications Express. Cette solution permet à l'administrateur de définir comment les dossiers système doivent être mappés. Le fichier uwc_folders.map contient les définitions de mappage des dossiers système de Communications Express. Le fichier outlook_folders.map contient les définitions de mappage des dossiers système de Connector pour Microsoft Outlook.

Vous pouvez choisir l'un de ces fichiers à utiliser comme fichier de définition des dossiers système dans le programme de configuration et de déploiement (sous l'onglet Courrier). Sélectionnez style Outlook ou style Communications Express pour choisir laquelle de ces deux normes le programme utilisateur doit employer pour nommer les dossiers IMAP des utilisateurs. Votre choix détermine lequel des deux fichiers de mappage, outlook_folders.map ou uwc_folders.map, sera utilisé pour le mappage des noms de dossiers IMAP des utilisateurs. Avant d'exécuter ce programme, un administrateur peut modifier ces fichiers afin de satisfaire les exigences locales et ce, dans la mesure où les fichiers d'origine restent les mêmes.

Définition des dossiers système de Communications Express

Vous devez ensuite définir les dossiers système de Communications Express. Le fichier i18n.js détermine les noms de dossiers système de Communications Express. Ce fichier se trouve dans le répertoire /var/opt/SUNWmsgsr/config/html/ lang, où lang est la langue locale (par exemple fr pour Français). Ce fichier doit être modifié de sorte que les entrées de mappage soient similaires aux entrées du fichier sjoc_folders.map.

Par exemple, les mappages de dossiers par défaut sont les suivants dans le fichier i18n.js français :

i18n[’INBOX’] = ’Inbox’
i18n[’trash folder’] = ’trash’
i18n[’draft folder’] = ’draft’
i18n[’sent folder’] = ’sent’
...
fldr[’INBOX’] = ’French Inbox’
fldr[’trash’] = ’French Trash’
fldr[’draft folder’] = ’French Draft Folder’
fldr[’sent folder’] = ’French Sent Folder’

Les valeurs du fichier i18n[x ] sont utilisées pour créer des dossiers système dans la banque IMAP. Par exemple, si i18n[’trash folder’]= ’trash’, alors un dossier portant le nom trash sera créé dans la banque IMAP. Les valeurs de fldr[y] sont utilisées pour afficher le nom des dossiers système dans l'interface client.

Dans le fichier sjoc_folders.map, les mappages de dossiers similaires sont les suivants :

[fr]
INBOX=’Boîte de réception’
Deleted Items=’Éléments supprimés’
Drafts=’Brouillons’
Sent Items =’Éléments envoyés’

Les mappages de dossier du fichier i18n.js français doivent donc être modifiés de sorte à reprendre les entrées du fichier sjoc_folders.map :

i18n[’INBOX’] = ’Boîte de réception’
i18n[’trash folder’] = ’Éléments supprimés’i18n[’draft folder’] = ’Brouillons’
i18n[’sent folder’] = ’Éléments envoyés’
...
fldr[’INBOX’] = ’Boîte de réception’
fldr[’trash’] = ’Éléments supprimés’
fldr[’Drafts’] = ’Brouillons’
fldr[’Sent’] = ’Éléments envoyés’

Vous devrez modifier les fichiers i18n.js pour chacune des langues.

Remarque –

Les fichiers i18n.js étant en code UTF8, vous devez utiliser un éditeur compatible avec le code UTF8.

Cette nouvelle définition de mappage de dossiers ne s'applique qu'aux nouveaux utilisateurs.

Pour que l'utilisateur puisse se connecter à Communications Express, la langue préférée doit être définie. Pour ce faire, paramétrez l'attribut preferredLanguage ou preferredLocale à l'aide de la commande ldapmodify.

Les nouveaux utilisateurs ne doivent voir qu'un seul ensemble de dossiers système, sauf dans le cas suivant :

Si un utilisateur se connecte à Outlook avec ses paramètres régionaux définis sur le français et qu'il se connecte ensuite à Communications Express en définissant l'anglais comme préférence linguistique, il verra s'afficher les dossiers système trash, draft, sent, Éléments supprimés, Brouillons et Éléments envoyés dans Outlook et Communications Express.

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 :

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"