Implémenter l’Annuaire

OpenLDAP et Authentification
Sommaire
1 Présentation de Service d’annuaire
1.1 Introduction
1.2 Caractéristiques
1.3 Avantages
1.4 Principales normes
2 Présentation de protocole LDAP
2.1 Protocole LDAP
2.2 Architecture LDAP
2.3 Session LDAP
2.4 Pourquoi utiliser LDAP ?
2.5 Annuaire LDAP ou Base de données?
2.6 Implémentations LDAP
3 Installation et configuration d’OpenLDAP
3.1 Caractéristiques d'OpenLDAP
3.2 Daemon et utilitaires d'OpenLDAP
3.3 Configuration d'OpenLDAP
3.4 Gestion de données dans OpenLDAP
3.5 Authentification LDAP depuis un client
3.6 Informations supplémentaires

1 Présentation de Service d’annuaire

1.1 Introduction
Un annuaire est un système de stockage de données, dérivé des bases de données
hiérarchisées, permettant en particulier de conserver les données, c'est-à-dire les données
n'étant que peu mises à jour, comme les coordonnées des personnes, des partenaires, des
clients et des fournisseurs d'une entreprise, les adresses électroniques. La recherche peut se
faire selon de multiples critères et les données peuvent être utilisées par des logiciels clients
comme des applications serveurs (serveur de messagerie: Postfix, Sendmail, etc.).
En outre, certaines versions de service d'annuaires savent gérer les droits sur les
données mais aussi les services proposés sur les machines clientes par une authentification
grâce à un couple login/mot de passe. Aujourd'hui ces données sont centralisées sur une ou
plusieurs machines et les données sont transférées entre les machines via des protocoles
réseaux.
Grâce à des optimisations, un annuaire est beaucoup plus rapide en consultation
qu'en mise à jour, contrairement à une base de données classique. La performance des
processeurs et des serveurs tend à diminuer la lourdeur des bases de données, ce qui
permet aux données dynamiques de se rapprocher des données statiques plus rapides à
servir.
 1.2 Caractéristiques
C'est un système qui organise des informations physiques ou numériques; tout annuaire
électronique comprend notamment :
 Un index qui facilite la communication entre des entités ;
 Une organisation hiérarchique optimisée pour un accès rapide à de
nombreuses informations en petits volumes ;
 Des entités et objets sous la forme de personnes, de communautés, de
ressources ou d'équipements ;
 Des accès aux bases de données mises à jour par les utilisateurs des
applications informatiques.
1.3 Avantages
Même principe que les annuaires papiers, mais avec les avantages du numérique :
 Puissants : recherches multicritères complexes ;
 Dynamiques : mises à jour plus faciles ;
 Souples : possibilité d’évolution de la structure des données ;
 Sûrs : authentification, contrôles d’accès ;
 Personnalisables : affichage en fonction de l’utilisateur.
1.4 Principales normes
 X.500 désigne l'ensemble des normes informatiques sur les services d'annuaire
définies par l'UIT-T. Mais seule la partie X509 concernant l'authentification est
utilisée actuellement; pour le reste, la plupart des services d'annuaire actuels
utilisent une norme beaucoup moins lourde : LDAP.
 LDAP (Lightweight Directory Access Protocol) est un protocole permettant
l'interrogation et la modification des services d'annuaire. Ce protocole repose sur
TCP/IP. Un annuaire LDAP respecte généralement le modèle X500 : c'est une
structure arborescente dont chacun des nœuds est constitué d'attributs associés à
leurs valeurs.
 UDDI (Universal Description Discovery and Integration): cette norme créée en
octobre 2000 est utilisée pour le commerce électronique.

2 Présentation de protocole LDAP

2.1 Protocole LDAP
Le protocole LDAP (Lightweight Directory Access Protocol) est en fait un ensemble de
protocoles ouverts utilisés pour accéder à des informations stockées localement sur un
réseau. Il est basé sur le standard X.500 pour le partage de répertoires, mais est moins
complexe et moins gourmand en ressources, d'où la référence à LDAP sous le terme « X.500
Lite ». Le standard X.500 est un répertoire qui contient des informations hiérarchisées et
organisées pouvant inclure des renseignements tels que des noms, des adresses et des
numéros de téléphone.
Comme X.500, LDAP organise des informations d'une manière hiérarchique en
utilisant des répertoires. Ces répertoires peuvent stocker diverses informations et peuvent
même être utilisés d'une manière semblable au service d'informations réseau (ou NIS),
permettant à tout un chacun d'accéder à son compte depuis une machine quelconque
présente sur un réseau sous LDAP.
 Dans la plupart des cas, LDAP sert d'annuaire téléphonique virtuel, permettant aux
utilisateurs d'accéder facilement aux coordonnées d'autres utilisateurs. Mais le protocole
LDAP est beaucoup plus flexible qu'un annuaire téléphonique traditionnel car il peut
renvoyer un demandeur vers d'autres serveurs LDAP de par le monde, fournissant ainsi un
référentiel d'informations global et improvisé.
À l'heure actuelle cependant, le protocole LDAP est plus généralement utilisé au sein
de grandes organisations comme des universités, des services gouvernementaux et des
entreprises du secteur privé.
2.2 Architecture LDAP
Le protocole LDAP est un système client/serveur. Le serveur peut utiliser diverses
bases de données pour stocker un répertoire, chacune d'elles étant optimisée de façon à
permettre des opérations de consultation rapides et en grande quantité. Lorsqu'un client
LDAP se connecte à un serveur LDAP, il peut soit consulter un répertoire, soit y apporter des
modifications.
Lors de l'arrivée d'une requête, le serveur y répond localement ou la renvoie à un
serveur LDAP de niveau supérieur qui aura lui la réponse. Si l'application cliente tente de
changer des informations dans un répertoire LDAP, le serveur vérifie d'abord que l'utilisateur
est bien autorisé à effectuer des changements et ensuite ajoute ou met à jour les
informations.
Ce TP décrit la configuration et l'utilisation de OpenLDAP 2.0, une implémentation
Open Source des protocoles LDAPv2 et LDAPv3.
2.3 Session LDAP
Un client commence une session LDAP en se connectant sur le port TCP 389 du
serveur. Le client envoie ensuite des requêtes d'opération au serveur. Le serveur envoie des
réponses en retour. À part quelques exceptions, le client n'a pas besoin d'attendre de
réponse du serveur pour envoyer de nouvelles requêtes, et le serveur peut envoyer ses
réponses dans n'importe quel ordre.

Une méthode pour sécuriser les communications LDAP est d'utiliser un tunnel
TLS/SSL. Lors de l'emploi d'URL cet usage est traduit par le nom du protocole LDAPs en
remplacement de LDAP. Le port TCP standard pour LDAPs est 636.
 2.4 Pourquoi utiliser LDAP ?
Le principal avantage du protocole LDAP réside dans la possibilité de réunir les
informations concernant toute une organisation dans un lieu central. De plus, puisque LDAP
prend en charge les fonctions SSL/TLS, des données confidentielles peuvent être protégées
contre toute intrusion.
LDAP prend aussi en charge diverses bases de données parallèles pour y enregistrer
des répertoires. Ainsi, les administrateurs disposent de la flexibilité nécessaire pour déployer
la base de données la plus adaptée au type d'informations que le serveur doit disséminer.
De plus, comme LDAP comporte une interface de programmation d'application (API)
bien définie, le nombre d'applications compatibles avec LDAP est vaste et croissant aussi
bien en quantité qu'en qualité.
2.5 Annuaire LDAP ou Base de données?
Pourquoi utilisons-nous un annuaire LDAP et pas une simple base de données ?
Un annuaire est un type de base de données spécifique, c'est-à-dire qu'il s'agit d'une sorte
de base de données ayant des caractéristiques particulières :
 Un annuaire est prévu pour être plus sollicité en lecture qu'en écriture.
 Les données sont stockées de manière hiérarchique dans l'annuaire, tandis
que les bases de données dites « relationnelles » stockent les
enregistrements de façon tabulaire.
 Les annuaires doivent être compacts et reposer sur un protocole réseau léger.
 Un annuaire doit comporter des mécanismes permettant de rechercher
facilement une information et d'organiser les résultats.
 Les annuaires doivent pouvoir être répartis. Cela signifie qu'un serveur
d'annuaire doit comporter des mécanismes permettant de coopérer, c'est-à-
dire d'étendre la recherche sur des serveurs tiers si jamais aucun
enregistrement n'est trouvé.
 Un annuaire doit être capable de gérer l'authentification des utilisateurs ainsi
que les droits de ceux-ci pour la consultation ou la modification de données.
2.6 Implémentations LDAP
Les implémentations LDAP / X.500 incluent:
 Active Directory: service d'annuaire de Microsoft pour Windows, provenant du
répertoire X.500, créé pour être utilisé dans Exchange Server.
 389 Directory Server: Implémentation gratuite du serveur Open Source par RedHat.
 Red Hat Directory Server: Produit commercial s'exécutant sur Red Hat Enterprise
Linux en tant que projet 389 Directory Server pris en charge par la communauté. Le
projet open source en amont s’appelle FreeIPA.
 Apache Directory Server: service d'annuaire, écrit en Java, prenant en charge LDAP,
Kerberos 5 et le protocole de modification du mot de passe; Certifié LDAPv3.
 Apple Open Directory: serveur d'annuaire Apple pour Mac OS X, disponible via Mac
OS X Server.
 eDirectory: la mise en œuvre des services d'annuaire par NetIQ prend en charge
plusieurs architectures, notamment Windows, NetWare, Linux et plusieurs versions
d'Unix. précédemment connu sous le nom de Novell Directory Services.
 Oracle Internet Directory: (OID) est le service d'annuaire d'Oracle Corporation,
compatible avec LDAP version 3.
  Serveur d'annuaire Sun Java System: service d'annuaire de Sun Microsystems.
 OpenDS: service d'annuaire open-source en Java, soutenu par Sun Microsystems.
 IBM Tivoli Directory Server: version personnalisée d'une ancienne version
OpenLDAP.
 Les services d’annuaire Windows NT (NTDS), renommés ultérieurement Active
Directory, ont remplacé l’ancien système de domaine NT.
 OpenLDAP: dérivée de la mise en œuvre LDAP originale de l’Université du Michigan,
elle prend en charge toutes les architectures informatiques (y compris les dérivés
Unix et Unix, Linux, Windows, z/OS et un certain nombre de systèmes embarquée
temps réel.
 IBM Lotus Domino.
 OpenDJ - un serveur LDAP et un client d'annuaire basé sur Java qui s'exécute dans
n'importe quel environnement d'exploitation, sous licence CDDL.
Note : Les outils Open Source permettant de créer des services d’annuaire comprennent
OpenLDAP, le protocole Kerberos et le logiciel Samba, qui peuvent fonctionner en tant que
contrôleur de domaine Windows avec des back-end Kerberos et LDAP.
L'administration se fait par GOsa², PHPLDAPAdmin, Apache Directory Server,
FusionDirectory, Jxplorer, ou Samba SWAT.
3 Installation et configuration d’OpenLDAP
3.1 Caractéristiques d'OpenLDAP
OpenLDAP comprend un certain nombre de caractéristiques importantes parmi
lesquelles figurent :
 Prise en charge de LDAPv3 : OpenLDAP prend en charge SASL (Simple Authentication
and Security Layer), TLS/SSL entre autres améliorations. De nombreux changements
apportés au protocole depuis LDAPv2 visent à augmenter la sécurité de LDAP.
 Prise en charge d’IPv6 : OpenLDAP prend en charge le protocole de la prochaine
génération, Internet Protocol version 6.
 LDAP sur IPC : OpenLDAP peut communiquer au sein d'un système en utilisant IPC
(InterProcess Communication). Il en résulte une sécurité améliorée car il n'est plus
nécessaire de communiquer à travers un réseau.
 Mise à jour de C API : Améliore la manière dont les programmeurs se connectent aux
serveurs de répertoires LDAP et les utilisent.
 Amélioration du serveur autonome LDAP : À présent le serveur inclut entre autres
un système de contrôle d'accès mis à jour, un pool de conversation et des outils plus
performants.
 Prise en charge de LDIFv1 : Grâce à cette prise en charge, OpenLDAP 2.0 est
pleinement compatible avec la version 1 du format LDIF (LDAP Data Interchange
Format).
3.2 Daemon et utilitaires d'OpenLDAP
3.2.1 Installation des paquetages
La suite de bibliothèques et d'outils OpenLDAP est incluse dans les paquetages suivants :
 openldap — Contient les bibliothèques nécessaires pour faire fonctionner le serveur
OpenLDAP et les applications clientes.
  openldap-clients — Contient les outils de ligne de commande pour visualiser et
modifier les répertoires d'un serveur LDAP.
 openldap-servers — Contient les serveurs et autres utilitaires nécessaires pour
configurer et faire fonctionner un serveur LDAP.
3.2.2 Daemon OpenLDAP
Slapd est le démon LDAP autonome. Il écoute les connexions LDAP sur un nombre
quelconque de ports (389 par défaut), en réponse aux opérations LDAP qu'il reçoit sur ces
connexions.
# service slapd status
 slapd est généralement appelé au démarrage, généralement à partir de /etc/rc.local.

3.2.3 Fichiers de configuration d'OpenLDAP

Les fichiers de configuration d'OpenLDAP sont installés dans le répertoire
/etc/openldap/. Ci-dessous figure une brève liste des répertoires et fichiers les plus
importants :
 /etc/openldap/ldap.conf — Ce fichier est le fichier de configuration pour toutes les
applications clientes qui utilisent les bibliothèques OpenLDAP telles que ldapsearch,
ldapadd, Sendmail, Evolution et Gnome Meeting.
 /etc/openldap/slapd.conf — Ce fichier est le fichier de configuration du démon slapd.
 Le répertoire /etc/openldap/schema/ — Ce sous-répertoire contient le schéma utilisé
par le démon slapd.
3.2.3.1 Nouveautés
Historiquement, OpenLDAP a été configuré de manière statique, c'est-à-dire la
configuration sera consigner dans le fichier slapd.conf, ensuite le daemon slapd sera
redémarrer. Dans le cas des grands utilisateurs, cela pourrait prendre beaucoup de temps et
était devenu de plus en plus inacceptable en tant que méthode opérationnelle.
OpenLDAP version 2.3 a introduit une nouvelle fonctionnalité facultative grâce à laquelle
la configuration peut être effectuée au moment de l'exécution à l'aide d'une entrée DIT
(Directory Information Trees) appelée cn=config.
La fonctionnalité est connue par un nombre varié et déroutant de termes, y compris la
configuration en ligne (OLC, on-line configuration), la configuration sans temps mort,
cn=config et la configuration slapd.d. Tout d'abord, un certain nombre de points:
 La fonctionnalité est (à la version 2.4) toujours facultative, ce qui signifie que
slapd.conf, bien que officiellement déconseillé, continue de fonctionner.
 OpenLDAP a toujours été assez brutal pour retirer le support des capacités plus
anciennes. Cela signifie que la migration vers la configuration en ligne (OLC,
cn=config) doit être envisagée dès que possible.
 La configuration en ligne (OLC) utilise une configuration DIT pour contrôler la
configuration opérationnelle. Conceptuellement, en modifiant les entrées de cette
DIT (à l'aide d'un navigateur LDAP ou de fichiers LDIF), des changements immédiats
du comportement opérationnel de slapd sont déclenchés sans qu'il soit nécessaire de
redémarrer slapd comme vous le feriez après avoir modifié slapd.conf.
3.3 Configuration d'OpenLDAP
 3.3.1 Installation des paquetages
La bibliothèque OpenLDAP est installée par défaut sous CentOS 6.9. Avant de
commencer l’installation de serveur et de client OpenLDAP, vous devez entamer une
vérification de l’existence des paquetages :
# rpm -qa | grep openldap
openldap-2.4.40-16.el6.x86_64
# rpm -ihv openldap-clients-2.4.40-16.el6.x86_64.rpm
# rpm -ihv openldap-servers-2.4.40-16.el6.x86_64.rpm
3.3.2 Premier pas
Premièrement, le serveur qui va être un serveur OpenLDAP, il faut que l’ait un nom
complet, inscrit sur le serveur DNS (plus un nom ldap comme CNAME de serveur de nom).
Deuxièmes, vous devez copier le fichier de configuration DB_CONFIG qui est destiné
aux administrateurs d'environnement de base de données de personnaliser le paramétrage
de la base de données Berkeley, utilisée comme cache de stockage par OpenLDAP.
Par défaut, il n'y a pas de fichier DB_CONFIG créé. Par contre on peut trouver un
exemple dans /usr/share/openldap-servers/DB_CONFIG.example :
# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
# chown ldap:ldap /var/lib/ldap/DB_CONFIG
Finalement, en va générer un mot de passe chiffré pour l’administrateur qu’on va le
mettre dans le fichier de configuration OpenLDAP :
# slappasswd
New password:
Re-enter new password:
{SSHA}qh1XNqTNz3SANBIZnsXkF/Zv5f8KwLiN
 Copiez le mot de passe quelque part, vous en aurez besoins.
3.3.3 Configuration DIT
Il est intéressant de constater que notre DIT est contenu dans un fichier
olcDatabase={2}bdb.ldif. Sur un serveur CentOS 6, le format par défaut est effectivement le
format BDB (Berkeley DataBase), mais cela pourrait différer, l’évolution de BDB étant le HDB
(Hierarchical Database).
On va effectuer notre configuration dans le fichier olcDatabase{2}bdb.ldif se trouvant
dans le dossier /etc/openldap/slapd.d/cn\=config/ pour changer le nom de domaine et le
nom de domaine de Root.
Trouvez les lignes suivantes et éditez pour reflétez le nom de domaine que vous souhaitez.
olcSuffix: dc=ismontic,dc=ma
olcRootDN: cn=Manager,dc=ismontic,dc=ma
olcRootPW : {SSHA}qh1XNqTNz3SANBIZnsXkF/Zv5f8KwLiN
 « olcRootDN » est le DN de l’utilisateur qui va administrer OpenLDAP.
 C’est préférable d’ajouter olcRootPW directement après olcRootDN.
 Les mots de passe LDAP, y compris la directive « olcRootPW », sont envoyés sur le
réseau en texte clair, à moins que le chiffrement TLS ne soit activé.
3.3.4 Définir les droits d’accès
Avant de commencer à remplir et utiliser l’annuaire, il faut configurer une base et
définir les droits d’accès. Toute cette configuration se fait dans olcDatabase\=\
{1\}monitor.ldif se trouvant dans le même dossier cn=config/.
# vim /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{1\}monitor.ldif
...
olcAccess: {0}to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.base="cn=Manager,dc=ismontic,dc=ma" read
by * none
 Pour rendre la ligne olcAccess plus lisible, on a séparé la ligne comme présenté ci-
dessus, mais n’oublier pas que chaque fin de ligne d’olcAccess il y a deux espace.
 Mettre à jour la base de données DB_CONFIG avec la commande « # updatedb ».
 Tester la configuration avec la commande « # slaptest -u ».
# slaptest -u
5c6c7cf3 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif"
5c6c7cf3 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif"
config file testing succeeded
 Pour cette étape, on va ignorer les messages d’erreurs.
 Pour résoudre cette anomalie, à chaque modification de ces fichiers, générez un
checksum avec la commande crc32.
# cat olcDatabase\=\{1\}monitor.ldif | tail -n +3 > test01
Code_checksum
# crc32 test01
# cat olcDatabase\=\{2\}bdb.ldif | tail -n +3 > test01
# crc32 test01
Code_checksum
o Ensuite, on va copier le code vers ces fichiers en remplaçant l’ancien code qui
se trouve au 2éme ligne par le nouveau code.
 Tapez les deux commandes suivantes afin de lancer automatique OpenLDAP au
démarrage du serveur et pour le démarrer.
# chkconfig slapd on
# service slapd start
# netstat -tunlp | grep slapd
3.4 Gestion de données dans OpenLDAP
Vous avez maintenant un serveur LDAP en service prêt à recevoir des informations.
La méthode standard pour fournir des informations au serveur LDAP consiste à créer un
fichier LDIF (LDAP Directory Interchange Format).
LDIF est la représentation au format texte des entrées ldap. Ces entrées sont
directement lisibles et sont interchangeables entre des serveurs LDAP de différents
concepteurs, utilisant différents gestionnaires de base de données ou fonctionnant sous des
systèmes d'exploitation différents.
Les fichiers de type LDIF sont utilisés d'une part pour décrire des objets d'un annuaire
LDAP (Configuration via commande), et d'autre part pour décrire un ensemble d'opérations
à effectuer sur le contenu d'un annuaire.
 3.4.1 Création de l’annuaire
Tous d’abord, nous voulons créer le domaine LDAP pour qu’il aille accueillir les futurs
objets LDAP. Dans ce TP on va choisir l’arborescence LDAP la plus simple.

Explication :
 Le premier niveau nommé (organization - o), il s'agit de l'entreprise de la
personne.
 Le deuxième niveau, contient les unités d’organisation qui vont contenir les
objets :
o L’unité d’organisation People va contenir les objets utilisateurs ;
o L’unité d’organisation machines va contenir les objets ordinateurs ;
o L’unité d’organisation Applications va contenir les objets relier aux
applications;
o L’unité d’organisation Groups va contenir les objets groupes utilisateurs.
Créez un fichier base.ldif, qui va nous aider à initier notre annuaire LDAP avec les
entrées suivantes :
# vim base.ldif
dn: dc=ismontic,dc=ma
objectclass: dcObject
objectclass: organization
o: ismontic
dc: ismontic

dn: cn=Manager, dc=ismontic,dc=ma

objectclass: organizationalRole
cn: Manager
Puis tapez la commande suivante afin d’importer les changements dans la base de
donnée LDAP.
# ldapadd -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f base.ldif
Enter LDAP Password:
adding new entry " dc=ismontic,dc=ma "
adding new entry "cn=Manager, dc=ismontic,dc=ma "
 -x : Une simple authentification (ne pas utiliser SASL).
 -D : Utilisez le nom DN pour vous connecter à l'annuaire LDAP.
  -W : Demander une authentification simple. Ceci est utilisé au lieu de spécifier
le mot de passe sur la ligne de commande.
o En peut mettre -w mot_de_passe au lieu de -W.
 -f : Lire les informations de modification d’entrée à partir du fichier au lieu de
l’entrée standard.
Attention ! Si vous recevez l’erreur « ldap_bind: Invalid credentials (49) », ça veut dire que
l’étape de création de mot de passe pour l’administrateur a échoué.
Refaire la même démarche pour créer les unités d’organisation:
# vim ou_level1.ldif
dn: ou=people, dc=ismontic,dc=ma
ou: people
objectclass: organizationalUnit
objectclass: domainRelatedObject
associatedDomain: ismontic.ma

dn: ou=groups, dc=ismontic,dc=ma

ou: groups
objectclass: organizationalUnit
objectclass: domainRelatedObject
associatedDomain: ismontic.ma

dn: ou=machines, dc=ismontic,dc=ma

ou: machines
objectclass: organizationalUnit
objectclass: domainRelatedObject
associatedDomain: ismontic.ma

dn: ou=Applications, dc=ismontic,dc=ma

ou: Applications
objectclass: organizationalUnit
objectclass: domainRelatedObject
associatedDomain: ismontic.ma
Importer les changements dans la base de données LDAP.
# ldapadd -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f ou_level1.ldif
3.4.2 Création des objets utilisateurs et groupes d’utilisateurs
L’étape suivante, est de peupler les unités d’organisation « People » et « Groups »
par les objets convenables pour chacun.
# vim user_add.ldif
dn: uid=ld-user01,ou=people,dc=ismontic,dc=ma
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
cn: ld-user01
sn: sn-user01
givenName: gn-user01
telephoneNumber: 0661122334
mail: ld-user01@ismontic.ma
uidNumber: 999
gidNumber: 999
homeDirectory: /home/guests/ld-user01
loginShell: /bin/bash
userPassword: p@ssw0rd123

dn: uid=ld-user02,ou=people,dc=ismontic,dc=ma
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
cn: ld-user02
sn: sn-user02
givenName: gn-user02
mail: ld-user02@ismontic.ma
telephoneNumber: 0665566778
uidNumber: 888
gidNumber: 999
homeDirectory: /home/guests/ld-user02
loginShell: /bin/bash
userPassword: {ssha}x
 Chaque objectClass à sa propre attributs (Obligatoire et optionnel), et qui hérite des
attributs des autres objectClass. Par exemple inetOrgPerson hérite de l’objet Person.
 La raison de travailler avec la classe d’objet posixAccount, est que nous voulions
avoir l’UID et GID qui va nous permet de s’identifier avec ces utilisateurs.
 La classe d’objet Top est la classe racine.
 Que l’arborescence suivant /home/guests/ld-user01/ doit exister sur le serveur.
Pour le groupe, en va créer un autre fichier ldif, qui va contenir les lignes suivantes :
# vim group_add.ldif
dn: cn=users,ou=groups, dc=ismontic,dc=ma
objectClass: top
objectClass: posixGroup
cn: users
gidNumber: 999
description: "groupe de test"
memberuid: ld-user01
memberuid: ld-user02
Importer les changements dans la base de données LDAP.
# ldapadd -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f user_add.ldif
# ldapadd -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f group_add.ldif
3.4.3 Création d’objets Machine
3.4.4 Rechercher ou lire des objets LDAP
Avec ldapsearch, fournit un outil de ligne de commande pour la recherche de
données au sein d'un annuaire LDAP et pour la lecture de données depuis ce dernier. Une
requête simple emploierait la syntaxe suivante :
# ldapsearch -x -b "dc=ismontic,dc=ma" "(objectClass=*)"
# ldapsearch -x -LLL -b "dc=ismontic,dc=ma" "(objectClass=person)"
  L'option -b détermine la base de recherche, la section de l'arborescence au sein de
laquelle la recherche doit être menée.
 L’option -x demande l'activation de l'authentification simple (Non SASL, s’il existe).
 (objectClass=*) indique que tous les objets contenus dans l'annuaire doivent être lus,
c’est le paramètre par défaut.
 L’option -LLL filtre le résultat de recherche à afficher.
o Un simple -L limite la sortie à LDIFv1.
o Un second -L désactive les commentaires.
o Un troisième -L désactive l'impression de la version LDIF.
o La valeur par défaut consiste à utiliser une version étendue de LDIF.
Autres exemples de recherche d’objet dans l’annuaire :
# ldapsearch -x -b "ou=people,dc=ismontic,dc=ma" "uid=ld-user01" mail
 Récupère le mail de l’objet ld-user01.
# ldapsearch -x -b "dc=ismontic,dc=ma" -s base '(objectclass=*)' namingContexts -LLL
dn: dc=ismontic,dc=ma
 Affiche le nom de domaine «DN (Distinguished Name) ».
 Si on veut les DN de tous les objets de l’annuaire, mettez l’option « -s sub ».
 Si on veut juste le DN de premier niveau de notre arborescence, mettez l’option « -s
one».
 Si on veut juste les DN des objets enfant d’une arborescence, mettez l’option « -s
children».
3.4.5 Modification des objets LDAP
L'outil ldapmodify est fourni pour modifier le stock de données. La meilleure façon
pour ce faire consiste à modifier le fichier LDIF correspondant avant de transmettre ce fichier
modifié au serveur LDAP.
Pour mettre à jour les attributs du l’objet ld-user02, vous avez entre trois choix
{Mettre à jour, Ajouter, et/ou supprimer}. Pour faire cela, créer un fichier ldif nommé
usermod.ldif :
# vim usermod.ldif
dn: uid=ld-user02,ou=people,dc=ismontic,dc=ma
changetype: modify
replace: telephoneNumber
telephoneNumber: 212539955662
-
add: description
description: the world's most famous manager
-
delete: telephoneNumber
-
Importez le fichier modifié dans l'annuaire LDAP à l'aide de la commande suivante :
# ldapmodify -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f usermod.ldif
Attention ! Vérifier qu’il n’y a pas d’espaces à la fin de chaque ligne, même dans le cas
d’une ligne vide, car il va empêcher les commandes « ldap* » de s’exécuter.
 3.4.6 Renommer un objet LDAP
Créer un fichier uidmod.ldif, qui contient les lignes suivant :
dn: uid=ld-user02,ou=people,dc=ismontic,dc=ma
changetype: modrdn
newrdn: uid= ld-user03
deleteoldrdn: 0
Les valeurs de l’attribut « DeleteOldRDN » sont:
 0 - FAUX - indique que le RDN doit être conservé en tant qu'attribut distinct,
l'ancienne valeur d'attribut RDN est conservée sur l'entrée LDAP.
o 0 - FALSE est la valeur par défaut (si aucune valeur n'est présente, ou si des
valeurs illégales sont présentes).
 1 - VRAI - indique que le RDN ne doit PAS être conservé, car l'ancienne valeur
d'attribut RDN est supprimée de l'entrée LDAP
Importez le fichier modifié dans l'annuaire LDAP à l'aide de la commande suivante :
# ldapmodify -x -D "cn=Manager, dc=ismontic,dc=ma" -W -f uidmod.ldif
3.4.7 Déplacer un objet LDAP
Si vous devez déplacer l'entrée vers un nouvel emplacement, un paramètre
supplémentaire pour changegetype: modrdn est l'option « newsuperior: ». Lorsque vous
utilisez cette option, vous pouvez spécifier un nouvel emplacement sur le DIT vers lequel
déplacer l’entrée. Cela placera l'entrée sous le DN parent spécifié lors de la modification.
# vim rdnmove.ldif
# dn: uid=ld-user03,ou=people,dc=ismontic,dc=ma
changetype: modrdn
newrdn: uid= ld-user03
deleteoldrdn: 0
newsuperior: ou=Applications,dc=ismontic,dc=ma
3.4.8 Modifier le mot de passe
Pour modifier le mot de passe de l’utilisateur ld-user02, il faut utiliser la commande
client « ldappasswd » comme suite :
# ldappasswd -x -D "cn=Manager,dc=ismontic,dc=ma" -W -s nouv_MDP "uid=ld-user03,ou=
Applications,dc=ismontic,dc=ma"
Ou:
# ldappasswd -x -D "cn=Manager,dc=ismontic,dc=ma" -W -S "uid=ld-user03,ou=
Applications,dc=ismontic,dc=ma"
3.4.9 Suppression des objets LDAP
Pour supprimer les entrées d’un annuaire LDAP, il faut utiliser la commande
ldapdelete. Par exemple, pour supprimer l'entrée complète de ld-user02, utilisez la
commande suivante :
# ldapdelete -x -D "cn=Manager,dc=ismontic,dc=ma" -W
"uid=ld-user03,ou=Applications,dc=ismontic,dc=ma"
 3.5 Authentification LDAP depuis un client
3.5.1 Prérequis
L'utilisation de LDAP pour la gestion des comptes Unix requiert plusieurs composants:
PAM, NSS et un schéma LDAP adéquat, reconnu par pam_ldap et nss_ldap.
Pour faire cela, la machine cliente doit avoir les paquetages suivants :
 nss-pam-ldapd-0.7.5-32.el6.i686
 pam_ldap-185-11.el6.i686
 sssd-ldap-1.13.3-56.el6.i686
 sssd-client-1.13.3-56.el6.i686
 openldap-2.4.40-16.el6.i686
3.5.1.1 NSS
NSS (Name Service Switch, commutateur de services de nommages), permet de
fournir à Unix non des services d'authentification, mais des services de correspondances
« mappage » entre noms, de toutes sortes (noms de machines et noms d'utilisateurs
intelligibles par l'homme, par exemple), et les identifiants de ces mêmes objets pour la
machine local (adresses IP et UID/GID).
NSS, comme PAM, est composée de greffons sous formes de bibliothèques
dynamiques, Le paramétrage est plus limité, non unifié entre eux (au contraire de PAM), et
se fait principalement dans /etc/nsswitch.conf.
3.5.1.2 PAM et LDAP
Le module pam_ldap permet aux applications fonctionnant avec PAM d'authentifier
les utilisateurs en utilisant les informations stockées dans une base LDAP. Les applications
fonctionnant avec PAM comprennent la connexion console, les serveurs de messagerie POP
et IMAP ainsi que Samba.
En déployant un serveur LDAP sur votre réseau, toutes ces applications peuvent, pour
leur authentification, utiliser la même combinaison identifiant d'utilisateur/mot de passe, ce
qui simplifie considérablement l'administration.
3.5.1.3 SSSD
Le démon de services de sécurité système (SSSD) fournit un ensemble de démons
permettant de gérer l'accès aux répertoires distants et aux mécanismes d'authentification. Il
fournit des interfaces NSS (Name Service Switch) et des modules PAM vers le système, ainsi
qu'un système dorsal enfichable pour se connecter à plusieurs sources de compte
différentes.
Le principal avantage en comparaison avec nss_ldap est que les informations
d'authentification restent dans le cache et que l'authentification peut néanmoins continuer à
se faire, même en mode déconnecté (quand le serveur n'est plus accessible).
SSSD fournit les fonctions suivantes :
 Résolution d'identité - module NSS ;
 Authentification - Module PAM ;
 Mise en cache pour un accès hors connexion et un traitement réduit de la
base de données ;
 Multiples sources en configuration unique (sources communes: LDAP, AD,
KRB).
Voici le diagramme de fonctionnalité SSSD :

3.5.2 Etapes de configuration

3.5.2.1 Prérequis
Dans cette partie, on va configurer une seconde machine qui va être un client LDAP,
pour deux principales tâches :
 Authentifier les utilisateurs LDAP depuis la machine cliente;
 Consulter les informations LDAP de la base de données.
Noter que pour vous puissiez utiliser les commandes cliente ldap*, vous devez les
installer via le paquetage « openldap-clients-2.4.40-16.el6.x86_64 ».
# rpm -ihv openldap-clients-2.4.40-16.el6.x86_64.rpm
Avant de commencer, n’oublier pas de spécifier l’adresse de serveur DNS dans le
fichier /etc/resolv.conf, pour qu’on puisse résoudre le nom de domaine de serveur LDAP.
domain ismontic.ma
search ismontic.ma
nameserver @Server_DNS
On va vérifier que l’utilisateur ld-user01 n’existe pas sur la machine cliente LDAP.
# grep ld-user01 /etc/passwd
Ou
# getent passwd ld-user01
Ou
# su - ld-user01
3.5.2.2 Création de certificat et clés privé TLS
SSSD nécessite une communication chiffrée de protocole LDAP à l'aide d'un certificat
TLS (LDAPS). Et si se passe des anomalies de certificats durant la session TLS, la session TLS
sera terminée immédiatement. Pour empêcher cela de se produire entre le Serveur et Client
LDAP dans notre environnement de test. On va désactiver la vérification de certificat TLS
pour une simple raison, c’est pour se concentrer sur la phase d’authentification de
l’utilisateur LDAP depuis la machine cliente.
Tous d’abord, commençons par la création d’un certificat auto signé et la clé privé à
l’aide la commande openssl depuis le serveur:
# openssl req -nodes -new -x509 -keyout ldapkey.pem -out ldap.pem -days 365
 req : Crée et traite principalement les demandes de certificat au format
PKCS#10. Il peut en outre créer des certificats auto-signés à utiliser comme
autorités de certification racine.
 -nodes: si cette option est spécifiée, si une clé privée est créée, elle ne sera
pas chiffrée.
 -new: cette option génère une nouvelle demande de certificat. Il demandera à
l'utilisateur les valeurs de champ pertinentes. Les champs réels demandés et
leurs tailles maximales et minimales sont spécifiés dans le fichier de
configuration et toutes les extensions demandées.
 -x509: cette option génère un certificat auto-signé au lieu d’une demande de
certificat. Ceci est généralement utilisé pour générer un test certificat ou une
autorité de certification auto-signée.
 -keyout ldapkey.pem : la clé privée sera créé dans le fichier.
 -out ldap.pem : le fichier de sortie contiendra le certificat auto-signé.
 -jours n : lorsque l'option -x509 est utilisée, cela spécifie le nombre de jours
pour certifier le certificat. La valeur par défaut est 30 jours.
Ensuite, il faut copier le nouveau certificat et la clé privée vers le dossier
/etc/openldap/newcerts/ :
# cp ldap.pem /etc/openldap/newcerts/
# cp ldapkey.pem /etc/openldap/newcerts/
# chown -R ldap:ldap /etc/openldap/newcerts/
Au final, il faut spécifier l’emplacement de certificat et la clés privé dans le fichier
olcDatabase{2}bdb.ldif, pour faire cela, Il faut ajouter la configuration suivante au fichier.
olcTLSCertificateFile: /etc/openldap/newcerts/ldap.pem
olcTLSCertificateKeyFile: /etc/openldap/newcerts/ldapkey.pem
3.5.2.3 Configuration de système de l’authentification
Commençons par la configuration de la méthode d’authentification de client pour
qu’il utilise l’authentification LDAP, à l’aide de la commande suivante:
# authconfig-gtk
  Vous remarquez que la fenêtre de configuration vous signale qu’il faut utiliser l’URL
de serveur ldaps:// ou authentification sécuriser par TLS.
 Pour le moment, on va spécifier ldaps:// dans la partie Serveur LDAP.

Vous remarquez que le daemon sssd va démarrer pour prendre les nouvelles
configurations après que vous cliquiez sur « Appliquer »:
Starting sssd: [ OK ]
Attention ! N’oublier pas, qu’il faut activer le port 636 (LDAPS://) sur le serveur
LDAP, à partir de fichier /etc/sysconfig/ldap :
serveur# vim /etc/sysconfig/ldap
...
SLAPD_LDAPS=yes
...
Vérifier les ports ouverts de LDAP:
# netstat -tunlp | grep slapd
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 64175/slapd
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 64175/slapd
tcp 0 0 :::389 :::* LISTEN 64175/slapd
tcp 0 0 :::636 :::* LISTEN 64175/slapd
Notez qu’à chaque modification des attributs de l’utilisateur LDAP, vous devez vider
la cache sssd de la machine cliente pour recevoir les nouvelles valeurs.
# service sssd stop
# rm -f /var/lib/sss/db/*
# service sssd start
Vérifier maintenant l’existence de l’utilisateur ld-user01 depuis la machine cliente avec :
# getent passwd ld-user01
 On trouve que la commande ne donne aucune information sur cet utilisateur.
 Après l’utilisation de Wireshark pour vérifier les requêtes envoyés depuis le client
LDAP, on constate que durant la session TLS le serveur réinitialise la connexion TCP
 directement après que le client envois un Hello TLS. Dans notre cas, c’est normal
puisque on n’a pas implémenté dans notre configuration les fichiers de certificat TLS.

Pour travailler sans TLS, on va demander au service SSSD de client LDAP, de passer l’étape de
vérification de certificat TLS envoyé par le serveur, même si ces certificats sont faux ou
manquante. Pour faire cela on va ajouter l’option « ldap_tls_reqcert » dans le fichier de
configuration /etc/sssd/sssd.conf et dans la section [domain/default].
# vim /etc/sssd/sssd.conf
[domain/default]

autofs_provider = ldap
cache_credentials = True
ldap_search_base = dc=ismontic,dc=ma
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldapserver.ismontic.ma
ldap_id_use_start_tls = False
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_reqcert = allow

[sssd]
services = nss, pam, autofs
domains = default

[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]
[ifp]
Les valeurs possibles pour l’option « ldap_tls_reqcert » sont :
 never: Le client ne demandera ni ne vérifiera aucun certificat de serveur.
 allow : Le certificat de serveur est demandé. Si aucun certificat n'est fourni, la
session se déroule normalement. Si un mauvais certificat est fourni, il sera ignoré
et la session se déroulera normalement.
 try : Le certificat de serveur est demandé. Si aucun certificat n'est fourni, la session
se déroule normalement. Si un mauvais certificat est fourni, la session est
immédiatement terminée.
 demand | hard : Ces mots clés sont équivalents. Le certificat de serveur est
demandé. Si aucun certificat n'est fourni ou si un mauvais certificat est fourni, la
session est immédiatement terminée. Ce sont les paramètres par défauts.
# getent passwd ld-user01
ld-user01:*:999:999:ld-user01:/home/guests/ld-user01:/bin/bash
3.5.2.4 Accès au dossier personnel de l’utilisateur
Dans cette étape, malgré qu’on soit capable de s’authentifier avec l’utilisateur
ld-user01, nous recevons une erreur disant que le système ne trouve pas le dossier
personnel de cet utilisateur.
$ su - ld-user01
Mot de passe :
su: avertissement : impossible d'aller dans le répertoire /home/guests/ld-user01: Aucun
fichier ou dossier de ce type
-bash-4.1$
Pour surmonter ce problème, on va partager un dossier depuis le serveur via NFS, et
qui va être l’emplacement des dossiers personnel de tous les utilisateurs LDAP.
3.5.2.5 Partage NFS
Depuis le serveur LDAP, suivre les étapes présentées ci-dessous :
serveur# vim /etc/exports
/home/guests/ @IP/Préfix(rw,sync,no_root_squash)
serveur# service nfs restart
serveur# showmount -e nom_serveur.nom_domaine.tld
3.5.2.6 Point de montage NFS
Rappelons, que le montage manuel ou par « fstab » à plusieurs inconvénients:
 Le principal, c'est qu'il n'est pas toujours possible de rendre le montage automatique.
Il est censé l'être si vous ne spécifiez pas "noauto" dans les options de montage dans
/etc/fstab. Cependant, si lors du montage vous n'êtes pas encore connecté (en wifi
par exemple), alors il ne se fait pas, et il faut l'effectuer manuellement (de même que
le démontage).
 Un autre inconvénient, moins important, est que les dossiers restent montés et
consomment des ressources même si vous ne les utilisez pas.
Si vous éteignez l'ordinateur qui partage ses données, les autres ordinateurs auront
des difficultés à gérer la situation (Par exemple, le « shutdown » qui bloque à cause
d'un ancien montage NFS).
 D'autre part les montages réalisés à partir de nautilus (ou files) ne sont pas visibles
dans les autres applications comme Firefox, shotwell, ….
La solution, c’est AutoFS permet de résoudre ces problèmes.
  AutoFS contrôle les opérations des démons d'automount.
 Les démons d'automount montent automatiquement des systèmes de fichiers quand
ils sont employés et les démontent après une période d'inactivité. Ceci est fait en se
basant sur un ensemble de cartographies (maps) préconfigurées.
Les fichiers de configuration autofs sont organisés selon une relation parent-enfant. Le
fichier de configuration principal (/etc/auto.master) énumère des points de montage sur le
système qui sont liés à un type de correspondance (map type) particulier.
Ajouter la ligne suivant au fichier /etc/auto.master
#
# Sample auto.master file
# This is a 'master' automounter map and it has the following format:
# mount-point [map-type[,format]:]map [options]
# For details of the format look at auto.master(5).
#
/misc /etc/auto.misc
/home/guests/ /etc/auto.guests --timeout 60
.......
 --timetout n, qui indique au bout de combien de temps d'inactivité (Secondes) le
système de fichiers sera démonter.
Ensuite vous allez créer un fichier /etc/auto.guests, et qui va contenir la ligne suivant :
* -rw ldapserver.ismontic.ma:/home/guests/&
 La ligne est de format suivant :
</local/directory> -<options> <server>:</remote/export>
 Cette ligne stipule que tout répertoire auquel un utilisateur tente d'accéder dans
le répertoire /home/guests/ local (En raison de *), devrait entraîner un montage
NFS sur le système « ldapserver.ismontic.ma» au point de montage
/home/guests/.
 Le caractère * se substitue au nom d'utilisateur qui sert aussi à désigner son
répertoire à partir de la racine exportée par le système de fichier réseau NFS : le
caractère &.
o Autres exemples de contenu de fichier de mappage :
ld-user01 ldapserver.ismontic.ma:/home/guests/ld-user01
ld-user01 ldapserver.ismontic.ma:/home/guests/ld-user02
* ldapserver.ismontic.ma:/home/guests/&
Actualiser les Maps de daemon Asutofs:
# service autofs reload
Vérifier avec:
client# showmount -e ldapserver.ismontic.ma
client# mount
Reste une dernière option d’authentification à configurer, qui a pour rôle de créer le
répertoire personnel de l’utilisateur lors de son première connexion.
 Depuis la machine cliente, entrer la commande suivant : client# authconfig-gtk

Ouvrir un nouveau terminal sur la machine cliente :

client$ su - ld-user01
Mot de passe :
Creating home directory for ld-user01.
[ld-user01@client ~]$ pwd
/home/guests/ld-user01
[ld-user01@client ~]$ cd
[ld-user01@client ~]$ ls -ld
drwx------. 4 nobody nobody 4096 Mar 3 22:25
3.5.2.7 Problématique NFS
Par défaut, les partages NFS changent l'utilisateur root en utilisateur nobody, un
compte d'utilisateur sans privilège. Cela change le propriétaire de tous les fichiers créés par
la racine en nobody, ce qui empêche le téléchargement de programmes avec le bit setuid
défini.
Avec cette configuration standard, les ordinateurs clients NFS ne sont pas approuvés
pour un accès root sur le serveur NFS. L’accès par uid=0 est mappé sur un utilisateur sans
privilège (nobody). Pour créer le répertoire personnel, pam_mkdir (qui s'exécute en tant
que root) doit disposer d'autorisations sur le répertoire dans lequel le répertoire personnel
de l'utilisateur sera créé (généralement dans /home/guests/), et lorsqu'il est re-mappé sur
nobody, cela échoue.
Une solution à éviter, qui permet la création de dossier personnel des utilisateurs
authentifié par le serveur LDAP, par l’utilisation de l’option nfs « no_root_squash ». Cette
solution a comme conséquence de donner aux utilisateurs root distants « de machine
cliente » le droit de modification de n’importe quel fichier du système de fichiers partagé.
Cela va laisser les applications infectées par des chevaux de Troie pour que les autres
utilisateurs puissent s’exécuter par inattention.
 Au final, la meilleure approche consiste à avoir un script qui parcourt votre annuaire
LDAP et crée directement les répertoires de base manquants sur le serveur NFS.
3.5.2.8 Authentification avec vérification de certificat TLS
Maintenant, on est sûr que l’étape d’authentification et l’accès au dossier personnel
de l’utilisateur s’est bien déroulé, sachant qu’on a utilisé la méthode sans vérification de
certificat.
Par la suite, on va transférer le certificat TLS (Clé publique + Information d’identité +
signature de serveur) vers la machine cliente pour qu’il puisse vérifier avec serveur durant la
session TLS. Il existe plusieurs méthodes pour transférer ce certificat:
 Copier directement ou avec « scp » le fichier ldap.pem vers le dossier
/etc/openldap/cacerts/.
 Ou on va utiliser le serveur « Apache » pour permet aux clients de
télécharger le certificat:
serveur# cp ldap.pem /var/ftp/pub/
serveur# ln -s /var/ftp/pub /var/www/html/
serveur# service vsftpd start
serveur# service httpd start
 On suppose que le serveur ftp est en accès anonyme.
 On suppose que le serveur http est non configurer en « Virtual Hosting ».
Ensuite, on va configurer le système d’authentification de client pour qu’il télécharge
le certificat TLS:
# authconfig-gtk

Et pour finir, changer la valeur de l’option « ldap_tls_reqcert » en « demand ». Puis vérifier

la connexion de l’utilisateur.
3.6 Informations supplémentaires
 3.6.1 Migration Tools
Les outils de migration LDAP constituent un ensemble de scripts Perl fournis par
PADL Software Ltd. Ils permettent de convertir les fichiers de configuration au format LDIF. Si
vous envisagez d'utiliser votre serveur LDAP pour authentifier les utilisateurs, ces outils
peuvent s'avérer très utiles. Utilisez les outils de migration pour :
 convertir vos archives NIS ou vos mots de passe au format LDIF, rendant ainsi ces
fichiers compatibles avec votre serveur LDAP.
 Appliquez également ces scripts Perl pour migrer des utilisateurs, groupes, alias,
hôtes, groupes réseau, réseaux, protocoles, RPC et services à partir de services de
noms existants au format LDIF.

3.6.2 Configuration de l’outil

Installez le package ci-dessous pour prendre en charge la migration des utilisateurs
locaux vers LDAP.
# rpm -ihv migrationtools-47-7.el6.noarch.rpm
Pour tester la migration, nous aurions besoin de comptes locaux disponibles sur la machine.
Créons des utilisateurs locaux à l'aide de la commande suivante.
# useradd ldpuser1
# useradd ldpuser2
# useradd ldpuser3
Définir le mot de passe pour les utilisateurs créés.
# echo "pass" | passwd --stdin ldpuser1
# echo "pass" | passwd --stdin ldpuser2
# echo "pass" | passwd --stdin ldpuser3
Exportez les utilisateurs et les groupes créés dans le fichier.
# grep "^ldpuser" /etc/passwd > /root/users
# grep "^ldpuser" /etc/group > /root/groups
# cat /root/users
# cat /root/groups
 Vous pouvez exporter plusieurs utilisateurs ou groupes avec la même méthode.
Éditez « /usr/share/migrationtools/migrate_common.ph » et mettez-le à jour avec :
$ DEFAULT_MAIL_DOMAIN = "ismontic.ma";
$ DEFAULT_BASE = "dc=ismontic,dc=ma";
# Changez-le en 1 pour prendre en charge des classes d'objets plus générales telles que
# person.
$ EXTENDED_SCHEMA = 1;
Convertissez maintenant le fichier des utilisateurs et des groupes au format LDIF.
# cd /usr/share/migrationtools/
# ./migrate_passwd.pl /root/users /root/users.ldif
# ./migrate_group.pl /root/groups /root/groups.ldif
 Si vous listez le contenu de fichier ldif vous remarquer que le dn de chaque objets
sera :
o Pour les utilisateurs sera dn: uid=ldpuserX,ou=People,dc=ismontic,dc=ma
o Pour les groupes sera dn: cn=ldpuserX,ou=Group,dc=ismontic,dc=ma
 Si l’objet organisation (o) et les unités d’organisation (OU) de premier niveau ne sont
pas encore créer, MigrateTools vous offre le scripte migrate_base.pl qui va vous permet de
créer un fichier LDIF qui va contenir toutes les déclarations de l’arborescence LDAP.
# ./migrate_base.pl | grep “^dn:”
dn: dc=ismontic,dc=ma
dn: ou=Hosts,dc=ismontic,dc=ma
dn: ou=Rpc,dc=ismontic,dc=ma
dn: ou=Services,dc=ismontic,dc=ma
dn: nisMapName=netgroup.byuser,dc=ismontic,dc=ma
dn: ou=Mounts,dc=ismontic,dc=ma
dn: ou=Networks,dc=ismontic,dc=ma
dn: ou=People,dc=ismontic,dc=ma
dn: ou=Group,dc=ismontic,dc=ma
dn: ou=Netgroup,dc=ismontic,dc=ma
dn: ou=Protocols,dc=ismontic,dc=ma
dn: ou=Aliases,dc=ismontic,dc=ma
dn: nisMapName=netgroup.byhost,dc=ismontic,dc=ma
# ./migrate_base.pl > /root/base.ldif
Il vous reste qu’importer les fichiers LDIF vers la base de données LDAP, avec la commande
ldapadd.

3.6.1 Debug {sssd, autofs}

3.6.2 Configuration de serveur via ldapmodify.