Synchronisation d'annuaire Active Directory et de base LDAP

Transcription

1 Synchronisation d'annuaire Active Directory et de base LDAP Auteur : Jean-Noël Chardron Délégation régionale d'aquitaine-limousin Jean-Noel.Chardron@dr15.cnrs.fr Le 14 avril 2011 Résumé Cet article montre la possibilité de synchroniser un annuaire Active Directory (AD) sur un serveur Windows 2008 avec un annuaire Ldap sur un serveur Linux. Nous décrirons le choix du logiciel et succinctement son paramétrage. Dans un deuxième temps nous montrons comment procéder pour avoir une réplication de l'annuaire Ldap sur un autre serveur pour obtenir une haute disponibilité en cas de défaillance des systèmes. Enfin, est abordé un exemple de configuration client qui utilise le service centralisé Ldap : la configuration du serveur Imap dovecot. Avertissement Cet article montre la faisabilité de la mise en place d'une synchronisation d'annuaire dans un contexte opérationnel d'une délégation. Cette solution peut s'appliquer également à un laboratoire ou une entité quelconque ayant à gérer des bases multiples d'utilisateurs. Pour avoir une vue complète du logiciel, il est conseillé de se reporter au wiki et à la documentation officielle des logiciels utilisés. Seul sont repris ici les éléments qui ont été déterminant dans les choix opérés. 1 Contexte Le parc des stations de travail de la délégation repose pour une grande part sur des PC intel disposant du système Microsoft Windows XP, en cours d'évolution vers du Windows Seven. Quelques stations dans le périmètre du service informatique sont montées en Linux station de travail (Ubuntu ou Fedora). Le parc serveur est lui aussi hétérogène, il se compose de 2 serveurs bureautiques en Windows 2008r2, un serveur d'application TSE en Windows 2003, un serveur de fichier en Windows 2008r2, et d'une quinzaine de serveurs linux sous Fedora ou CentOS. Pour des raisons de simplification, le système de stockage et de sauvegarde des données n'est pas décrit ici. Les premiers serveurs bureautiques fournis par la DSI du CNRS dans les années 1990 étaient des serveurs NT. Ils ont suivi l'évolution technologique. Ils ont été upgradés en Windows 2000, puis en Windows2003 et enfin récemment en Windows Lors de ces évolutions nous avons toujours conservé la base des utilisateurs de la délégation dans le système Windows qui depuis Windows 2000, est stocké dans un annuaire ldap un peu particulier : l'active Directory (AD). Au sein de la délégation nous gérons un certain nombre de services sur les serveurs linux ou les stations linux qui nécessitent une authentification des utilisateurs internes. C'est le cas en particulier du système de messagerie pour la délégation qui est monté avec du postfix, dovecot etc... L'unification de la base des utilisateurs présents dans l'ad et dans de multiples systèmes linux est devenue pour nous un enjeux important afin de ne pas avoir à gérer des bases redondantes comme c'était le cas pour nous jusque dans les années Brouillon version n 1 1/21

2 2 Objectifs L'objectif initial a été d'avoir un seul point de gestion et de création des utilisateurs. Historiquement la population de la délégation est composée d'un ensemble d'utilisateurs «internes» et d'un ensemble d'utilisateurs «externes». Les utilisateurs «internes» -typiquement les utilisateurs présents dans l'ad- ont accès aux ressources bureautiques et communes ; les utilisateurs «externes» ne doivent pas avoir accès aux ressources bureautiques internes pour des raisons de confidentialités des données mais ont accès à diverses ressources sur les systèmes, tels que des services virtuels comme la messagerie. Parmi les utilisateurs «internes», certains doivent avoir accès à des ressources Unix et doivent donc disposer de comptes Unix. Jusqu'à récemment, Les utilisateurs de l'ad étaient dupliqués manuellement dans des bases d'utilisateurs Unix entrainant une double gestion des comptes. Pour parer ces inconvénients, s'est dessinée l'idée de gérer les utilisateurs interne dans l'ad, de les dupliquer et synchroniser automatiquement dans une base jumelée qui contiendrait en plus les utilisateurs externes. Le point important est l'automaticité du processus de synchronisation des bases. Schéma des multiples bases et migration souhaitée 3 Choix de la base Ldap Nous avons fait un peu de veille technologique sur la synchronisation de base AD et de base Ldap. A l'époque diverses solutions existaient : Le script CGI écrit en php permettant un point unique de création des utilisateurs en poussant vers deux bases OpenLdap et AD les utilisateurs, Des méta-annuaires se tourner vers les PAM (plugable Authentication Module) pour les services Unix faire l'authentification directement sur l'ad pour les services Unix à base de winbind ou d'authentification sur l'ad comme cette solution 1 Toutes ces solutions présentaient des avantages mais aussi des inconvénients importants : comment résoudre le problème de la divergence des bases et donc leur resynchronisation. Les applications de 1 Brouillon version n 1 2/21

3 méta-annuaire sont extrêmement lourdes à mettre en place et surtout la gestion des utilisateurs externes aurait reposé finalement sur un nouvel annuaire ldap, le méta-annuaire ne faisant qu'intégrer les deux annuaires. Notre choix s'est finalement porté sur le logiciel 389 Directory Server (389DS) -qui à l'époque répondait au nom de Redhat Fedora CentOS Directory Server- intégrant dans son cœur la synchronisation de base de l'ad vers le serveur 389DS et de façon bijective. Projet extrêmement bien documenté en langue anglaise qui est supporté par la société RedHat et par une large communauté. Seul persistait le problème de la synchronisation des mots de passe de l'ad qui, comme chacun sait, sont stockés sous forme crypté propriétaire dans la base AD et dont il n'est pas possible de retrouver ni le texte clair ni de l'utiliser dans la base 389DS dont les cryptages sont différents. Les auteurs de 389DS ont pour ceci développés un plugin -certains diront une glue- à disposer sur les serveurs Windows pour assurer la synchronisation du mot de passe lors du changement de celui-ci par les utilisateurs. La configuration de ce plugin sera vu au chapitre 7. Rester à monter ce système de synchronisation entre l'ad et la base 389DS en minimisant les interventions sur les serveurs Windows. 4 Configuration de 389DS 4.1 L'installation du logiciel La plateforme du serveur étant une Fedora, l'installation est triviale avec yum install : 389-admin.x86_ admin-console.noarch 389-admin-console-doc.noarch 389-adminutil.x86_ console.noarch 389-ds.noarch 389-ds-base.x86_ ds-console.noarch 389-ds-console-doc.noarch 389-dsgw.x86_ La configuration initiale Une fois les paquets installés, il faut passer à la configuration de 389ds en lançant le script : setup-ds-admin.pl soit on répond en interactif aux questions posées, soit on lance les options en argument de la ligne de commande. Toutefois avant de lancer le script, il faut préparer les éléments de configuration Eléments de configuration Le Fully-qualified Domain Name : ici pour notre serveur nous avons un serveur aragon dans le domaine dr15.cnrs.fr soit la machine au nom complet : aragon.dr15.cnrs.fr. Le numéro de port : nous avons choisi de conserver pour ldap et ldaps les numéros standards 389 et 636, ainsi que le numéro par défaut 9830 pour l'administration du serveur. Dans un premier temps de configuration, nous n'avons monté que ldap sur le port 389, c'est dans un deuxième temps que nous avons configuré ldaps sur le port 636 avec l'insertion du certificat serveur X509. Le manager de l'annuaire : nous avons conservé les options par défaut : cn=directory Manager L'administrateur du serveur par defaut : admin Brouillon version n 1 3/21

4 Le suffixe racine de l'annuaire : ici la difficulté commence sur le choix du suffixe et les implications avec les bases de données sous-jacentes, la relation avec l'ad et la synchronisation des bases. Historiquement et pour des raisons très logiques non abordées ici, l'administrateur du domaine des serveurs Windows a défini le suffixe dc=ad,dc=dr15,dc=cnrs,dc=fr. Sous ce suffixe, il existe une branche ou=dr15 sous laquelle nous avons ou=utilisateur pour la base des utilisateurs et ou=groupes pour les groupes. Ainsi pour les groupes nous avons : ou=groupes,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr Il aurait été possible de choisir le même suffixe racine de l'ad pour le 389ds, néanmoins le choix s'est porté sur dc=dr15,dc=cnrs,dc=fr, ainsi le suffixe correspond par défaut au nom de domaine de notre réseau. Une autre raison a poussé à faire ce choix : la synchronisation avec l'ad se fera sur la branche ou=dr15 avec une base de données 'DR15', il semblait correct de pouvoir peupler la branche supérieure dc=ad sur le serveur 389DS avec une base de données 'ad' distincte. La discussion sur ce choix reste ouverte Fin de l'installation Une fois le script exécuté, on peut jeter un œil sur le système pour voir où sont installés les fichiers du serveur : # tree -L 1 /etc/dirsrv /etc/dirsrv -- admin-serv -- config -- dsgw -- schema `-- slapd-aragon 5 directories, 0 files # tree -L 1 /var/lib/dirsrv/slapd-aragon/ /var/lib/dirsrv/slapd-aragon/ -- bak -- changelogdb -- db -- ldif `-- ldifdr15.ldif 4 directories, 1 file 4.3 Configuration graphique Le serveur en place, nous pouvons passer à la configuration avec la console graphique ou pour les afficionados de la ligne de commande configurer par insertion de fichier ldif ou de ldapmodify. Dans ce qui suit, nous présenterons la console graphique. Java est nécessaire pour faire tourner la console, l'openjdk convient pour ceci. Brouillon version n 1 4/21

5 Le lancement de la console se fait en lançant : 389-console S'ouvre une console d'authentification : Il faut saisir le mot de passe précédemment saisi dans la phase du script de configuration ce qui permet d'ouvrir un premier écran de choix entre l'administration et le serveur d'annuaire. A dire vrai, ouvrir la console de l'administration du serveur et rarement nécessaire voire jamais. Ce qui nous intéresse est donc la console du serveur d'annuaire. Brouillon version n 1 5/21

6 Voici un résumé des différentes tâches possibles sur le serveur, En fait le start/stop est aussi plus simple par ligne de commande avec services start/stop. Gérer les certificats, dans le contexte du CNRS qui dispose de sa propre IGC est plus simple avec les commandes netscape certutil. L'import/export de fichier ldif peut se faire avec les outils mozilla ldap. Reste éventuellement les backup/restore Création des bases Ce qui nous intéresse comme précédemment dit dans le chapitre sur les éléments de configuration est la réplication des bases de l'ad et de 389. De même la possibilité d'avoir une base d'utilisateurs indépendantes de l'ad dans la branche ad permettra de gérer les utilisateurs externes. Ainsi sur le 389ds, dans le suffixe racine, créé lors de l'installation, on va créer une branche dc=ad avec une base ad et une sous branche ou=dr15 avec une base DR15. Voir le schéma récapitulatif des branches de l'ad et du 389DS suivant. Brouillon version n 1 6/21

7 Dans l'onglet configuration, ceci revient à créer un nouveau suffixe dc=ad avec une base 'ad'. Puis sous cette branche, de répéter l'opération avec le suffixe ou=dr15 Les nouveaux suffixes sont listés sous le dossier Data (voir figure). Brouillon version n 1 7/21

8 Pour finir, il reste à définir les Unités Organisationelles, OU=utilisateurs et OU=Groupes, sous la branche ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr pour avoir un arbre de réplication similaire entre l'ad et le 389ds. Ceci se fait dans l'onglet Directory en créant un nouvel Organizational Unit (OU). A ce stade nous avons un serveur ldap opérationnel qui écoute sur le port 389, même si le peuplement des utilisateurs n'est pas encore effectué. Reste à activer SSL/TLS sur le serveur 389ds, ce qui nous permettra la synchronisation des mots de passe avec l'ad ; comme écrit dans l'avertissement initial, l'opération d'activer SSL sur le port 636 n'est pas décrite dans le présent article. Cette opération est décrite dans la documentation du projet. Pour la suite nous considérons que le serveur est opérationnel en ldap et ldaps. Brouillon version n 1 8/21

9 5 Synchronisation de l'ad et de 389DS La synchronisation nécessite l'activation de ldaps sur l'ad. L'installation d'un certificat valide sur un contrôleur de domaine permet au service LDAP d'écouter, et d'accepter automatiquement, les connexions SSL pour le trafic LDAP sur le port 636. Pour de plus ample information sur la configuration du serveur Windows, on peut se reporter à la base de connaissance de Microsoft : Dans le détail, une simple connexion ldap peut suffire pour synchroniser les entrées utilisateurs et groupes mais pour synchroniser les mots de passe il est impératif de disposer de ldaps sur le 389ds et sur le serveur windows. Peupler l'annuaire 389 avec les données utilisateurs de la base AD, revient à initier une synchronisation complète. Il faut configurer le serveur 389 pour faire un replica. 1ère étape : activer le Changelog dans l'onglet configuration dossier Replication 2 ème étape : Sélectionner la base à répliquer, ici DR15 : Activer le replica en Rôle Single master ou Multi Master et ajouter le DN du fournisseur courant. Brouillon version n 1 9/21

10 3 ème étape : Dans l'onglet Configuration, le Folder Replication puis la Base, avec le clic droit Créer un nouvel agrément de synchronisation. Un assistant s'ouvre pour aider à remplir les différents champs. En synthèse nous avons la figure suivante : Brouillon version n 1 10/21

11 Lors de la saisie du Bind as, il est nécessaire de choisir un utilisateur de l'ad ayant les droits de parcourir l'ad, ici nous avons choisi le compte administrateur qui disposent de droit vraiment étendu, il est toutefois préférable de créer un nouvel utilisateur pour cette opération. 4 ème étape : sous la BASE est crée un agrément de synchronisation, un clic droit sur cet agrément permet d'initier une synchronisation complète : Le 389ds va alors se peupler des groupes et utilisateurs de l'ad. En résultat : dans l'onglet Directory sur le folder de l'unité organisationnelle de l'ou=groupes,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr nous voyons apparaître les données Brouillon version n 1 11/21

12 Les utilisateurs sont ainsi synchronisés avec le serveur Ldap, toutefois le mots de passe initialement présent sur l'ad n'a pas été transmis vers le serveur 389ds. 6 Mise à jour des mots de passe 6.1 Installer sur les serveurs Windows le programme Passync.msi Le projet 389ds fournit un programme Passync.msi qui s'installe sur les serveurs Windows. Programme bien documenté, il nécessite l'installation du certificat du serveur avec les programme certutil de Mozilla. Ce programme qui tourne comme un service sur les serveurs Windows AD capture le mot de passe en clair lors du changement de celui-ci par un utilisateur et l'envoie au serveur 389ds pour mettre à jour l'attribut correspondant. La configuration des paramètres ne posent pas de problème particulier, lors de l'installation : 6.2 Une organisation auprès des utilisateurs Si l'installation du 389ds est concomitante à l'installation des contrôleurs de domaine Windows et au début du peuplement des utilisateurs, il suffit d'ajouter les utilisateurs dans un des annuaires pour qu'ils soient propagés sur l'autre. Toutefois si l'installation du 389ds est postérieur à l'installation de l'ad, ce qui était notre cas, il devient nécessaire de ré-initialiser les mots de passe sur le serveur de l'ad pour qu'ils soient propagés. Localement, nous avons prévu une information aux utilisateurs sur la nécessité de choisir un mot de passe à protection forte et nous les avons forcés à changer le mot de passe selon la nouvelle politique de sécurité des mots de passe. Cette politique de changement de mot de passe a permis de peupler le 389ds de l'intégralité des nouveaux mots de passe. Brouillon version n 1 12/21

13 7 Peupler le 389ds des comptes Unix Le 389 est maintenant peuplé des comptes Windows, il reste à le peupler des comptes Unix divers soit provenant de la base NIS, soit des fichiers systèmes à plat tel que /etc/password. L'opération se fait facilement avec les outils de migration que l'on trouve sur internet ou bien avec les outils openldap. 8 Gérer les comptes avec la console graphique Il est bien entendu possible de gérer les utilisateurs sur le 389ds, dans l'onglet annuaire, après avoir déplier les folders, sur les propriétés : Le panneau d'information de l'utilisateur s'affiche Brouillon version n 1 13/21

14 Il est possible de naviguer dans les autres propriétés Windows : Ainsi que les propriétés Posix pour les utilisateurs unix : Brouillon version n 1 14/21

15 Pour un utilisateur non Unix, les attributs sont vides : Brouillon version n 1 15/21

16 9 Réplication de 389DS On peut souhaiter disposer d'un nouveau serveur qui soit la réplication du premier. Ceci permet entre autre de palier au défaillance d'un serveur. Dans le cas qui nous préoccupe, nous avons un serveur principal en écriture, déjà lui-même réplique de la base AD. L'ajout d'un réplica peut se faire en mode écriture complète ou bien en mode lecture seule, le serveur est alors un simple consommateur des données sans qu'il soit possible de modifier les données sur ce serveur. Dans le cas présent le serveur principal sera fournisseur, le nouveau serveur sera un consommateur dédié. Le schéma souhaité ressemble simplement à ceci : 9.1 Monter un nouveau serveur La réplication sur un nouveau serveur nécessite de monter celui-ci. L'opération est explicitée dans le chapitre Ajuster les paramètres de réplication Le premier serveur est constitué de deux bases, l'une 'ad' et l'autre 'DR15'. Comme nous voulons l'intégralité du serveur il sera nécessaire de répliquer les deux bases. Sur le serveur fournisseur des ressources, l'activation du changelog est déjà établie puisqu'il est déjà configuré comme réplique de la base de l'ad. Il nous reste à activer le replica pour la base ad et pour la base DR15 en multi-master ou bien single master. Sur le consommateur, il suffit d'activer le replica en tant que consommateur dédié. Dans les paramètres de mise à jour, nous saisirons un utilisateur particulier -manager de replication- créé spécialement pour l'occasion sur le fournisseur et introduit dans le champs supplier DN. 9.3 Agrément de Replication Sur le fournisseur, sur chaque base, nous créons un nouvel agrément de réplication, ce qui lance un assistant dans lequel nous indiquons le consommateur, le type de connexion (ldap, ldaps,tls/ssl), l'utilisateur de connexion, le planning de synchronisation etc... Puis nous initialisons le consommateur qui va se peupler des données du fournisseur et permettre la synchronisation. Brouillon version n 1 16/21

17 10 Exemple de configuration client 10.1 L'authentification d'un client imap dovecot Notre système de messagerie comporte différents modules que l'on peut résumer selon le schéma suivant : Les utilisateurs disposent de compte virtuel de mail sur le serveur. Le mécanisme de lecture du mail en imap avec le logiciel dovecot suppose de vérifier l'utilisateur et son mot de passe dans la base ldap. Ainsi nous aurons comme fichier de configuration : /etc/dovecot.conf : Brouillon version n 1 17/21

18 # LDAP database <doc/wiki/authdatabase.ldap.txt> passdb ldap { args = /etc/dovecot-ldap.conf } userdb ldap { args = /etc/dovecot-ldap.conf } et un fichier /etc/dovecot-ldap.conf hosts = briand.dr15.cnrs.fr base = dc=ad,dc=dr15,dc=cnrs,dc=fr ldap_version = 3 auth_bind = yes scope = subtree user_attrs = uid=home=/home/vmail/%l$/, =gid=vmail,=uid=vmail user_filter = (&(objectclass=person)( (mail=%u)(uid=%u))) pass_attrs = uid=user pass_filter = (&(objectclass=person)(uid=%u)) 10.2 Requête ldapsearch Pour finir, il est toujours possible d'utiliser la ligne de commande pour interroger, modifier l'annuaire. Voici un extrait du résultat d'une commande ldapsearch sur l'annuaire AD et sur l'annuaire 389DS : sur l'ad : $ ldapsearch -x -D "cn=administrateur,cn=users,dc=ad,dc=dr15,dc=cnrs,dc=fr" -W -h 15srvad -b "ou=utilisateurs,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr" samaccountname=chardron # extended LDIF # # LDAPv3 # base <ou=utilisateurs,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr> with scope subtree # filter: samaccountname=chardron # requesting: ALL # # Chardron, utilisateurs, DR15, ad.dr15.cnrs.fr dn: CN=Chardron,OU=utilisateurs,OU=DR15,DC=ad,DC=dr15,DC=cnrs,DC=fr objectclass: top objectclass: person objectclass: organizationalperson objectclass: user cn: Chardron sn: Chardron c: FX ou: STI Brouillon version n 1 18/21

19 postalcode: physicaldeliveryofficename:: bskwidixmiayw6htzsbldgfnzq== telephonenumber: facsimiletelephonenumber: givenname: Jean-Noel initials: jnc distinguishedname: CN=Chardron,OU=utilisateurs,OU=DR15,DC=ad,DC=dr15,DC=cnrs,DC=fr instancetype: 4 whencreated: Z whenchanged: Z displayname: Chardron usncreated: 9276 memberof:cn=reglement,ou=groupes,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc= fr memberof: CN=dr15,OU=groupes,OU=DR15,DC=ad,DC=dr15,DC=cnrs,DC=fr memberof: CN=Utilisa. Du domaine,cn=users,dc=ad,dc=dr15,dc=cnrs,dc=fr usnchanged: co:: RlJBTkNFIE3DiVRST1BPTElUQUlORQ== department: STI company: CNRS name: Chardron objectguid:: wqc5c9nmn0yoshtekvhjlw== useraccountcontrol: badpwdcount: 0 codepage: 0 countrycode: 249 badpasswordtime: lastlogoff: 0 lastlogon: pwdlastset: primarygroupid: 1863 objectsid:: AQUAAAAAAAUVAAAA/OMVMUTduD1DFwoy+QcAAA== admincount: 1 accountexpires: logoncount: 104 samaccountname: chardron samaccounttype: userprincipalname: chardron@ad.dr15.cnrs.fr lockouttime: 0 objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=dr15,DC=cnrs,DC=fr dscorepropagationdata: Z dscorepropagationdata: Z lastlogontimestamp: mail: Jean-Noel.Chardron@dr15.cnrs.fr manager: CN=rd,OU=utilisateurs,OU=DR15,DC=ad,DC=dr15,DC=cnrs,DC=fr # search result search: 2 result: 0 Success Brouillon version n 1 19/21

20 # numresponses: 2 # numentries: 1 sur le 389ds : $ ldapsearch -x -D "cn=directory Manager" -w -h aragon -b "dc=ad,dc=dr15,dc=cnrs,dc=fr" uid=chardron # extended LDIF # # LDAPv3 # base <dc=ad,dc=dr15,dc=cnrs,dc=fr> with scope subtree # filter: uid=chardron # requesting: ALL # # chardron, utilisateurs, DR15, ad.dr15.cnrs.fr dn: uid=chardron,ou=utilisateurs,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr userpassword:: e1nzozoubed1ekx1seloedzjalb2snpkuuq4quq5derknzvzznrrrhc9pq== ntuserlastlogon: telephonenumber: objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: ntuser objectclass: posixaccount objectclass: Vacation ntuserdeleteaccount: true uid: chardron sn: Chardron postalcode: physicaldeliveryofficename:: bskwidixmiayw6htzsbldgfnzq== givenname: Jean-Noel initials: jnc cn: Chardron ntusercodepage: 0 ntuseracctexpires: ntuserdomainid: chardron mail: Jean-Noel.Chardron@dr15.cnrs.fr ntuniqueid: c107390bd3669f4ca8b074de2af86397 ntuserlastlogoff: 0 manager: uid=rd,ou=utilisateurs,ou=dr15,dc=ad,dc=dr15, dc=cnrs, dc=fr uidnumber: gidnumber: 2000 homedirectory: /home/dr15/chardron loginshell: /bin/bash facsimiletelephonenumber: secretary: uid=chardron,ou=utilisateurs,ou=dr15,dc=ad,dc=dr15,dc=cnrs,dc=fr Brouillon version n 1 20/21

21 vacationactive: FALSE vacationinfo:: PHA+Qm9uam91cjwvcD4NCjxwPkplIHN1aXMgYWJzZW50IGp1c3F1J2F1IDI4IEY mzwfjdxrlo3zyawvyidiwmteupc9wpg0kpha+rw4gy2fzigqndxjnzw5jzsb2b3vz IHBvdXZleiBj7PC9wPg== businesscategory: IE1 ou: STI search: 2 result: 0 Success # numresponses: 2 # numentries: 1 11 Conclusion L'annuaire 389DS fonctionne à la délégation depuis maintenant 3 ans. Il a permis d'assurer la synchronisation avec un annuaire Windows Active Directory. La solution mise en œuvre est simple. L'ergonomie graphique du logiciel est assez intuitive pour pouvoir se repérer facilement. Il a permis une gestion centralisée et simple des comptes utilisateurs sur lequel reposent l'ensemble des authentifications. Il permet de mettre en œuvre assez aisément des réplications de l'annuaire. Ce service d'annuaire, nous a permis, dans un second temps, de monter un service central d'authentification unique (CAS) pour accéder aux applications web intranet authentifiées. Mais ceci est une autre histoire. Brouillon version n 1 21/21