Projet Tutoré Gestion des utilisateurs dans un environnement hétérogène L A TEX HINDERCHIETTE Aymeric - KILFIGER Estelle - SIMONET Charles - SIVADON Florian 1 Année 2014-2015
Contents Remerciements........................................ 3 L équipe............................................ 4 1 Introduction au projet tutoré............................. 5 2 Mise au point...................................... 5 3 Contexte - Présentation................................ 8 4 La problématique.................................... 8 5 Objectifs......................................... 8 6 Reformulation du sujet................................. 9 7 Définition du périmètre................................ 10 8 La mise en place des outils collaboratifs....................... 10 9 Déroulement temporel de notre projet........................ 11 9.1 Première semaine................................ 11 9.2 Seconde et troisième semaines......................... 11 9.3 Quatrième et cinquième semaines....................... 11 9.4 Reste du temps................................. 12 10 Travail d analyse, de recherche de notre solution.................. 12 10.1 Définition de l axe de recherche........................ 12 10.2 Solutions éventuelles.............................. 12 10.3 Centrify..................................... 12 10.4 Mandriva Directory Server.......................... 13 10.5 Microsoft Windows Services for Unix 3.5................... 13 10.6 Samba + LDAPScripts............................ 13 10.7 PhpLdapAdmin................................. 14 10.8 LDAP Synchronization Connector...................... 14 11 La solution retenue................................... 17 11.1 PhpLdapAdmin + LDAP Synchronisation Connector............ 17 12 PhpLdapAdmin - LSC, la mise en place de notre solution............. 19 12.1 Installation de OpenLDAP.......................... 19 12.2 Installation de Apache, PHP et PhpLdapAdmin.............. 19 12.3 Pré-requis pour LSC.............................. 20 12.4 Installation de LSC............................... 21 12.5 Configuration.................................. 21 12.6 Les modes de lancement de LSC....................... 25 12.7 Les tests..................................... 28 12.8 Sécurisation................................... 32 13 Pour résumer...................................... 34 14 Problèmes rencontrés.................................. 35 15 Suite du projet..................................... 36 16 Avis sur le projet.................................... 36 17 Bibliographie - Ressources............................... 37 18 Annexes......................................... 38 2
Remerciements Tout d abord, nous souhaiterions remercier l entreprise Pharmagest de nous avoir fourni une infrastructure de tests dans leurs locaux. MM. Yohan PARENT et Jérémie CEINTREY, nos tuteurs sur ce projet, de nous avoir accordé leur temps, leur aide et leurs précieux conseils avec une grande gentillesse, ainsi que M.OUDOT Clément, intégrateur et Community Manager du projet LSC, d avoir bien voulu répondre à nos questions avec sympathie. 3 Année 2014-2015
Composition de l équipe Etudiants Nom: Charles SIMONET Email: charles.simonet398@gmail.com Nom: Florian SIVADON Email: f.sivadon@gmail.com Nom: Estelle KILFIGER Email: e.kilfiger@laposte.net Nom: Aymeric HINDERCHIETTE Email: aymhinder@gmail.com Tuteurs Nom: Yohan PARENT Email: yohan.parent@gmail.com Nom: Jérémie CEINTREY Email: jeremie.ceintrey@pharmagest.com 4 Année 2014-2015
1 Introduction au projet tutoré Le sujet de notre projet tutoré, dans le cadre de la licence professionnelle ASRALL, est "Gestion des Utilisateurs dans un Environnement Hétérogène". Ce sujet nous a été proposé par MM. Yohan PARENT et Jérémie CEINTREY, de l entreprise Pharmagest. Notre travail a été réparti sur 8 semaines à mi-temps, de la semaine 4 (19 Janvier) jusqu au milieu de la semaine 13 (25 Mars), et sera conclu par une soutenance devant un jury et les autres groupes de projets tutorés de notre promotion. 2 Mise au point Avant de parler de l objectif de notre projet tutoré, il nous semble nécessaire de faire une petite mise au point sur les différents termes que nous allons utiliser. Annuaire: Les annuaires électroniques sont un type de base de données spécialisé permettant de stocker des informations de manière hiérarchique et offrant des mécanismes simples pour rechercher l information, la trier, l organiser selon un nombre limité de critères. Ainsi le but d un annuaire électronique est approximativement le même que celui d un annuaire papier, si ce n est qu il offre une grande panoplie de possibilités que les annuaires papier ne sauraient donner. Une base LDAP est optimisée pour la lecture d un nombre important de petits enregistrements et convient donc parfaitement pour stocker des annuaires ou des profils utilisateurs. L utilisation d annuaire ne se limite pas à la recherche de personnes ou de ressources. En effet, un annuaire peut servir à: constituer un carnet d adresses et authentifier des utilisateurs (grâce à un mot de passe) définir les droits de chaque utilisateur recenser des informations sur un parc matériel (ordinateurs, serveurs, leurs adresses IP et adresses MAC,...) décrire les applications disponibles. 5 Année 2014-2015
Les annuaires électroniques possèdent un grand nombre d avantages : Ils sont dynamiques: Un annuaire en ligne (disponible sur le réseau) sera à jour très rapidement, d autant plus que les ressources recensées dans l annuaire peuvent elles-mêmes modifier les informations les concernant (si elles sont habilitées à le faire). Ils sont sûrs: les annuaires en ligne disposent de mécanismes d authentification des utilisateurs grâce à un mot de passe et un nom d utilisateur ainsi que des règles d accès permettant de définir les branches de l annuaire auxquelles l utilisateur peut accéder. Ils sont souples: ils permettent ainsi de classer l information selon des critères multiples et variables. Chaque objet d un annuaire contient plusieurs attributs (obligatoires ou facultatifs). chaque objet peut hériter des attributs d un autre objet. Et Exemple: L objet «person» a comme attributs : commonname, surname,.. L objet fils «organizationalperson» dérivé de l objet «person» ajoute les attributs : title, PostalAddress,... Les objets et les attributs sont normalisés pour assurer les échanges entre les logiciels. Il est possible de modifier un schéma en rajoutant des attributs à un objet (déconseillé) ou en créant un nouvel objet (mieux). Chaque donnée enregistrée dans la base est identifiée par son DN (Distinguished Name). Ce DN est comparable au chemin complet d un fichier. Exemple : dc=mondomaine,dc=fr Pour ajouter ou modifier des données dans la base, il est possible d utiliser le format LDIF. LDIF (LDAP Data Interchange Format) : LDIF est un format standardisé d échange de données, qui permet la représentation des données contenues dans un annuaire LDAP. Il permet également la représentation d opérations sur les données de l annuaire (ajout, suppression, modification). Une entrée peut ressembler à la représentation suivante lorsqu elle est formatée en LDIF : 6 Année 2014-2015
Dans cet exemple, dn est le nom de l entrée, ce n est pas un attribut de l entrée. "cn=john Doe" est le RDN de l entrée et "dc=example,dc=org" est le DN de son parent. Les autres lignes montrent les attributs de l entrée. Les noms des attributs sont parfois des abréviations pour les plus courants : cn pour common name, dc pour domain component, sn pour surname. Lightweight Directory Access Protocol (LDAP): L implémentation peut être totalement différente d un serveur à un autre, c est pourquoi il a été nécessaire de définir une interface normalisée permettant d accéder de façon standard aux différents services de l annuaire. C est le rôle du protocole LDAP (Lightweight Directory Access Protocol), qui va fournir un moyen unique (standard ouvert) d effectuer des requêtes sur un annuaire (compatible LDAP). Synchronisation/réplication: Processus de partage d informations pour assurer la cohérence de données entre plusieurs sources de données redondantes, pour améliorer la fiabilité, la tolérance aux pannes, ou la disponibilité. Lorsqu un utilisateur est ajouté, modifié, ou supprimé à l endroit A, le processus de synchronisation entre A et B ajoutera, modifiera, ou supprimera le même utilisateur à l endroit B. 7 Année 2014-2015
3 Contexte - Présentation Pharmagest est une entreprise Française située à Villers-lès-Nancy. Elle est spécialisée dans le développement et la commercialisation de solutions informatiques professionnelles pour l industrie pharmaceutique. Partenaire privilégié des pharmaciens, Pharmagest conçoit des solutions informatiques innovantes à destination des officines, et développe une activité e-business et e-media à fort potentiel en direction des laboratoires. La diffusion et la commercialisation des produits du Groupe Pharmagest sont assurées par 27 agences en France et 4 dans les DOM. Pharmagest est notamment connu pour avoir développé LGPI Global Services. LGPI Global Services révolutionne le secteur des logiciels de gestion officinale en offrant aux pharmaciens un outil de travail qui allie modernité et performance. Il s agit de la première solution à se doter d un portail d information Intégré. 4 La problématique Dans un environnement hétérogène contenant des machines sous Windows, GNU/Linux, etc, l entreprise doit gérer les utilisateurs, les groupes, les droits de chaque groupe et utilisateur. Actuellement chez Pharmagest, tout se fait manuellement, c est-à-dire que, par exemple, pour créer un utilisateur il faut faire plusieurs manipulations sur différents outils, le mettre dans les bons groupes sur chaque outil, les bonnes listes de diffusion, lui accorder les accès spécifiques, etc... Tout cela devient rapidement complexe et fastidieux à gérer d autant plus lorsque le nombre d utilisateurs est conséquent. On voit donc apparaître des difficultés à administrer les utilisateurs en raison de la diversité des systèmes d exploitation (MacOS, Linux, Windows, Android, IOS, Windows Phone) et des nombreux outils. 5 Objectifs L objectif est donc de proposer une solution pour gérer de manière simple et homogène un ensemble d utilisateurs dans un environnement hétérogène et uniformiser leur création. Notre solution doit être un outil au-dessus des autres, un outil plus général qui aura pour mission de gérer et faciliter l ajout, suppression et modification des utilisateurs. L idée, ici, est de centraliser l information et d avoir un seul point de contrôle. Les buts sont multiples, en effet cela permettra entre autres de faire gagner du temps aux administrateurs réseaux dans l optique d une recherche d automatisation de la tâche mais également de diminuer la probabilité d erreurs dans la mesure où la solution est vouée à centraliser la gestion des utilisateurs. Cela permettra la création d utilisateurs sur tous les outils en même temps ou presque, pour limiter les risques d erreurs qu on pourrait faire en le créant une fois sur chaque outil par exemple. Pour cela nous devons donc trouver une solution générique à interface unique pour gérer les utilisateurs et visualiser leurs accès. Active Directory, OpenLDAP ou autres outils comme des bases de données doivent cohabiter sans heurt au sein de l entreprise et au sein de notre solution. De plus, nous voulons qu elle soit évolutive pour que Pharmagest puisse, si elle le souhaite, pour une raison quelconque (ajout ou suppression d outil par exemple), pouvoir interconnecter 8 Année 2014-2015
d autres outils à terme à notre solution. On ne veut pas faire une application qui automatise la main de l administrateur, en effet on ne veut pas automatiser la création des utilisateurs mais simplifier leur création et leur intégration dans les annuaires en particulier. Exemple de situation: Les différentes agences de Pharmagest disposent pour la plupart d un annuaire qui leur est propre, la gestion des utilisateurs est donc complexifiée du fait d avoir plusieurs annuaires, non synchronisés entre eux, répartis sur plusieurs agences. En effet un utilisateur qui est créé dans une agence ne l est pas dans une autre, on peut donc vite se perdre. 6 Reformulation du sujet Proposer une solution pour gérer de manière simple et homogène un ensemble d utilisateurs dans l environnement déjà présent et uniformiser leur création, mise à jour et suppression. La solution gérera les utilisateurs, leurs groupes, les droits spécifiques en fonction de leur poste et de leurs besoins. Tout cela dans un environnement hétérogène (Windows, Mac, Linux). Elle s appuiera sur les services d annuaires Active Directory et OpenLDAP déjà présents dans l entreprise. En l occurrence elle ne gérera pas les comptes locaux en raison d un manque de temps. 9 Année 2014-2015
7 Définition du périmètre Dans la mesure où le temps du projet est assez court et la complexité/largeur du sujet, nous avons dû définir le périmètre du sujet. Doit-on gérer les comptes locaux?......... Nous avons donc décidé avec nos tuteurs de projet que notre solution de gestion gérera les utilisateurs, leurs groupes, les droits spécifiques en fonction de leur poste et de leurs besoins. Tout cela dans un environnement hétérogène (Windows, Mac, Linux). Elle s appuiera sur des annuaires LDAP, Active Directory, OpenLDAP déjà présents dans l entreprise. Active Directory, OpenLDAP ou autres bases de données doivent cohabiter sans heurt au sein de l entreprise et au sein de notre solution. De plus, il est nécessaire de garder en mémoire que cette dernière se doit d être générique puisqu il n est pas exclu que d autres types d annuaires viennent se greffer par la suite : IBM Tivoli Directory Server, HP OpenView, etc. 8 La mise en place des outils collaboratifs «La pierre n a point d espoir d être autre chose qu une pierre. Mais, de collaborer, elle s assemble et devient temple.» (Antoine de Saint-Exupéry) Afin d optimiser notre travail de recherche, nous avons décidé de mettre en place des outils de travail pour simplifier la gestion et favoriser la bonne entente de notre groupe de travail. Nous avons donc listé ceux qui nous semblaient utiles pour notre tâche : Applications Google, Framapad, Git, GitHub, Mail, LaTeX, Skype / Hangout. En définitif, nous avons utilisé ces outils : Google Drive -> Pour mettre en commun tous nos documents et ressources. Google Docs -> Nous avons utilisé les Google Docs pour mettre en commun toutes nos idées, ressources. Google Drawing -> Nous l utilisons pour la rédaction de brouillons / schémas. Git / GitHub -> Nous utilisons Git pour toute modification sur le rapport de notre projet. Mail -> Nous utilisons les mails pour tout échange avec nos tuteurs de projet et entre élèves parfois. LaTeX -> Nous l utilisons pour la rédaction du rapport. 10 Année 2014-2015
Nous avons décidé de ne pas utiliser Framapad puisque cette solution est similaire à Google Docs, mais Docs nous semblait plus user-friendly, et les possibilités que nous offrent les applications Google comme la mise en forme, la création de schémas avec Google Drawing, tout cela nous a convaincus d utiliser la solution de Google. Nous n avons pas aussi utilisé Skype / Hangout car nous nous voyons très souvent "physiquement" dans les créneaux horaires de projet tutoré fixés dans notre emploi du temps ou en cours. L utilisation d un logiciel de visioconférence ne nous a donc pas paru nécessaire. En ce qui concerne l utilisation des applications Google, ce qui peut paraître contradictoire avec la licence ASRALL mais la simplicité, l efficacité, la rapidité ainsi que la possibilité de chat des applications nous ont séduits. De plus toutes les informations qui se trouvent sur ces applications ne sont pas sensibles comme des mots de passe, etc. S y trouvent seulement des idées, résultats de recherches ou autres schémas de notre solution. 9 Déroulement temporel de notre projet Notre travail s est principalement déroulé de cette manière : Après avoir mis en place tous les outils collaboratifs nécessaires à notre travail, nous avons tout d abord accompli un gros travail d analyse, de recherche de solutions, afin de trouver celle qui répondrait le mieux à nos besoins. Il s agit de la première grosse partie de notre rapport, où nous énumérons ces solutions, leurs avantages, leurs inconvénients, et pourquoi nous avons retenu / n avons pas retenu cette solution. Ensuite, après avoir retenu notre solution, notre travail était de la mettre en place dans un environnement virtuel, avec une batterie de tests à effectuer, puis dans l infrastructure qui nous a été fournie par Pharmagest. 9.1 Première semaine La première semaine, nous avons reformulé le sujet puis nous l avons présenté à notre tuteur lors de notre premier rendez-vous pour être sûrs d avoir bien compris ce qu il attendait de nous. Lors de ce même rendez-vous nous avons défini le périmètre du sujet car celui-ci peut être très ambigu. Ensuite nous nous sommes penchés sur le fonctionnement général de LDAP. 9.2 Seconde et troisième semaines Lors de la seconde semaine nous avons recherché les solutions possibles pour répondre au sujet de notre projet. Les recherches se sont déroulées principalement sur internet et par contact professionnel. 9.3 Quatrième et cinquième semaines Pour la troisième semaine nous avons isolé une solution puis nous l avons étudiée plus en profondeur. Nous avons aussi rédigé une Road Map pour la mise en place de la solution et la mise en place des tests. 11 Année 2014-2015
9.4 Reste du temps Pour le reste du temps nous avons fait une rapide présentation de notre solution dans les locaux de Pharmagest. Ensuite nous avons mis en pratique notre solution dans un environnement local et effectué des tests. 10 Travail d analyse, de recherche de notre solution 10.1 Définition de l axe de recherche Avant de se lancer à corps perdu dans la recherche de notre solution, nous avons défini un axe de recherche précis afin de ne pas perdre de vue notre objectif, ce qui passe par une reformulation de notre sujet, que nous avons exprimée ainsi : "Proposer une solution pour gérer de manière simple et homogène un ensemble d utilisateurs dans l environnement déjà présent et uniformiser leur création, mise à jour et suppression. La solution gérera les utilisateurs, leurs groupes, les droits spécifiques en fonction de leur poste et de leurs besoins. Tout cela dans un environnement hétérogène (Windows, Mac, Linux). Elle s appuiera sur les services d annuaires Active Directory et OpenLDAP déjà présents dans l entreprise. En l occurrence, elle ne gérera pas les comptes locaux en raison d un manque de temps." Nous recherchons donc une solution que l on situerait à un niveau "au-dessus" des services d annuaires, qui permettrait d effectuer une gestion centralisée des utilisateurs, et qui ainsi répliquerait les utilisateurs sur chacun des annuaires afin d atteindre notre objectif. 10.2 Solutions éventuelles Pour la recherche de la solution qui nous conviendrait, nous avons établi une liste de logiciels ayant des caractéristiques qui nous permettraient de répondre à notre problématique. Dans cette liste, nous avons éliminé des logiciels sans les tester, en voyant que le logiciel ne correspondait pas à ce que l on cherchait. Nous avons aussi étudié plus en profondeur les autres logiciels pour au final garder la solution qui répond parfaitement à nos besoins. 10.3 Centrify Centrify développe des solutions qui contrôlent, sécurisent et auditent de manière centralisée l accès aux environnements hétérogènes, aux appareils mobiles (tablettes, smartphones) et aux applications, en utilisant pour seul référentiel d identité Active Directory de Microsoft. Nous nous sommes intéressé de plus près à la solution Direct Control proposée par Centrify. Voici les possibilités de cette solution, présentées par Centrify : "Direct Control apporte un contrôle d accès sécurisé et une gestion des identités centralisée, en intégrant parfaitement des systèmes UNIX, Linux et Mac et leurs applications, à Microsoft Active Directory." "Direct Control transforme un système non-microsoft en un client Active Directory, permettant ainsi de sécuriser ce système en utilisant les mêmes authentifications et les services de stratégies de groupes déployés sur vos systèmes Windows." "Direct Control est non-intrusif, facile à déployer et à gérer, et est la seule solution qui permet le contrôle d accès granulaire grâce à sa technologie unique de Zone." 12 Année 2014-2015
Direct Control fait partie des solutions que nous avons directement éliminées, car c est une solution propriétaire, et qui veut centraliser le service d annuaire sur l Active Directory. Dans la mesure du possible, nous recherchions une solution libre et gratuite. 10.4 Mandriva Directory Server Mandriva Directory Server (MDS) est un annuaire d entreprise et contrôleur de domaine basé sur le couple Samba / OpenLDAP, conçu pour gérer les utilisateurs, les contrôles d accès, règles et paramètres des applications et profils d utilisateurs. Nous avons éliminé MDS rapidement car c est un service d annuaire comme AD / OpenL- DAP, et nous recherchions une solution qui permettrait de gérer ces services d annuaires. 10.5 Microsoft Windows Services for Unix 3.5 Ce package logiciel produit par Windows présente des avantages convaincants : Partage transparent des données entre les protocoles réseaux Windows et UNIX. Accès distant via la ligne de commande aux ordinateurs Windows et UNIX via les méthodes et protocoles UNIX existants. Prise en charge complète des scripts UNIX sous Windows, notamment les shells, les utilitaires, les liens matériels et logiciels (symboliques), ainsi qu un système de fichiers à racine unique. Administration des réseaux hétérogènes, notamment la gestion commune des répertoires et la synchronisation des mots de passe utilisateurs. Environnement haute performance d exécution et de développement d applications, afin de permettre la réorientation des applications métier essentielles. Processus d installation intégré et unique. Simplicité de l administration et de la gestion pour tous les composants SFU. Cependant, la solution ne nous semblait pas assez complète, avec des spécifications trop peu décrites. La solution étant basée qui plus est sur un modèle propriétaire, notre choix a été de ne pas l utiliser. 10.6 Samba + LDAPScripts Samba est un logiciel d interopérabilité qui permet à des ordinateurs Unix de mettre à disposition des imprimantes et des fichiers dans des réseaux Windows, en mettant en œuvre le protocole SM- B/CIFS de Microsoft Windows. Samba donne la possibilité aux ordinateurs Windows d accéder aux imprimantes et aux fichiers des ordinateurs Unix en permettant aux serveurs Unix de se substituer à des serveurs Windows. Samba 4 supporte le côté serveur dans un environnement Active Directory utilisé par Windows 2000. Il est ainsi possible de joindre complètement des clients Windows à un domaine et effectuer des opérations d ouverture de session. Il inclut un serveur LDAP et un centre de distribution de clés Kerberos (KDC). Nous n avons pas choisi cette solution car elle ne permettait pas la gestion complète des deux services d annuaires, et le manque de documentation nous a refroidis. 13 Année 2014-2015
10.7 PhpLdapAdmin PhpLDAPadmin est une interface écrite en PHP qui permet de modifier facilement, via une interface conviviale, un annuaire LDAP (OpenLDAP principalement), sur le même principe que phpmyadmin pour les bases de données MySQL. Il permet de gérer des annuaires LDAP et implémente plusieurs modes d authentification. Il permet aussi de gérer les services d annuaires suivants. Microsoft Active Directory IBM Tivoli DS Apache DS Fedora Directory Server OpenDS Redhat Directory Server (RHDS) Oracle Internet Directory et bien d autres... 10.8 LDAP Synchronization Connector Ldap Synchronization Connector (LSC) est un projet qui permet de synchroniser des données de n importe quelle source de données, y compris des bases de données, annuaires LDAPv3 ou fichiers à plat, en transformant et en comparant ces données entre la source et les référentiels cibles. Ces connecteurs peuvent ensuite être utilisés pour synchroniser en permanence une source de données dans un répertoire, pour une importation d un projectile ou tout simplement pour comparer les différences de sortie CSV ou LDIF. La dernière version (2.1.3) est sortie le 4 mars 2015. Aperçu des fonctionnalités: Outil d installation graphique (l utilisation est facultative). Entièrement configurable via un fichier de configuration XML. Écrit en Java, tirant parti de l écosystème des outils disponibles. Des Wrapper shell sont fournis, pour faciliter l utilisation et l intégration de systèmes. Fonctionne sur n importe quelle plateforme de java6-enabled - Testé sur Windows, Linux et MacOS X. Trois politiques pour mettre à jour les attributs, y compris les valeurs de forçage, mises à jour non destructives et fusion. Manipulation de chaînes: formatage pour les tâches courantes en matière de gestion d identité, tels que la capitalisation premières lettres dans un nom complexe, filtrage des accents pour les noms de connexion, etc... Outils de sécurité: hachage de mot de passe, chiffrement bidirectionnel 14 Année 2014-2015
Conditions de créer seulement, mise à jour, renommer ou supprimer des entrées en fonction de valeurs actuelles Journalisation détaillée et configurable dans LDIF (entièrement compatible RFC) et CSV Support des plugins pour Nagios (monitoring) Opérations de synchronisation d identité: En réconciliant deux référentiels d identité, trois opérations sont possibles pour chaque identité individuelle: Créer: Si l identité n existe que dans un seul dépôt, elle peut être créée dans l autre. Dans ce cas, toutes les informations au sein de l identité proviennent du référentiel contenant l identité, ou à partir de valeurs par défaut spécifiées sur une base générale. Mise à jour: Si l identité existe dans les deux dépôts, l information doit être mise à jour, pour synchroniser chaque élément d un référentiel vers l autre. Effacer: Si l identité n existe que dans un seul dépôt, elle peut être supprimée dans l autre. Dans ce cas, l identité et les informations à l intérieur sont complètement enlevées. La combinaison de ces deux solutions permettrait une synchronisation des annuaires OpenL- DAP et Active Directory, tous deux gérés par LSC. PhpLdapAdmin permettrait une gestion des utilisateurs par une interface web pour les deux services d annuaires. Cette solution permet aussi de pouvoir intégrer d autres types d annuaires sur le long terme. C est pour ces critères, qui répondent à ce que nous recherchons, que nous choisissons ce couple de solution. Nous allons expliquer plus en détails la mise en place de cette solution dans le prochain chapitre. Les phases de LSC: Une synchronisation complète avec LSC comporte deux phases : Phase de synchronisation (Sync phase) : LSC va ajouter/modifier/renommer les entrées dans la destination. Phase de nettoyage (Clean phase) : LSC va supprimer les entrées de la destination. Figure 1: Phase de synchronisation 15 Année 2014-2015
1. Toutes les entrées sont lues dans la source. Cela se fait avec getallfilter pour LDAP, base de données ou pour requestnameforlist listscript pour l extension exécutable. Les valeurs des attributs définis dans pivotattributes (dans la source) sont lus. 2. Pour chaque entrée trouvée à l étape 1, les valeurs de pivot sont utilisés pour obtenir l entrée dans la source et les valeurs d attributs définis dans fetchedattributes sont lus. Cela se fait avec getonefilter pour LDAP, base de données ou pour requestnameforobject getscript pour l extension exécutable. 3. Pour chaque entrée trouvée à l étape 1, les valeurs de pivotement (de la source) sont utilisés pour obtenir l entrée dans la destination et les valeurs d attributs définis dans fetchedattributes sont lus. Cela se fait avec getonefilter pour LDAP, base de données ou pour requestnameforobject getscript pour l extension exécutable. 4. Attributs et valeurs trouvées à l étape 2 sont placés dans srcbean, et ceux trouvés à l étape 3 sont en dstbean. Les règles de synchronisations sont exécutés et LSC calcule les modifications. 5. La modification est appliquée sur la destination, si les conditions associées sont vraies. Figure 2: Phase de clean 1. Toutes les entrées sont lues dans la destination. Les valeurs des attributs définis dans pivotattributes (dans la destination) sont lus. 2. Pour chaque entrée trouvée à l étape 1, les valeurs de pivotement (à partir de la destination) sont utilisés pour obtenir l entrée dans la source. Cela se fait avec cleanfilter pour LDAP, base de données ou pour requestnameforclean getscript pour l extension exécutable. 3. Si aucune entrée correspondante se trouve dans la source, LSC marquer l entrée de destination pour la suppression. 4. La suppression sont appliquées sur la destination, si l état de suppression est vrai. 16 Année 2014-2015
11 La solution retenue 11.1 PhpLdapAdmin + LDAP Synchronisation Connector Nous avons choisi de couplé PhpLdapAdmin à LDAP Sychronization Connector. En effet, PhpLdapAdmin servira d interface de gestion pour ajouter, modifier, mettre à jour les informations de l annuaire sur l OpenLDAP et LDAP Synchronisation Connector synchronisera tout changement de l annuaire OpenLDAP sur les autres outils. (Active Directory, bases de données, etc) Avantages : LSC est open source et bien suivi par la communauté. LSC permet de s interfacer avec n importe quelle base de données SQL et n importe quel annuaire LDAPv3. LSC est un projet spécialisé dans la synchronisation d annuaire LDAP. Possibilité de gestion des annuaires par interface web via PhpLdapAdmin. Inconvénients : La configuration de LSC est entièrement en XML. LSC est écrit en Java. LSC doit être configuré à la main. LSC ne possède pas d interface graphique pour simplifier la configuration. 17 Année 2014-2015
OpenLDAP et phpldapadmin ont été installés sur une machine sous Debian wheezy, en localhost et reposant sur le serveur Apache. Pour les tests, le serveur est resté en http et aucun certificat n a été généré. En production, il est nécessaire de passer en https pour des raisons évidentes de sécurité. L avantage de phpldapadmin est qu il offre une interface graphique de gestion des bases, ce qui rend l usage plus ergonomique. Pour synchroniser les annuaires nous allons utiliser Ldap Synchronization Connector (LSC). Cela va nous permettre de diffuser tous les changements sur les autres annuaires. La gestion des utilisateurs se fera via PhpLdapAdmin sur un OpenLDAP puis LSC synchronisera sur les autres annuaires. Pour en savoir plus sur LSC,nous avons contacté les développeurs de LSC, à savoir Clément OUDOT et Sébastien BAHLOUL, pour en savoir un peu plus sur leur outil. Nous avons donc appris qu au départ, ils développaient des scripts de synchronisation pour chaque projet client. Il s est avéré que les besoins étaient souvent similaires, d où la création d un moteur de synchronisation, nommé LSC, pouvant adapter son comportement par configuration. La principale difficulté qu ils aient rencontrée a été la prise en main par des personnes extérieures au projet en raison de la complexité de l outil. Mais au fur et à mesure l outil est devenu plus facilement utilisable et la documentation plus fournie. Ils ont eu des retours plutôt positifs surtout au fur et à mesure des versions, certaines sociétés comme Orange ont même financé une partie du développement du projet. Les questions/réponses aux développeurs de LSC sont disponibles en annexe ici. 18 Année 2014-2015
12 PhpLdapAdmin - LSC, la mise en place de notre solution 12.1 Installation de OpenLDAP L installation de OpenLDAP se fait via les dépôts Debian: apt-get install slapd ldap-utils Configuration de /etc/ldap/ldap.conf: Modification des lignes suivantes (nous avons choisi comme domaine pharma.local): 1 BASE dc=pharma,dc= local 2 URI ldap :// debian. pharma. local ldap :// debian - master. pharma. local :666 Ensuite: dpkg-reconfigure slapd Omit OpenLDAP server configuration? No DNS domain name: debian.pharma.local Organization name: PharmaGest Administrator password: <PASSWORD> Confirm password: <PASSWORD> Database backend to use: HDB Do you want the database to be removed when slapd is purged? Yes Move old database? Yes Allow LDAPv2 protocol? No Vérifier la configuration initiale avec la commande: slapcat 12.2 Installation de Apache, PHP et PhpLdapAdmin Installation de Apache et PHP: apt-get install apache2 php5 php5-mysql Installation de PhpLdapAdmin apt-get install phpldapadmin Modification dans /etc/phpldapadmin/config.php: 1 $servers -> setvalue ( server, name, My LDAP Server ); 2 $servers -> setvalue ( server, host, 127.0.0.1 ) ; 3 $servers -> setvalue ( server, base, array ( dc=debian,dc=pharma,dc=local )); 4 $servers -> setvalue ( login, bind_id, cn=admin,dc=debian,dc= pharma,dc=local ); 19 Année 2014-2015
URL d accès à PhpLdapAdmin: http://localhost/phpldapadmin/ 12.3 Pré-requis pour LSC Le serveur OpenLDAP doit appartenir au même domaine, dans notre cas Pharma.local. Le JRE 1 1.6 au minimum doit être installé. On peut vérifier si Java est installé en entrant la commande : java -version De plus, pour que les scripts cron fonctionnent correctement, il vaut mieux configurer la variable d environnement JAVA_HOME. Pour cela : export JAVA_HOME=/usr/lib/jvm/<chemin_vers_java> 1 Java Runtime Environment 20 Année 2014-2015
12.4 Installation de LSC Dans /etc/apt/sources.list.d/lsc-project.list ajouter : deb http://lsc-project.org/debian lsc main deb-src http://lsc-project.org/debian lsc main Mettre à jour les dépôts : apt-get update Importer la clé PGP : wget -O - http://ltb-project.org/wiki/lib/rpm-gpg-key-ltb-project sudo apt-key add - Si on ne le fait pas, on a l erreur suivante à l update : Erreur de GPG : http://lsc-project.org lsc Release : Les signatures suivantes n ont pas pu ê NO_PUBKEY 0AC51F926D45BFC5 Installation depuis les dépôts ajoutés juste avant : apt-get install lsc 12.5 Configuration Avec cette installation, les fichiers de LSC sont installés dans : /usr/bin/lsc: wrapper pour lancer LSC /etc/lsc/: configuration /var/log/lsc/: logs /etc/init.d/lsc: init script (pour le mode asynchrone) /etc/default/lsc: init script /etc/cron.d/lsc: configuration cron /usr/lib/lsc/: LSC libraries /var/lib/lsc/nagios/: scripts de monitoring /usr/share/doc/lsc: scripts d exemple 21 Année 2014-2015
Pour configurer LSC nous avons commencé par ceci: Nous avons créé un répertoire de configuration pour nos fichiers de configuration: mkdir /etc/lsc/openldap2ad/ Nous avons besoin d une configuration de logback dans ce répertoire: cp /etc/lsc/logback.xml /etc/lsc/openldap2ad/ Toute la configuration se fait à travers le fichier de configuration /etc/lsc/openldap2ad/lsc.xml. Un exemple de fichier est fourni: cp /etc/lsc/lsc.xml /etc/lsc/openldap2ad/ Tous les paramètres de configuration sont décrits dans le fichier lsc.xml. Détail de notre fichier de configuration lsc.xml: Le fichier de configuration s ordonne de la manière suivante: 1. Connexion aux outils 2. Taches à effectuer Règles générales à propos de ce fichier: L ordre des paramètres est important. Il faut respecter l ordre donné dans les exemples. Les caractères contenus entre <!- and -> sont des commentaires. Les XML entities comme "&" doivent être convertis ou encapsulés en CDATA. Exemple : <getonefilter>(&(objectclass=inetorgperson)(uid={uid}))</getonefilter> devient : <getonefilter><![cdata[(&(objectclass=inetorgperson)(uid={uid}))]]></getonefilter> Un namespace XML doit être déclaré dans lsc.xml. Ce namespace va varier en fonction des releases de LSC, il faudra donc le garder à jour. <?xml version="1.0"?> <lsc xmlns="http://lsc-project.org/xsd/lsc-core-2.1.xsd" revision="0"> Voici nos connexions aux annuaires: Connexion à l OpenLDAP: 1 < connections > 2 < ldapconnection > 3 <name > openldap </ name > 4 <url > ldap :// localhost :389/ dc=debian,dc=pharma,dc=local </ url > 5 <username >cn=admin,dc=debian,dc=pharma,dc=local </ username > 22 Année 2014-2015
6 <password >toor </ password > 7 < authentication > SIMPLE </ authentication > 8 <referral > IGNORE </ referral > 9 < derefaliases > NEVER </ derefaliases > 10 <version > VERSION_3 </ version > 11 <pagesize > -1 </ pagesize > 12 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 13 < tlsactivated > false </ tlsactivated > 14 </ ldapconnection > Explication des balises: <url>obligatoire : Adresse de connexion au serveur OpenLDAP et l annuaire ensuite</url> <username>optionnel : Utilisateur d accès à l annuaire</username> <password>optionnel : Le mot de passe de l utilisateur qui accède à l annuaire</password> <authentication>obligatoire : Le niveau d authentification</authentication> <referral>obligatoire : Protocole de communication permettant de créer des liens permettant ainsi de relier des annuaires les uns aux autres</referral> <derefaliases>obligatoire : Indique le comportement à adopter en utilisant un alias 2 (1)</derefAliases> <version>obligatoire : Version du protocole LDAP, par défaut LDAPv3</version> <pagesize>obligatoire : Taille de la page à utiliser ou -1 pour infini. 3 </pagesize> <tlsactivated>obligatoire : Activation du mode de communication TLS 4 <tlsactivated> Connexion à l Active Directory: 1 < ldapconnection > 2 <name >AD </ name > 3 <url > ldaps :// ServeurAD. pharma. local :636/ dc=pharma,dc= local </ url > 4 <username >CN= Administrateur,CN=Users,DC=pharma,DC=local </ username > 5 <password >toor </ password > 6 < authentication > SIMPLE </ authentication > 7 <referral > IGNORE </ referral > 8 < derefaliases > NEVER </ derefaliases > 9 <version > VERSION_3 </ version > 10 < pagesize >1000 </ pagesize > 11 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 12 < tlsactivated > false </ tlsactivated > 13 </ ldapconnection > 14 </ connections > La connexion à l Active Directory est configuré de la même manière. On peut remarquer que <pagesize> est, comme indiqué plus haut, configuré pour 1000 résultats pour éviter les erreurs. 2 Voir http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html pour plus d informations. 3 Certains clients LDAP ne peuvent recevoir que les 1000 premiers résultats lors d une requête (AD par exemple). S il y a 1200 résultats à retourner et que la pagination n est pas activée, le client va recevoir une erreur de type "Size Limit Exceeded" Voir http://www.ietf.org/rfc/rfc2696 pour plus d informations. 4 Activation de SSL et TLS: LSC peut chiffrer la communication avec un serveur LDAP en utilisant StartTLS (sur le port LDAP standard, 389) ou via SSL (sur un port specifique, le 636). 23 Année 2014-2015
Voici le détail d une tâche: La structure d une tâche: 1 <tasks > 2 <task > 3 <name > syncusers </ name > 4 <bean > org. lsc. beans. SimpleBean </ bean > 5... 6 <task > 7 <tasks > Explication des balises: <name>nom de la tâche</name> <bean>nom du bean. SimpleBean pour le bean par défaut. OrderedValuesBean pour forcer LSC à modifier les attributs si l ordre des valeurs a changé.</bean> 1 < ldapsourceservice > 2 <name > openldap - source - service </ name > 3 < connection reference =" openldap " / > 4 <basedn >cn=users,dc=debian,dc=pharma,dc=local </ basedn > 5 < pivotattributes > 6 <string >uid </ string > 7 </ pivotattributes > Explication des balises: <name>obligatoire : Nom de la source</name> <connection>nom de la connexion à utiliser (configurée avant) pour l accès à l annuaire</connection> <basedn>obligatoire : Fait référence au nom de connexion cité plus haut dans la partie de connexion</basedn> <pivotattributes>obligatoire : Liste de valeurs contenant les attributs pivots qui sont récupérés lors de la recherche sur toutes les entrées. Ils sont utilisés pour obtenir le bon filtre afin de lire chaque entrée unique.</pivotattributes> 1 < fetchedattributes > 2 <string >cn </ string > 3 < string > homedirectory </ string > 4 < string > givenname </ string > 5 <string >mail </ string > 6 <string >sn </ string > 7 <string >uid </ string > 8 < string > userpassword </ string > 9 </ fetchedattributes > Explication des balises: <string>nom des ressources à récupérer</string> 24 Année 2014-2015
1 < ldapdestinationservice > 2 <name >ad -dst - service </ name > 3 < connection reference =" AD" / > 4 <basedn >cn= Computers,dc=pharma,dc=local </ basedn > 5 < pivotattributes > 6 < string > samaccountname </ string > 7 </ pivotattributes > 8... 9 </ ldapdestinationservice > Il s agit de la même chose mais du côté destination, dans notre cas l Active Directory Autres balises: getallfilter: Obligatoire : Filtre utilisé pour chercher toutes les entrées à synchroniser getonefilter: Obligatoire : Filtre utilisé pour chercher une entrée particulière lors de la phase de synchronisation cleanfilter: Optionnel : Filtre utilisé pour chercher une entrée particulière lors de la phase de nettoyage filterasync: Optionnel : Filtre utilisé pour simuler une tache asynchrone (par défaut: modifytimestamp>=0) dateformat: Optionnel : Format de la date pour le filtre d avant (par défaut: yyyymmddhhmmss Z) interval: Optionnel : Intervalle en secondes pour aller chercher les données (par défaut: 5) 12.6 Les modes de lancement de LSC On peut lancer LSC sous trois modes différents : Mode synchrone: c est la façon la plus simple pour démarrer LSC. Une fois que le service de la source a été listé, les objets sont extraits de la source et de la destination. Les nouveaux objets sont créés, les existants sont mis à jour et, à la fin, LSC va s arrêter (pas de démon ou de programme en cours d éxecution) clean mode: ce mode est complémentaire au premier pour le nettoyage du service de destination en récupérant les objets et en vérifiant leur existence à l intérieur du service de la source. S ils existent, rien n est fait mais s ils n existent pas, ils sont supprimés à partir du service de destination. Mode asynchrone: dans ce mode, LSC est lancé en tant que démon. Si le service de la source a quelque chose à synchroniser, LSC va récupérer les objets mis à jour un par un et se synchroniser avec le service de destination. Si aucune mise à jour n est disponible, LSC va attendre pendant 5 secondes et essayez à nouveau. Il ne s arrêtera jamais tant qu une demande explicite ne soit faite. Nous utiliserons le mode asynchrone pour que LSC soit lancé en démon et fasse les modifications immédiatement une fois que la modification a été faite sur PhpLdapAdmin. Si une tâche 25 Année 2014-2015
doit être exécutée une fois, alors le mode Synchrone correspond le mieux. Attention! Le "clean mode", qui permet de supprimer une entrée, n est pas compatible avec le mode asynchrone. Ce qui veut dire que lorsque le mode asynchrone est lancé, LSC effectue les ajouts et modifications mais pas les suppressions. D après Clément OUDOT, un développeur de LSC, il s agit plus d une question de temps qu un véritable choix technique. La meilleur solution dans ce cas-là est d établir une procédure lorsque vous voulez supprimer un utilisateur. Par exemple celle-ci pourrait dire, lorsque vous voulez supprimer un utilisateur, qu il faut le supprimer normalement via PhpLdapAdmin puis lancer un "clean mode" à la main par la suite. Les commandes de lancement de LSC: Cette commande lance une synchronisation en mode synchrone: /usr/bin/lsc -f /etc/openldap2ad/ -s all -c all /usr/bin/lsc: Correspond au chemin de l exécutable lsc -f /etc/openldap2ad: Correspond au fichier de configuration que l on souhaite -s all: Correspond à l ordre de tout synchroniser -c all: Correspond au clean mode Cette commande lance une synchronisation en mode asynchrone /usr/bin/lsc -f /etc/openldap2ad/ -s all -c all -a Ajout du - a permet de lancer la commande précédente en mode asynchrone. 26 Année 2014-2015
Résumé de la mise en place: Dans un premier temps: 1. Installation de OpenLDAP 2. Configuration de OpenLDAP pour votre domaine 3. Installation de php5 et apache2 4. Installation de java Puis: 1. Installation de PhpLdapAdmin 2. Configuration de PhpLdapAdmin 3. Installation de LSC 4. Création/configuration des tâches LSC PS: Les autres annuaires doivent être configurés et être dans le même domaine que l OpenLDAP, dans notre cas pharma.local 27 Année 2014-2015
12.7 Les tests Les phases de tests sont importantes pour vérifier le fonctionnement de notre solution en toutes circonstances. Pour cela nous avons mis en place une "Road map" dans laquelle nous avons détaillé toutes les étapes des tests que nous avons prévus. Nous avons créé 3 utilisateurs sur l annuaire OpenLDAP grâce à PhpLdapAdmin qui vont nous servir pour nos tests. Road map: Jeu de tests numéro 1: -> Création d un user sur OpenLDAP via PhpLDAPAdmin -> Synchronisation via LSC sur AD -> Vérification sur l AD et OpenLDAP -> Modification d un user sur OpenLDAP via PhpLDAPAdmin -> Synchronisation via LSC sur AD -> Vérification sur l AD et OpenLDAP -> Suppression d un user sur OpenLDAP via PhpLDAPAdmin -> Synchronisation via LSC sur AD -> Vérification sur l AD et OpenLDAP La tâche que nous avons créée fait les 3 en même temps, l ajout, la modification et la suppression. C est-à-dire, en une seule tâche, il va à la fois ajouter, modifier et supprimer si besoin. La tâche est disponible en annexe: ici. 28 Année 2014-2015
Voici un exemple de test: Dans celui-ci nous avons ajouté, modifié et supprimé un utilisateur. Figure 3: OpenLDAP, avant synchronisation Figure 4: Ajout d un utilisateur via PhpLdapAdmin 29 Année 2014-2015
Figure 5: Synchronisation avec LSC Figure 6: Active Directory, avant synchronisation Figure 7: Active Directory, après synchronisation 30 Année 2014-2015
Jeu de tests numéro 2: -> Création d un user sur AD -> Synchronisation via LSC sur OpenLDAP -> Vérification sur l OpenLDAP -> Modification d un user sur AD -> Synchronisation via LSC sur OpenLDAP -> Vérification sur l OpenLDAP -> Suppression d un user sur AD -> Synchronisation via LSC sur OpenLDAP -> Vérification sur l OpenLDAP Il s agit d effectuer le même test que précédemment en changeant la source et la destination. Nous n avons pas jugé utile de détailler ce test. Vous pouvez retrouver le fichier lsc.xml qui a servi à ce test en annexe ici. 31 Année 2014-2015
12.8 Sécurisation Par manque de temps, nous n avons pas pu approfondir la sécurisation de notre solution. Voici tout de même un exemple de ce qui est possible: Le protocole Kerberos: Le protocole Kerberos repose sur un système de cryptographie à base de clés secrètes (clés symétriques ou clés privées), avec l algorithme DES. Kerberos partage avec chaque client du réseau une clé secrète faisant office de preuve d identité. Ce système est relativement long et complexe à mettre en place. SSL et PhpLdapAdmin: La connexion à PhpLdapAdmin peut se faire en SSL, il est même vivement conseillé de le faire pour sécuriser les échanges entre l annuaire et PhpLdapAdmin. LSC: Dans LSC, il existe une options de chiffrement des communications: Les options de cryptage sont utilisées pour fournir un mécanisme de chiffrement bidirectionnel nécessaire pour protéger l information sensible. Elles sont utilisées par la bibliothèque SecurityUtils. Le chiffrement symétrique peut être configuré via les trois paramètres suivants dans le fichier de configuration: lsc> securityencryption> keyfile: le chemin vers le fichier utilisé pour crypter / décrypter les données. Par défaut, "lsc.key". lsc> Sécurité> Cryptage> algorithme: l algorithme à utiliser. Par défaut AES. lsc> Sécurité> Cryptage> force: la force en bits. Par défaut, 128. Exemple de configuration de chiffrement: 1 <lsc > 2 < security > 3 < encryption > 4 <keyfile > $LSC_HOME / etc / lsc.key </ keyfile > 5 <algorithm >AES </ algorithm > 6 < strength >128 </ strength > 7 </ encryption > 8 </ security > 9 </lsc > Configurer LSC en TLS pour des opérations via StartTLS (cette fonctionnalité est disponible depuis LSC 1.1.0) : 1 < tlsactivated > false </ tlsactivated > Configurer LSC en SSL On peut aussi utiliser SSL pour créer un tunnel sécurisé. Cela implique d utiliser l URI ldaps: 32 Année 2014-2015
1 <url > ldaps :// localhost / </ url > Attention: Notre solution implique que le serveur avec OpenLDAP, LSC et PhpLdapAdmin doit être bien sécurisé. En effet, il est le point central de notre configuration, sur lui est installé PhpLdapAdmin, LSC et l annuaire "principal" OpenLDAP sur lequel tout les autres annuaires serons synchronisés. Il est donc le point critique de notre solution. 33 Année 2014-2015
13 Pour résumer Pour répondre aux objectifs que nous avions, qui étaient de proposer une solution pour gérer de manière simple et homogène un ensemble d utilisateurs dans un environnement hétérogène et uniformiser leur gestion via une interface tout en étant évolutive, nous avons choisi de coupler PhpLdapAdmin et LSC. En effet PhpLdapAdmin nous permet de gérer les utilisateurs de l OpenLDAP via une interface web sécurisé et LSC est chargé de synchroniser tout changement, que ce soit un ajout, une modification ou encore une suppression d utilisateur, sur les outils connectés à celui-ci (Active directory, MySQL, IBM Tivoli, etc..). De cette manière tous les utilisateurs, qu ils soient sur MAC OSX, Windows ou Linux sont tous gérés dans des annuaires synchronisés entre eux. Voici quelques schémas pour illustrer nos propos: Schéma de l architecture avant: Figure 8: Chaque annuaire est géré indépendamment 34 Année 2014-2015
Schéma de l architecture après: Figure 9: Les annuaires sont gérés via PhpLdapAdmin et synchronisés 14 Problèmes rencontrés La recherche de la solution en elle-même a pu paraître difficile au premier abord en raison de la quantité et de la variété des logiciels et applications existants et qui répondaient, ne seraitce qu en partie, à nos besoins. De plus, il nous fallait répondre à la problématique posée en prenant en compte les contraintes et obligations qui y étaient liées ; il fallait donc procéder par élimination afin de ne retenir que les solutions réellement envisageables. La solution définitive ne devait pas non plus trop perturber l architecture existante ; il ne s agissait pas de la repenser entièrement mais de la faire évoluer et gagner en simplicité et praticité. D autre part, le choix porté sur LSC ne présentait pas que des avantages ; la prise en main n était pas facile en raison d une configuration peu intuitive et d un certain manque de documentation et d exemples en ligne. En effet, nous avons perdu beaucoup de temps à comprendre le fichier tâche lsc.xml. Il nous a donc fallu en découvrir le fonctionnement avancé par nousmêmes au fur et à mesure des tests menés. Mais une fois le fichier compris, il était beaucoup plus simple pour nous d avancer. 35 Année 2014-2015
15 Suite du projet Une grande partie du travail a déjà été effectuée, puisque nous avons trouvé la solution la plus adaptée à nos besoins et avons commencé à la mettre en place localement afin de la prendre en main et davantage en comprendre le fonctionnement. Par la suite, il nous faudra commencer une phase de tests au sein de l entreprise elle-même, en utilisant des échantillons de données fournis par nos tuteurs et en couvrant tous les schémas d utilisation possibles. 16 Avis sur le projet Lors de la répartition des sujets, l intitulé du projet nous a aussitôt interpellés et intéressés, c est pourquoi nous l avons choisi. La gestion des utilisateurs représente une partie essentielle de l administration système au sein d une entreprise et il s agit d une problématique toujours grandement d actualité. La notion d environnement hétérogène et la variété des outils utilisés représentaient également un challenge intéressant. De plus, nous avons été très bien encadrés par nos tuteurs qui ont su nous conseiller aux moments-clés et nous familiariser aux étapes à suivre lors de la réalisation d une étude dans le cas d un besoin en entreprise et de la concrétisation d une solution, notamment aux problèmes et contraintes qu il est possible de rencontrer. Durant la réalisation de ce projet nous avons compris que lors de la recherche et de la mise en place d une solution pour répondre à une problématique précise, une grande partie consiste en la recherche de l outil adéquat, qui répondra au mieux à nos objectifs. Finalement l aspect technique n est qu une petite partie du travail. 36 Année 2014-2015
17 Bibliographie - Ressources Tout au long de la première étape, il nous a fallu rechercher sur Internet les solutions possibles et envisageables pour répondre à la problématique posée. Voici la liste (non-exhaustive) des sites web consultés : Authentification unique:http://fr.wikipedia.org/wiki/authentification_unique LDAP: https://fr.wikipedia.org/wiki/lightweight_directory_access_protocol OpenLDAP: https://fr.wikipedia.org/wiki/openldap OpenLDAP How to: http://www.openldap.org/doc/admin23/intro.html OpenLdap authentification Windows http://actuel.wikidot.com/projets:heterogeneserveurl Active Directory : https://fr.wikipedia.org/wiki/active_directory Kerberos: http://fr.wikipedia.org/wiki/kerberos_(protocole)ldap Solution possiblehttp://perso.univ-rennes1.fr/pascal.aubry/sites/default/files/ CASKERB-88244245-280211-0134-529.pdf RHEV: http://en.wikipedia.org/wiki/red_hat_enterprise_virtualization vsphere: http://fr.wikipedia.org/wiki/vmware_vsphere Kerberos + RADIUS + TACACS http://www.nolot.eu/download/cours/reseaux/ m2pro/sesy0708/proto-authentification.pdf TACACS: http://en.wikipedia.org/wiki/tacacs 802.1X: http://www.tacacs.net/ Solution d authentification sécurisée: pdf http://2003.jres.org/actes/paper.143. MWSfU: https://technet.microsoft.com/fr-fr/library/bb463212.aspx Direct Control: http://www.cerberis.com/component/flexicontent/48-cerberis-centrify/ 348-direct-control OBM Pro: http://pro.obm.org/spip.php?article1 List of LDAP softwares: https://en.wikipedia.org/wiki/list_of_ldap_software LSC: http://lsc-project.org/wiki/ LSC: http://coudot.blogs.linagora.com/index.php/post/2013/03/25/ldap-synchronization-co 0 Présentation LSC https://2014.rmll.info/slides/138/conf138-rmll_2014_oudot_ LDAP_Synchronization_Connector.pdf Conférence LSC: http://fr.slideshare.net/ldapcon/synchronize-ad-and-openldap-with-lsc 37 Année 2014-2015
18 Annexes Questions aux développeurs de LDAP Synchronisation Connector: Quelles sont les raisons / les besoins qui vous ont poussés à développer LSC? Au départ, nous développions des scripts de synchronisation pour chaque projet client. Il s est avéré que les besoins étaient souvent similaires, d où la création d un moteur de synchronisation, nommé LSC, pouvant adapter son comportement par configuration. Quelles ont été les difficultés que vous avez rencontrées? L outil étant très technique, la principale difficulté a été sa prise en main par des personnes extérieures au projet. Les premières versions ne pouvaient pas fonctionner sans un processus de recompilation. Puis, au fur et à mesure, l outil est devenu plus facilement utilisable, et la documentation plus fournie. LSC est désormais utilisé par de nombreux administrateurs systèmes partout dans le monde. Quels ont été les retours des entreprises avec lesquelles vous avez travaillé? Plutôt positifs, surtout au fur et à mesure des versions, comme expliqué précédemment. Certaines sociétés, comme Orange, ont même financé une partie du développement du projet. Pourquoi avoir utilisé le language XML pour la configuration? Les version 1.x du LSC utilisaient un format "java properties", le XML est arrivé en version 2. Ce format permet notamment une validation de la syntaxe de la configuration par un XSD. LSC a t-il une limite? LSC suit la philosophie UNIX: faire une seule chose, mais la faire bien. Du coup, il n est pas possible de faire tout ce qu on veut avec LSC, et dans certains cas, des produits d ETL son plus pertinents. Mais si vous devez synchroniser votre annuaire LDAP avec un autre référentiel, alors LSC est aujourd hui un outil incontournable. Le projet est-il encore maintenu? Oui, des versions sortent régulièrement. La dernière (2.1.3) est sortie le 4 mars 2015. 38 Année 2014-2015
Les fichiers de configuration: Fichier de configuration de OpenLDAP, soit: /etc/openldap/ldap.conf 1 # 2 # LDAP Defaults 3 # 4 5 # See ldap. conf (5) for details 6 # This file should be world readable but not world writable. 7 10 8 BASE dc=pharma,dc= local 9 URI ldap :// debian. pharma. local ldap :// debian - master. pharma. local :666 11 # SIZELIMIT 12 12 # TIMELIMIT 15 13 # DEREF never 14 15 # TLS certificates ( needed for GnuTLS ) 16 TLS_CACERT / etc / ssl / certs /ca - certificates. crt Fichier de configuration de log de LSC, soit dans notre cas: /etc/openldap2ad/logback.xml 1 <? xml version ="1.0" encoding =" UTF -8"? > 2 3 < configuration > 4 5 <!-- Standard output to console -- > 6 < appender name =" CONSOLE " class =" ch.qos. logback. core. ConsoleAppender " > 7 < encoder class =" ch.qos. logback. core. encoder. LayoutWrappingEncoder "> 8 < layout class =" org. lsc. utils. output. LdifLayout "> 9 <Pattern >% date { MMM dd HH:mm:ss} - % -5 level - % message %n </ Pattern > 10 </ layout > 11 </ encoder > 12 </ appender > 13 14 <!-- Log all application messages -- > 15 <!-- this file is rotated every 10000 KB, compressed and 7 files are kept for history -- > 16 < appender name =" LSC " class =" ch.qos. logback. core. rolling. RollingFileAppender "> 39 Année 2014-2015
17 <file >/ var / log / lsc / lsc.log </ file > 18 19 < layout class =" org. lsc. utils. output. LdifLayout "> 20 <Pattern >% date { MMM dd HH:mm:ss} - % -5 level - % message %n </ Pattern > 21 </ layout > 22 23 < filter class =" ch.qos. logback. classic. filter. ThresholdFilter " > 24 <level >INFO </ level > 25 </ filter > 26 27 < rollingpolicy class =" ch.qos. logback. core. rolling. FixedWindowRollingPolicy "> 28 < FileNamePattern > lsc. log.%i.gz </ FileNamePattern > 29 < MinIndex >1 </ MinIndex > 30 < MaxIndex >7 </ MaxIndex > 31 </ rollingpolicy > 32 33 < triggeringpolicy class =" ch.qos. logback. core. rolling. SizeBasedTriggeringPolicy "> 34 < MaxFileSize >10000 KB </ MaxFileSize > 35 </ triggeringpolicy > 36 </ appender > 37 38 39 <!-- Log for status (to use with check_lsc_status_file.pl --> 40 <!-- this file is erased at each execution -- > 41 < appender name =" LSC_STATUS " class =" ch.qos. logback. core. FileAppender " > 42 <append > false </ append > 43 <file >/ var / log / lsc / lsc. status </ file > 44 45 < layout class =" org. lsc. utils. output. LdifLayout "> 46 <Pattern >% date { MMM dd HH:mm:ss} - % -5 level - % message %n </ Pattern > 47 </ layout > 48 49 < filter class =" ch.qos. logback. classic. filter. ThresholdFilter " > 50 <level >INFO </ level > 51 </ filter > 52 </ appender > 53 54 <!-- Special logger to have a LDIF file of all modifications applied -- > 55 <!-- this file is rotated every 10000 KB, compressed and 7 files are kept for history -- > 56 < appender name =" LDIF " class =" ch.qos. logback. core. rolling. RollingFileAppender "> 40 Année 2014-2015
57 <file >/ var / log / lsc / lsc.ldif </ file > 58 59 < layout class =" org. lsc. utils. output. LdifLayout "> 60 <Pattern >%m%n </ Pattern > 61 <onlyldif >true </ onlyldif > 62 </ layout > 63 64 < filter class =" ch.qos. logback. classic. filter. ThresholdFilter " > 65 <level >INFO </ level > 66 </ filter > 67 68 < rollingpolicy class =" ch.qos. logback. core. rolling. FixedWindowRollingPolicy "> 69 < FileNamePattern > lsc. ldif.% i. gz </ FileNamePattern > 70 < MinIndex >1 </ MinIndex > 71 < MaxIndex >7 </ MaxIndex > 72 </ rollingpolicy > 73 74 < triggeringpolicy class =" ch.qos. logback. core. rolling. SizeBasedTriggeringPolicy "> 75 < MaxFileSize >10000 KB </ MaxFileSize > 76 </ triggeringpolicy > 77 </ appender > 78 79 <!-- Main LSC messages -- > 80 <logger name =" org. lsc " level =" INFO "> 81 <appender - ref ref =" LSC "/ > 82 <appender - ref ref =" LSC_STATUS "/ > 83 </ logger > 84 <!-- Messages for LDIF output -- > 85 <logger name =" lsc " level =" INFO "> 86 <appender - ref ref =" LDIF "/ > 87 </ logger > 88 <!-- Other messages -- > 89 <logger name =" communicationlogger " level =" WARN "> 90 <appender - ref ref =" CONSOLE "/ > 91 </ logger > 92 <logger name =" org. apache " level =" WARN "> 93 <appender - ref ref =" CONSOLE "/ > 94 </ logger > 95 <logger name =" poollogger " level =" WARN "> 96 <appender - ref ref =" CONSOLE "/ > 97 </ logger > 98 <!-- Root logger --> 99 <root level =" INFO "> 100 <appender - ref ref =" CONSOLE "/ > 101 </root > 102 </ configuration > 41 Année 2014-2015
Fichier de configuration de LSC qui contient la tâche de synchronisation OpenLDAP/AD que nous avons utilisée pour les tests: /etc/openldap2ad/lsc.xml 1 <? xml version ="1.0"?> 2 <!-- 3 In the following file, comments are describing each node. Elements are 4 referenced through XPath expression, whereas attributes are prefixed with 5 @ 6 7 // lsc Root node of the XML configuration file 8 @ xmlns XML Schema validation is not ready yet ( Reserved for futur use ) 9 @id optional, added by XML API 10 @revision mandatory, used by the Web Administration Interface to version 11 this file 12 --> 13 <lsc xmlns =" http :// lsc - project. org / XSD /lsc -core -2.1. xsd " revision ="0" > 14 15 <!--./ connections Connections list node, must contain at least two connections -- > 16 17 < connections > 18 < ldapconnection > 19 <name > openldap </ name > 20 <!--./ url mandatory, the JNDI URL -- > 21 <url > ldap :// localhost :389/ dc=debian,dc=pharma,dc=local </ url > 22 <!--./ username mandatory, the DN to bind with -- > 23 <username >cn=admin,dc=debian,dc=pharma,dc=local </ username > 24 <!--./ password mandatory, credentials to bind with -- > 25 <password >toor </ password > 26 <!--./ authentication mandatory, must contain either ANONYMOUS, SIMPLE, SASL, GSSAPI or DIGEST_ MD5 -- > 27 < authentication > SIMPLE </ authentication > 28 <!--./ referral mandatory, must contain either IGNORE, THROUGH, THROW or FOLLOW -- > 29 <referral > IGNORE </ referral > 30 <!--./ derefaliases mandatory, must contain either NEVER, SEARCH, FIND, ALWAYS -- > 31 < derefaliases > NEVER </ derefaliases > 32 <!--./ version mandatory, must contain either VERSION_ 2, VERSION_ 3 -- > 33 <version > VERSION_3 </ version > 42 Année 2014-2015
34 <!--./ pagesize optional, specify the paged size when searching -- > 35 <pagesize > -1 </ pagesize > 36 <!--./ factory mandatory, points to LDAP Context Factory, com. sun. jndi. ldap. LdapCtxFactory for a SUN JDK --> 37 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 38 <!--./ tlsactivated optional, specify if SSL / TLS is activated to connect to the LDAP server -- > 39 < tlsactivated > false </ tlsactivated > 40 </ ldapconnection > 41 < ldapconnection > 42 <name >AD </ name > 43 <!--./ url mandatory, the JNDI URL -- > 44 <url > ldaps :// ServeurAD. pharma. local :636/ dc=pharma,dc= local </ url > 45 <!--./ username mandatory, the DN to bind with -- > 46 <username >CN= Administrateur,CN=Users,DC=pharma,DC=local </ username > 47 <!--./ password mandatory, credentials to bind with -- > 48 <password >toor </ password > 49 <!--./ authentication mandatory, must contain either ANONYMOUS, SIMPLE, SASL, GSSAPI or DIGEST_ MD5 -- > 50 < authentication > SIMPLE </ authentication > 51 <!--./ referral mandatory, must contain either IGNORE, THROUGH, THROW or FOLLOW -- > 52 <referral > IGNORE </ referral > 53 <!--./ derefaliases mandatory, must contain either NEVER, SEARCH, FIND, ALWAYS -- > 54 < derefaliases > NEVER </ derefaliases > 55 <!--./ version mandatory, must contain either VERSION_ 2, VERSION_ 3 -- > 56 <version > VERSION_3 </ version > 57 <!--./ pagesize optional, specify the paged size when searching -- > 58 < pagesize >1000 </ pagesize > 59 <!--./ factory mandatory, points to LDAP Context Factory, com. sun. jndi. ldap. LdapCtxFactory for a SUN JDK --> 60 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 61 <!--./ tlsactivated optional, specify if SSL / TLS is activated to connect to the LDAP server -- > 62 < tlsactivated > false </ tlsactivated > 63 </ ldapconnection > 64 65 </ connections > 66 67 <tasks > 68 <task > 69 <name > syncusers </ name > 70 <bean > org. lsc. beans. SimpleBean </ bean > 71 < ldapsourceservice > 72 <name > openldap - source - service </ name > 43 Année 2014-2015
73 < connection reference =" openldap " / > 74 <basedn >cn=users,dc=debian,dc=pharma,dc=local </ basedn > 75 < pivotattributes > 76 <string >uid </ string > 77 </ pivotattributes > 78 < fetchedattributes > 79 <string >cn </ string > 80 < string > homedirectory </ string > 81 < string > givenname </ string > 82 <string >mail </ string > 83 <string >sn </ string > 84 <string >uid </ string > 85 < string > userpassword </ string > 86 </ fetchedattributes > 87 < getallfilter > <![ CDATA [( objectclass = inetorgperson ) ]] > </ getallfilter > 88 < getonefilter > <![ CDATA [(&( objectclass = inetorgperson )( uid ={ uid }))]] > </ getonefilter > 89 <cleanfilter > <![ CDATA [(&( objectclass = inetorgperson )( uid ={ samaccountname }))]] > </ cleanfilter > 90 </ ldapsourceservice > 91 < ldapdestinationservice > 92 <name >ad -dst - service </ name > 93 < connection reference =" AD" / > 94 <basedn >cn= Computers,dc=pharma,dc=local </ basedn > 95 < pivotattributes > 96 < string > samaccountname </ string > 97 </ pivotattributes > 98 < fetchedattributes > 99 <string >cn </ string > 100 < string > description </ string > 101 < string > givenname </ string > 102 <string >mail </ string > 103 < string > objectclass </ string > 104 < string > samaccountname </ string > 105 <string >sn </ string > 106 < string > unicodepwd </ string > 107 < string > useraccountcontrol </ string > 108 < string > userprincipalname </ string > 109 </ fetchedattributes > 110 < getallfilter > <![ CDATA [( objectclass = user )]] > </ getallfilter > 111 < getonefilter > <![ CDATA [(&( objectclass = user )( samaccountname ={ uid }))]] > </ getonefilter > 112 </ ldapdestinationservice > 113 < propertiesbasedsyncoptions > 114 < mainidentifier >" cn =" + srcbean. getdatasetfirstvaluebyid (" cn ") + ",cn= Computers,dc=pharma,dc= local " </ mainidentifier > 115 < defaultdelimiter >; </ defaultdelimiter > 44 Année 2014-2015
116 < defaultpolicy > FORCE </ defaultpolicy > 117 < conditions > 118 <create >true </ create > 119 <update >true </ update > 120 <delete >true </ delete > 121 <changeid >true </ changeid > 122 </ conditions > 123 < dataset > 124 < name > objectclass </ name > 125 <policy >KEEP </ policy > 126 < createvalues > 127 <string >" user " </ string > 128 <string >" organizationalperson " </ string > 129 <string >" person " </ string > 130 <string >" top " </ string > 131 </ createvalues > 132 </ dataset > 133 < dataset > 134 < name > samaccountname </ name > 135 <policy >KEEP </ policy > 136 < createvalues > 137 <string > srcbean. getdatasetfirstvaluebyid (" uid ") </ string > 138 </ createvalues > 139 </ dataset > 140 < dataset > 141 <!-- userprincipalname = uid + "@lsc - project. org " --> 142 < name > userprincipalname </ name > 143 <policy > FORCE </ policy > 144 < forcevalues > 145 <string > srcbean. getdatasetfirstvaluebyid (" uid ") + " @pharma. local " </ string > 146 </ forcevalues > 147 </ dataset > 148 < dataset > 149 < name > useraccountcontrol </ name > 150 <policy >KEEP </ policy > 151 < createvalues > 152 <string >AD. useraccountcontrolset ( "0", [AD. UAC_SET_NORMAL_ACCOUNT ]) </ string > 153 </ createvalues > 154 </ dataset > 155 < dataset > 156 <!-- unicodepwd = " changeit " at creation ( requires SSL connection to AD) -- > 157 < name > unicodepwd </ name > 158 <policy > FORCE </ policy > 159 < forcevalues > 160 <string >AD. getunicodepwd ( srcbean. getdatasetfirstvaluebyid (" userpassword ")) </ string > 161 </ forcevalues > 45 Année 2014-2015
162 </ dataset > 163 </ propertiesbasedsyncoptions > 164 </task > 165 </ tasks > 166 <!--./ security This mandatory node contains the security settings used by LSC -- > 167 < security > 168 <!--./ encryption This optional node contains the encryption settings -- > 169 < encryption > 170 <!--./ keyfile This optional node contains the keyfile location -- > 171 <keyfile > etc / lsc.key </ keyfile > 172 <!--./ algorithm This optional node contains the encryption algorithm -- > 173 <algorithm >AES </ algorithm > 174 <!--./ strength This optional node contains the algorithm key length -- > 175 < strength >128 </ strength > 176 </ encryption > 177 </ security > 178 </lsc > 46 Année 2014-2015
Fichier de configuration de LSC qui contient la tâche de synchronisation AD/OpenLDAP que nous avons utilisée pour les tests: /etc/ad2openldap/lsc.xml 1 <? xml version ="1.0"?> 2 <lsc xmlns =" http :// lsc - project. org / XSD /lsc -core -2.1. xsd " revision ="0" > 3 < connections > 4 < ldapconnection > 5 <name > openldap </ name > 6 <url > ldap :// localhost :389/ dc=debian,dc=pharma,dc=local </ url > 7 <username >cn=admin,dc=debian,dc=pharma,dc=local </ username > 8 <password >toor </ password > 9 < authentication > SIMPLE </ authentication > 10 <!--./ referral mandatory, must contain either IGNORE, THROUGH, THROW or FOLLOW -- > 11 <referral > IGNORE </ referral > 12 <!--./ derefaliases mandatory, must contain either NEVER, SEARCH, FIND, ALWAYS -- > 13 < derefaliases > NEVER </ derefaliases > 14 <!--./ version mandatory, must contain either VERSION_ 2, VERSION_ 3 -- > 15 <version > VERSION_3 </ version > 16 <!--./ pagesize optional, specify the paged size when searching -- > 17 <pagesize > -1 </ pagesize > 18 <!--./ factory mandatory, points to LDAP Context Factory, com. sun. jndi. ldap. pctxfactory for a SUN JDK --> 19 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 20 <!--./ tlsactivated optional, specify if SSL / TLS is activated to connect to the LDAP ver -- > 21 < tlsactivated > false </ tlsactivated > 22 </ ldapconnection > 23 < ldapconnection > 24 <name >AD </ name > 25 <url > ldaps :// ServeurAD. pharma. local :636/ dc=pharma,dc= local </ url > 26 <username >cn= Administrateur,cn=Users,dc=pharma,dc=local </ username > 27 <password >toor </ password > 28 < authentication > SIMPLE </ authentication > 29 <!--./ referral mandatory, must contain either IGNORE, THROUGH, THROW or FOLLOW -- > 30 <referral > IGNORE </ referral > 31 <!--./ derefaliases mandatory, must contain either NEVER, SEARCH, FIND, ALWAYS -- > 32 < derefaliases > NEVER </ derefaliases > 47 Année 2014-2015
33 <!--./ version mandatory, must contain either VERSION_ 2, VERSION_ 3 -- > 34 <version > VERSION_3 </ version > 35 <!--./ pagesize optional, specify the paged size when searching -- > 36 < pagesize >1000 </ pagesize > 37 <!--./ factory mandatory, points to LDAP Context Factory, com. sun. jndi. ldap. LdapCtxFactory for a SUN JDK --> 38 <factory > com. sun. jndi. ldap. LdapCtxFactory </ factory > 39 <!--./ tlsactivated optional, specify if SSL / TLS is activated to connect to the LDAP server -- > 40 < tlsactivated > false </ tlsactivated > 41 </ ldapconnection > 42 </ connections > 43 <tasks > 44 <task > 45 <name > syncusers </ name > 46 <bean > org. lsc. beans. SimpleBean </ bean > 47 < ldapsourceservice > 48 <name >ad - source - service </ name > 49 < connection reference =" AD" / > 50 <basedn >cn= Computers,dc=pharma,dc=local </ basedn > 51 < pivotattributes > 52 < string > samaccountname </ string > 53 </ pivotattributes > 54 < fetchedattributes > 55 <string >cn </ string > 56 < string > description </ string > 57 < string > givenname </ string > 58 <string >mail </ string > 59 < string > samaccountname </ string > 60 <string >sn </ string > 61 < string > unicodepwd </ string > 62 < string > useraccountcontrol </ string > 63 < string > userprincipalname </ string > 64 </ fetchedattributes > 65 < getallfilter > <![ CDATA [( objectclass = user )]] > </ getallfilter > 66 < getonefilter > <![ CDATA [(&( objectclass = user )( samaccountname ={ samaccountname }))]] > </ getonefilter > 67 <cleanfilter > <![ CDATA [(&( objectclass = user )( samaccountname ={ uid }))]] > </ cleanfilter > 68 </ ldapsourceservice > 69 < ldapdestinationservice > 70 <name > openldap -dst - service </ name > 71 < connection reference =" openldap " / > 72 <basedn >cn=users,dc=debian,dc=pharma,dc=local </ basedn > 73 < pivotattributes > 48 Année 2014-2015
74 <string >uid </ string > 75 </ pivotattributes > 76 < fetchedattributes > 77 <string >cn </ string > 78 < string > homedirectory </ string > 79 < string > givenname </ string > 80 <string >mail </ string > 81 <string >sn </ string > 82 <string >uid </ string > 83 < string > userpassword </ string > 84 < string > objectclass </ string > 85 < string > posixaccount </ string > 86 </ fetchedattributes > 87 < getallfilter > <![ CDATA [( objectclass = inetorgperson ) ]] > </ getallfilter > 88 < getonefilter > <![ CDATA [(&( objectclass = inetorgperson )( uid ={ samaccountname }))]] > </ getonefilter > 89 </ ldapdestinationservice > 90 < propertiesbasedsyncoptions > 91 < mainidentifier >" cn =" + srcbean. getdatasetfirstvaluebyid (" cn ") + ",cn=users,dc=debian,dc=pharma,dc= local " </ mainidentifier > 92 < defaultdelimiter >; </ defaultdelimiter > 93 < defaultpolicy > FORCE </ defaultpolicy > 94 < conditions > 95 <create >true </ create > 96 <update >true </ update > 97 <delete >true </ delete > 98 <changeid >true </ changeid > 99 </ conditions > 100 < dataset > 101 < name > objectclass </ name > 102 <policy >KEEP </ policy > 103 < createvalues > 104 <string >" inetorgperson " </ string > 105 </ createvalues > 106 </ dataset > 107 < dataset > 108 <name >uid </ name > 109 <policy >KEEP </ policy > 110 < createvalues > 111 <string > srcbean. getdatasetfirstvaluebyid (" samaccountname ") </ string > 112 </ createvalues > 113 </ dataset > 114 < dataset > 115 < name > homedirectory </ name > 116 <policy >KEEP </ policy > 117 < createvalues > 118 <string > srcbean. getdatasetfirstvaluebyid (" homedirectory ") </ string > 49 Année 2014-2015
119 </ createvalues > 120 </ dataset > 121 < dataset > 122 < name > userpassword </ name > 123 <policy >KEEP </ policy > 124 < createvalues > 125 <string > srcbean. getdatasetfirstvaluebyid (" unicodepwd ") </ string > 126 </ createvalues > 127 </ dataset > 128 </ propertiesbasedsyncoptions > 129 </task > 130 </ tasks > 131 <!--./ security This mandatory node contains the security settings used by LSC -- > 132 < security > 133 <!--./ encryption This optional node contains the encryption settings -- > 134 < encryption > 135 <!--./ keyfile This optional node contains the keyfile location -- > 136 <keyfile > etc / lsc.key </ keyfile > 137 <!--./ algorithm This optional node contains the encryption algorithm -- > 138 <algorithm >AES </ algorithm > 139 <!--./ strength This optional node contains the algorithm key length -- > 140 < strength >128 </ strength > 141 </ encryption > 142 </ security > 143 </lsc > 50 Année 2014-2015