Tag Archives: Données OpenLDAP

OpenLDAP – Ajouter des données à l'annuaire

Objectif: Dans ce 6eme article de la série « OpenLDAP Tutorial », nous allons alimenter l’annuaire avec des données utiles. Ceci permettra d’utiliser réellement le serveur OpenLDAP. Un prochain article détaillera un exemple concret d’utilisation de cet annuaire. Il sera présenté pas à pas la manière de restreindre l’accès à un site web (Internet ou Intranet) à des utilisateurs authentifiés. Pré-requis:

1. Création d’un nœud pour les personnes.

Un annuaire se doit d’être organisé. Dans un soucis d’organisation, on va d’abord créer un nœud (conteneur) qui recevra les entrées annuaire des personnes. Créer un fichier LDIF pour ce nœud: 
vi people.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: ou=People,dc=ldaptuto,dc=net
objectClass: organizationalUnit
ou: People
  • People est un nom au choix.
  • Le type de cette nouvelle entrée est organizationalUnit (OU), c’est le type usuel des nœuds conteneurs dans OpenLDAP.
  • OpenLDAP n’est pas sensible à la casse et ne fait pas de différence entre majuscules et minuscules, people ou People sont équivalents.
On ajoute cette entrée à l’annuaire: 
ldapmodify -a -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f people.ldif
-a (pour add) après ldapmodify veut dire qu’on souhaite ajouter le contenu du fichier.

2. Ajouter des personnes à l’annuaire

vi dupond.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: uid=dupond,ou=People,dc=ldaptuto,dc=net
objectClass: inetOrgPerson
givenName: Jean
sn: Dupond
cn: Jean Dupond
uid: dupond
userPassword: dupond
On ajoute cette entrée à l’annuaire: 
ldapmodify -a -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f dupond.ldif
Et on vérifie cet ajout: 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -b ou=People,dc=ldaptuto,dc=net
Remarquer que le mot de passe a été crypté et même l’administrateur ne peut plus le voir en claire.

3. Utilisation

Regardons maintenant ce qui se passe si Jean Dupond essaye de se connecter à l’annuaire et voir les personnes référencées (entre autres lui même). 
ldapsearch -x -H ldap://localhost -D uid=dupond,ou=people,dc=ldaptuto,dc=net -w dupond -b ou=people,dc=ldaptuto,dc=net -LLL
ldap_bind: Invalid credentials (49)
Rappel:
  • -D : dn de l’utilisateur qui s’authentifie, la requête utilise les droits de lecture de cet utilisateur.
  • -w : Mot de passe de cet utilisateur.
Le résultat est un message d’erreur qui veut dire que l’authentification est non valide. Pourtant les données envoyées sont correctes (dn et mot de passe). La cause est un droit d’accès insuffisant pour l’authentification. On ne va pas aborder ici ce thème sensible et complexe des droits d’accès. On va juste ajouter une configuration qui permettra aux utilisateurs de l’annuaire de s’authentifier. 
vi acces.ldif
Saisir dans l’éditeur, puis enregistrer: 
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcAccess
olcAccess: to * by users read by anonymous auth by * none
Cette commande ajoute une autorisation d’authentification (by anonymous auth) et de lecture à toutes les personnes de l’annuaire. Bien entendu il n’est pas conseillé d’utiliser une telle configuration dans la réalité. Elle n’est utilisée ici que pour des raisons de simplification de la démonstration. On lance cette commande de configuration de l’annuaire: 
ldapmodify -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -w admin -f acces.ldif
Maintenant une requête de lecture des données des personnes de l’annuaire par Jean Dupond (la même que la précédente) permet de les afficher. 
ldapsearch -x -H ldap://localhost -D uid=dupond,ou=people,dc=ldaptuto,dc=net -w dupond -b ou=people,dc=ldaptuto,dc=net -LLL
dn: ou=People,dc=ldaptuto,dc=net
objectClass: organizationalUnit
ou: People

dn: uid=dupond,ou=People,dc=ldaptuto,dc=net
objectClass: inetOrgPerson
givenName: Jean
sn: Dupond
cn: Jean Dupond
uid: dupond
userPassword:: e1NTSEF9Umk1d0QrWEtmNHRrSHBOelBEMkdqU3NNSUhtRmtNU28=
Finalement l’annuaire servi par OpenLDAP permet à Jean Dupond, qui y est référencé, de s’authentifier et de lire toutes les données qu’il contient. A tire d’exercice vous pouvez ajouter une autre personne à l’annuaire: Alain Durand. Après cela le contenu de cet annuaire aura cette structure: 
dc=ldaptuto,dc=net
├── cn=admin,dc=ldaptuto,dc=net
└── ou=People,dc=ldaptuto,dc=net
    ├── uid=dupond,ou=People,dc=ldaptuto,dc=net
    └── uid=durand,ou=People,dc=ldaptuto,dc=net
 ]]>

OpenLDAP – organisation et types de données

Objectif: Dans ce 5eme article de la série OpenLDAP tutorial, nous allons voir comment ce serveur d’annuaire organise son contenu. Ceci constitue un préalable nécessaire pour pouvoir l’alimenter de données. Une fois cette alimentation faite, le serveur sera prêt pour être utilisé. Les principales utilisations sont: l’authentification d’utilisateurs auprès de systèmes informatiques et la synchronisation de données auprès de ces systèmes (serveurs de messagerie par exemple). L’intérêt de l’utilisation des serveurs LDAP pour ces fonctions est que ce protocole est devenu un standard de fait. Il est supporté par la majorité des systèmes et applications informatiques qui ont ce besoin. Un article à venir traitera l’alimentation effective en données. Pré-requis:

1. L’organisation des données dans un serveur OpenLDAP

Dans un serveur OpenLDAP, les données sont organisées en arbre . Il y a la racine de l’arbre: le DIT (Directory information tree), le tronc de celle-ci. En avançant après le tronc, on rencontre:
  • Des nœuds: données de type spécial qui ont la capacité de contenir d’autres données.
  • Des feuilles: les données proprement dites et qui peuvent être de différents types.
On peut assimiler, par analogie, cette organisation à celle d’un système de fichier sur un disque d’ordinateur. Voici la représentation qu’on obtiendrait du dossier /etc/resolvconf par la commande: 
sudo tree /etc/resolvconf
– OpenLDAP tutorialEn bleu, les noeuds ou dossiers dans un système de fichier. – En bleu claire et en vert les données proprement dites ou fichiers dans un système de fichier. Pour désigner de manière non ambiguë le fichier dnscache par exemple, on utilise le chemin complet (full qualified name – FQN): /etc/resolvconf/update.d/dnscache. Cela est nécessaire du fait qu’il peut y avoir un autre fichier, qui porte le même nom, quelque part ailleurs sur le disque.   Pour un annuaire LDAP l’équivalent du FQN est le DN (distinguished name) et il constitue le chemin complet depuis la racine (c’est à dire le DIT).

2. Les types de données dans un serveur OpenLDAP

Il existe un très grand nombre de types de données utilisables par le serveur OpenLDAP. De plus ces types de données sont extensibles et évoluent constamment. Dans la pratique il convient de choisir un ensemble restreint de ces types de données en fonction des besoins réels. Cela revient à déclarer dans la configuration du serveur les schémas à embarquer. Un schéma est une description de types de données (métadonnées). Cette commande donne la liste des schémas embarqués par le serveur: 
ldapsearch -x -H ldap://localhost -s one -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b cn=schema,cn=config cn -LLL
dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson
Le résultat est celui obtenu juste après l’installation d’un serveur OpenLDAP. Ce sont les quatre schémas embarqués par défaut. Ils suffisent pour la plupart des utilisations de base d’un annuaire LDAP.

3. Le contenu par défaut du serveur OpenLDAP

Pour obtenir le contenu entier et réel d’un annuaire OpenLDAP, il faut lancer une requête de recherche en mode connecté avec le compte de l’administrateur du serveur (rootdn). C’est le seul compte qui n’est jamais soumis à aucune restriction d’accès. 
ldapsearch -x -H ldap://localhost -D cn=admin,dc=ldaptuto,dc=net -y pwdAdmin -b dc=ldaptuto,dc=net -LLL
dn: dc=ldaptuto,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: OpenLDAP tutorial
dc: ldaptuto

dn: cn=admin,dc=ldaptuto,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9RzlwcjRUdkRJajlWOWpqYjFzMTJkczhaaDBrY2pzOXA=
Le résultat est celui obtenu juste après l’installation d’un serveur OpenLDAP. On reconnaît les valeurs saisies au cours de l’installation (ou la reconfiguration).
  • cn=admin: l’identifiant de l’administrateur du serveur.
  • o=OpenLDAP tutorial: Le nom de l’oganisation.
  • dc=ldaptuto,dc=net: le DIT (nom de domiaine).
  • userPassword: le mot de passe de l’administrateur (crypté).
En tout, il n’y a que deux entrées dans l’arbre de l’annuaire: dc=ldaptuto,dc=net └── cn=admin,dc=ldaptuto,dc=net Ce sont les valeurs de l’attribut objectClass qui déterminent la nature (ou le type) de l’entrée.
  • dc=ldaptuto,dc=net: de type dcObject, c’est le type spécial qui détermine la racine ou le DIT de l’annuaire. Cette entrée est le conteneur de toutes les données de cet annuaire.
  • cn=admin,dc=ldaptuto,dc=net: de type simpleSecurityObject, donnée finale qui représente un compte d’authentification. Contient principalement le mot de passe de ce compte.
]]>