Vous êtes sur la page 1sur 21

Synchronisation d'annuaire Active Directory et de base LDAP

Auteur : Jean-Nol Chardron Dlgation rgionale d'Aquitaine-Limousin Jean-Noel.Chardron@dr15.cnrs.fr Le 14 avril 2011

Rsum 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 dcrirons le choix du logiciel et succinctement son paramtrage. Dans un deuxime temps nous montrons comment procder pour avoir une rplication de l'annuaire Ldap sur un autre serveur pour obtenir une haute disponibilit en cas de dfaillance des systmes. 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 oprationnel d'une dlgation. Cette solution peut s'appliquer galement un laboratoire ou une entit quelconque ayant grer des bases multiples d'utilisateurs. Pour avoir une vue complte du logiciel, il est conseill de se reporter au wiki et la documentation officielle des logiciels utiliss. Seul sont repris ici les lments qui ont t dterminant dans les choix oprs. 1 Contexte Le parc des stations de travail de la dlgation repose pour une grande part sur des PC intel disposant du systme Microsoft Windows XP, en cours d'volution vers du Windows Seven. Quelques stations dans le primtre du service informatique sont montes en Linux station de travail (Ubuntu ou Fedora). Le parc serveur est lui aussi htrogne, 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 systme de stockage et de sauvegarde des donnes n'est pas dcrit ici. Les premiers serveurs bureautiques fournis par la DSI du CNRS dans les annes 1990 taient des serveurs NT. Ils ont suivi l'volution technologique. Ils ont t upgrads en Windows 2000, puis en Windows2003 et enfin rcemment en Windows 2008. Lors de ces volutions nous avons toujours conserv la base des utilisateurs de la dlgation dans le systme Windows qui depuis Windows 2000, est stock dans un annuaire ldap un peu particulier : l'Active Directory (AD). Au sein de la dlgation nous grons un certain nombre de services sur les serveurs linux ou les stations linux qui ncessitent une authentification des utilisateurs internes. C'est le cas en particulier du systme de messagerie pour la dlgation qui est mont avec du postfix, dovecot etc... L'unification de la base des utilisateurs prsents dans l'AD et dans de multiples systmes linux est devenue pour nous un enjeux important afin de ne pas avoir grer des bases redondantes comme c'tait le cas pour nous jusque dans les annes 2008.

Brouillon version n 1

1/21

2 Objectifs L'objectif initial a t d'avoir un seul point de gestion et de cration des utilisateurs. Historiquement la population de la dlgation est compose d'un ensemble d'utilisateurs internes et d'un ensemble d'utilisateurs externes . Les utilisateurs internes -typiquement les utilisateurs prsents dans l'AD- ont accs aux ressources bureautiques et communes ; les utilisateurs externes ne doivent pas avoir accs aux ressources bureautiques internes pour des raisons de confidentialits des donnes mais ont accs diverses ressources sur les systmes, tels que des services virtuels comme la messagerie. Parmi les utilisateurs internes , certains doivent avoir accs des ressources Unix et doivent donc disposer de comptes Unix. Jusqu' rcemment, Les utilisateurs de l'AD taient dupliqus manuellement dans des bases d'utilisateurs Unix entrainant une double gestion des comptes. Pour parer ces inconvnients, s'est dessine l'ide de grer les utilisateurs interne dans l'AD, de les dupliquer et synchroniser automatiquement dans une base jumele qui contiendrait en plus les utilisateurs externes. Le point important est l'automaticit du processus de synchronisation des bases.

Schma des multiples bases et migration souhaite 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 cration des utilisateurs en poussant vers deux bases OpenLdap et AD les utilisateurs, Des mta-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 prsentaient des avantages mais aussi des inconvnients importants : comment rsoudre le problme de la divergence des bases et donc leur resynchronisation. Les applications de
1 http://www.aquitaine-limousin.cnrs.fr/spip.php?article756

Brouillon version n 1

2/21

mta-annuaire sont extrmement lourdes mettre en place et surtout la gestion des utilisateurs externes aurait repos finalement sur un nouvel annuaire ldap, le mta-annuaire ne faisant qu'intgrer les deux annuaires. Notre choix s'est finalement port sur le logiciel 389 Directory Server (389DS) -qui l'poque rpondait au nom de Redhat|Fedora|CentOS Directory Server- intgrant dans son cur la synchronisation de base de l'AD vers le serveur 389DS et de faon bijective. Projet extrmement bien document en langue anglaise qui est support par la socit RedHat et par une large communaut. Seul persistait le problme de la synchronisation des mots de passe de l'AD qui, comme chacun sait, sont stocks sous forme crypt propritaire 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 diffrents. Les auteurs de 389DS ont pour ceci dvelopps 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 systme 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_64 389-admin-console.noarch 389-admin-console-doc.noarch 389-adminutil.x86_64 389-console.noarch 389-ds.noarch 389-ds-base.x86_64 389-ds-console.noarch 389-ds-console-doc.noarch 389-dsgw.x86_64 4.2 La configuration initiale

Une fois les paquets installs, il faut passer la configuration de 389ds en lanant le script : setup-ds-admin.pl soit on rpond en interactif aux questions poses, soit on lance les options en argument de la ligne de commande. Toutefois avant de lancer le script, il faut prparer les lments de configuration. 4.2.1 Elments 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 numro de port : nous avons choisi de conserver pour ldap et ldaps les numros standards 389 et 636, ainsi que le numro par dfaut 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 deuxime 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 dfaut : cn=Directory Manager L'administrateur du serveur par defaut : admin Brouillon version n 1 3/21

Le suffixe racine de l'annuaire : ici la difficult commence sur le choix du suffixe et les implications avec les bases de donnes sous-jacentes, la relation avec l'AD et la synchronisation des bases. Historiquement et pour des raisons trs logiques non abordes ici, l'administrateur du domaine des serveurs Windows a dfini 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 mme suffixe racine de l'AD pour le 389ds, nanmoins le choix s'est port sur dc=dr15,dc=cnrs,dc=fr, ainsi le suffixe correspond par dfaut au nom de domaine de notre rseau. Une autre raison a pouss faire ce choix : la synchronisation avec l'AD se fera sur la branche ou=DR15 avec une base de donnes 'DR15', il semblait correct de pouvoir peupler la branche suprieure dc=ad sur le serveur 389DS avec une base de donnes 'ad' distincte. La discussion sur ce choix reste ouverte. 4.2.2 Fin de l'installation

Une fois le script excut, on peut jeter un il sur le systme pour voir o sont installs 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 prsenterons la console graphique. Java est ncessaire pour faire tourner la console, l'openjdk convient pour ceci. Brouillon version n 1 4/21

Le lancement de la console se fait en lanant : 389-console S'ouvre une console d'authentification :

Il faut saisir le mot de passe prcdemment 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 ncessaire voire jamais. Ce qui nous intresse est donc la console du serveur d'annuaire.

Brouillon version n 1

5/21

Voici un rsum des diffrentes tches possibles sur le serveur, En fait le start/stop est aussi plus simple par ligne de commande avec services start/stop. Grer 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.

4.3.1

Cration des bases

Ce qui nous intresse comme prcdemment dit dans le chapitre 4.2.1 sur les lments de configuration est la rplication des bases de l'AD et de 389. De mme la possibilit d'avoir une base d'utilisateurs indpendantes de l'AD dans la branche ad permettra de grer les utilisateurs externes. Ainsi sur le 389ds, dans le suffixe racine, cr lors de l'installation, on va crer une branche dc=ad avec une base ad et une sous branche ou=DR15 avec une base DR15. Voir le schma rcapitulatif des branches de l'AD et du 389DS suivant.

Brouillon version n 1

6/21

Dans l'onglet configuration, ceci revient crer un nouveau suffixe dc=ad avec une base 'ad'. Puis sous cette branche, de rpter l'opration avec le suffixe ou=DR15

Les nouveaux suffixes sont lists sous le dossier Data (voir figure).

Brouillon version n 1

7/21

Pour finir, il reste dfinir les Units Organisationelles, OU=utilisateurs et OU=Groupes, sous la branche ou=DR15,dc=ad,dc=dr15,dc=cnrs,dc=fr pour avoir un arbre de rplication similaire entre l'AD et le 389ds. Ceci se fait dans l'onglet Directory en crant un nouvel Organizational Unit (OU). A ce stade nous avons un serveur ldap oprationnel qui coute sur le port 389, mme 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'opration d'activer SSL sur le port 636 n'est pas dcrite dans le prsent article. Cette opration est dcrite dans la documentation du projet. Pour la suite nous considrons que le serveur est oprationnel en ldap et ldaps. Brouillon version n 1 8/21

5 Synchronisation de l'AD et de 389DS La synchronisation ncessite l'activation de ldaps sur l'AD. L'installation d'un certificat valide sur un contrleur 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 : http://support.microsoft.com/kb/321051 Dans le dtail, une simple connexion ldap peut suffire pour synchroniser les entres utilisateurs et groupes mais pour synchroniser les mots de passe il est impratif de disposer de ldaps sur le 389ds et sur le serveur windows. Peupler l'annuaire 389 avec les donnes utilisateurs de la base AD, revient initier une synchronisation complte. Il faut configurer le serveur 389 pour faire un replica. 1re tape : activer le Changelog dans l'onglet configuration dossier Replication

2 me tape : Slectionner la base rpliquer, ici DR15 : Activer le replica en Rle Single master ou Multi Master et ajouter le DN du fournisseur courant.

Brouillon version n 1

9/21

3 me tape : Dans l'onglet Configuration, le Folder Replication puis la Base , avec le clic droit Crer un nouvel agrment de synchronisation. Un assistant s'ouvre pour aider remplir les diffrents champs. En synthse nous avons la figure suivante :

Brouillon version n 1

10/21

Lors de la saisie du Bind as, il est ncessaire 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 prfrable de crer un nouvel utilisateur pour cette opration. 4 me tape : sous la BASE est cre un agrment de synchronisation, un clic droit sur cet agrment permet d'initier une synchronisation complte : Le 389ds va alors se peupler des groupes et utilisateurs de l'AD. En rsultat : 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 apparatre les donnes

Brouillon version n 1

11/21

Les utilisateurs sont ainsi synchroniss avec le serveur Ldap, toutefois le mots de passe initialement prsent 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 ncessite 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 paramtres ne posent pas de problme particulier, lors de l'installation :

6.2

Une organisation auprs des utilisateurs

Si l'installation du 389ds est concomitante l'installation des contrleurs de domaine Windows et au dbut du peuplement des utilisateurs, il suffit d'ajouter les utilisateurs dans un des annuaires pour qu'ils soient propags sur l'autre. Toutefois si l'installation du 389ds est postrieur l'installation de l'AD, ce qui tait notre cas, il devient ncessaire de r-initialiser les mots de passe sur le serveur de l'AD pour qu'ils soient propags. Localement, nous avons prvu une information aux utilisateurs sur la ncessit de choisir un mot de passe protection forte et nous les avons forcs changer le mot de passe selon la nouvelle politique de scurit des mots de passe. Cette politique de changement de mot de passe a permis de peupler le 389ds de l'intgralit des nouveaux mots de passe.

Brouillon version n 1

12/21

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 systmes plat tel que /etc/password. L'opration se fait facilement avec les outils de migration que l'on trouve sur internet ou bien avec les outils openLdap. 8 Grer les comptes avec la console graphique Il est bien entendu possible de grer les utilisateurs sur le 389ds, dans l'onglet annuaire, aprs avoir dplier les folders, sur les proprits :

Le panneau d'information de l'utilisateur s'affiche

Brouillon version n 1

13/21

Il est possible de naviguer dans les autres proprits Windows :

Ainsi que les proprits Posix pour les utilisateurs unix :

Brouillon version n 1

14/21

Pour un utilisateur non Unix , les attributs sont vides :

Brouillon version n 1

15/21

9 Rplication de 389DS On peut souhaiter disposer d'un nouveau serveur qui soit la rplication du premier. Ceci permet entre autre de palier au dfaillance d'un serveur. Dans le cas qui nous proccupe, nous avons un serveur principal en criture, dj lui-mme rplique de la base AD. L'ajout d'un rplica peut se faire en mode criture complte ou bien en mode lecture seule, le serveur est alors un simple consommateur des donnes sans qu'il soit possible de modifier les donnes sur ce serveur. Dans le cas prsent le serveur principal sera fournisseur, le nouveau serveur sera un consommateur ddi. Le schma souhait ressemble simplement ceci :

9.1

Monter un nouveau serveur

La rplication sur un nouveau serveur ncessite de monter celui-ci. L'opration est explicite dans le chapitre 4. 9.2 Ajuster les paramtres de rplication

Le premier serveur est constitu de deux bases, l'une 'ad' et l'autre 'DR15'. Comme nous voulons l'intgralit du serveur il sera ncessaire de rpliquer les deux bases. Sur le serveur fournisseur des ressources, l'activation du changelog est dj tablie puisqu'il est dj configur comme rplique 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 ddi. Dans les paramtres de mise jour, nous saisirons un utilisateur particulier -manager de replication- cr spcialement pour l'occasion sur le fournisseur et introduit dans le champs supplier DN. 9.3 Agrment de Replication

Sur le fournisseur, sur chaque base, nous crons un nouvel agrment de rplication, 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 donnes du fournisseur et permettre la synchronisation.

Brouillon version n 1

16/21

10 10.1

Exemple de configuration client L'authentification d'un client imap dovecot

Notre systme de messagerie comporte diffrents modules que l'on peut rsumer selon le schma suivant :

Les utilisateurs disposent de compte virtuel de mail sur le serveur. Le mcanisme de lecture du mail en imap avec le logiciel dovecot suppose de vrifier 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

# 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 Requte ldapsearch

Pour finir, il est toujours possible d'utiliser la ligne de commande pour interroger, modifier l'annuaire. Voici un extrait du rsultat 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

postalCode: 33402 physicalDeliveryOfficeName:: bsKwIDIxMiAyw6htZSBldGFnZQ== telephoneNumber: 05.57.35.58.00 facsimileTelephoneNumber: 05.57.35.58.01 givenName: Jean-Noel initials: jnc distinguishedName: CN=Chardron,OU=utilisateurs,OU=DR15,DC=ad,DC=dr15,DC=cnrs,DC=fr instanceType: 4 whenCreated: 20050830085826.0Z whenChanged: 20110413144445.0Z 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: 3133945 co:: RlJBTkNFIE3DiVRST1BPTElUQUlORQ== department: STI company: CNRS name: Chardron objectGUID:: wQc5C9Nmn0yosHTeKvhjlw== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 249 badPasswordTime: 129473305569243281 lastLogoff: 0 lastLogon: 129473305569563281 pwdLastSet: 129471794853064678 primaryGroupID: 1863 objectSid:: AQUAAAAAAAUVAAAA/OMVMUTduD1DFwoy+QcAAA== adminCount: 1 accountExpires: 9223372036854775807 logonCount: 104 sAMAccountName: chardron sAMAccountType: 805306368 userPrincipalName: chardron@ad.dr15.cnrs.fr lockoutTime: 0 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=dr15,DC=cnrs,DC=fr dSCorePropagationData: 20110106142032.0Z dSCorePropagationData: 16010101000001.0Z lastLogonTimestamp: 129470091184290878 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

# 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: 129470692509621760 telephoneNumber: 05.57.35.58.00 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetOrgPerson objectClass: ntUser objectClass: posixAccount objectClass: Vacation ntUserDeleteAccount: true uid: chardron sn: Chardron postalCode: 33402 physicalDeliveryOfficeName:: bsKwIDIxMiAyw6htZSBldGFnZQ== givenName: Jean-Noel initials: jnc cn: Chardron ntUserCodePage: 0 ntUserAcctExpires: 9223372036854775807 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: 20269 gidNumber: 2000 homeDirectory: /home/dr15/chardron loginShell: /bin/bash facsimileTelephoneNumber: 05.57.35.58.01 secretary: uid=chardron,OU=utilisateurs,ou=DR15,dc=ad,dc=dr15,dc=cnrs,dc=fr Brouillon version n 1 20/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 dlgation 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 reprer facilement. Il a permis une gestion centralise et simple des comptes utilisateurs sur lequel reposent l'ensemble des authentifications. Il permet de mettre en uvre assez aisment des rplications de l'annuaire. Ce service d'annuaire, nous a permis, dans un second temps, de monter un service central d'authentification unique (CAS) pour accder aux applications web intranet authentifies. Mais ceci est une autre histoire.

Brouillon version n 1

21/21