A propos de LDAP
Un peu d’étymologie
Nous allons d’abord disséquer cet acronyme, Lightweight Directory Access Protocol.
D’abord Lightweight : pour toute personne qui a déjà pratiqué un peu la chose, la légèreté, qui rime avec simplicité, n’est vraiment pas la première chose qui viendrait à l’esprit quand on parle de LDAP. Ca semblerait même presque incongru. Pourtant, aussi incroyable que ça puisse paraître, la norme LDAP est une simplification de la norme X500, … que personne n’arrivait à implémenter ! Le vocabulaire entourant la LDAP est assez fleuri, dénotant la puissance des substances psychotropes disponibles au début des années 90 sur la côte est des Etats Unis.
Ensuite Directory : un serveur LDAP n’est pas un serveur de base de données comme les autres. Contrairement à un serveur SQL, où la structure est donnée par des schémas de base de données, de tables, de contraintes et de relations entre les tables, la base LDAP prend une approche complètement différente en se basant une structure hiérarchique. Une base LDAP s’apparente un peu à un partage de fichiers. Il y a une racine (le partage), des répertoires et des fichiers, le tout prenant une forme arborescente. Les bases de données arborescentes sont revenues à la mode avec la tendance NoSQL (par ex. MongoDB). On reviendra sur tout ça un peu après.
Et enfin Access Protocol : la norme LDAP ne définit pas une implémentation, mais un protocole de communication. Vous pouvez implémenter votre LDAP comme vous le voulez, en C, en Python, en Perl ou en OCaml, avec une base de stockage BDB, LMDB, TDB, EDB, etc, tant que le serveur parle le protocole LDAP, ce sera un annuaire LDAP !
Structure LDAP
Dans l’introduction nous avons souligné qu’un LDAP n’a pas de structure similaire à celle d’une base SQL. Pour éviter que ça devienne le souk, il a quand même fallu définir quelques règles de base. Au fait, ça ressemble à quoi ?
Ici la racine de l’arbre est DC=test,DC=lan. Pourquoi c’est comme ça ? Parce que serait la meilleure réponse. Il y a plein d’options possibles pour nommer la racine de l’arbre (par exemple O=tranquilit, le paramètre O voulant dire ici organisation). Toutefois, vu que la plupart des LDAP déployés dans le monde sont des Active Directory, le choix de Microsoft a fini par s’imposer. Microsoft a choisi d’utiliser le schéma suivant : si votre domaine est test.lan, la racine LDAP sera DC=test,DC=lan, si le domaine est ad.tranquil.it, la racine sera DC=ad,DC=tranquil,DC=it. C’est une norme de fait, il n’y a pas grand-chose à comprendre en plus.
Chaque élément peut être nommé d’une manière absolue en donnant tout le chemin pour y accéder depuis la racine. Ca s’appelle le DN ou Nom distingué. Dans l’exemple ci-dessus, mon compte se trouve dans le répertoire ou=Nantes, mon DN sera alors CN=dcardon,OU=nantes,DC=test,DC=lan. On retrouve le nom DN quand on configure des applications pour s’authentifier sur le LDAP, et assez souvent on parlera de Bind DN. En LDAP, on ne se connecte pas, on fait un bind (ça serait trop simple sinon). On vous avait prévenu que le vocabulaire était fleuri !
Et c’est quoi une OU ? OU veut dire Organizational Unit (Unité d’Organisation). Dans le LDAP, ça correspond à un répertoire qui va permettre de trier les différents objets que l’on va stocker. On peut avoir des OU pour trier géographiquement (OU=nantes,``OU=paris``, etc.), des OU pour trier par service (OU=compta, OU=informatique, etc.), ou tout autre type de classification qui peut aider les administrateurs système et réseau à s’y retrouver.
Pourquoi l’entrée dcardon est nommé CN=dcardon. Encore ici, c’est un choix de Microsoft, ça aurait pu être UID=dcardon, mais Microsoft a choisi l’attribut CN.
CN, OU, DN, c’est quoi ces choses là ? Ce sont des attributs ! Comme on l’a dit plus haut, il n’y a pas de schéma SQL comme dans les bases de données habituelles pour structurer l’arbre LDAP. Donc pour garder les choses dans un état décent, chaque objet LDAP doit respecter une structure définie par des schémas LDAP :
Un schéma contient des ObjectClass.
Une ObjectClass contient un ou plusieurs attributs. Une ObjectClass peut être Structurelle ou Auxiliaire, mais c’est pas très important ici, sauf si vous voulez étendre votre Schéma (voir plus bas à ce sujet).
Un attribut (CN, givenName, sAMAccountName,etc.) définit une valeur que l’on peut donner à un object LDAP. Un attribut a un type, un type de recherche, et éventuellement des indexes.
L’Active Directory vient avec un nombre assez conséquent de schémas LDAP. Quand on vient de l’univers OpenLDAP, on a l’habitude d’intégrer des nouveaux schémas (par exemple pour stocker des données DHCP, DNS, etc). En pratique on trouve presque toujours des ObjectClass et des attributs qui conviennent dans les schémas existant et il n’est pas nécessaire d’étendre les schémas LDAP dans Active Directory.
Encore un peu de vocabulaire. La partie la plus à gauche du DN CN=dcardon,OU=Nantes,DC=test,dc=lan, qui est ici CN=dcardon s’appelle le RDN.
Les 5 partitions racines dans Active Directory
Dans ce chapitre, on avait dit qu’une base LDAP avait une seule racine, dans notre exemple : DN=test,DC=lan. Toutefois dans l’environnement Active Directory, pour des questions d’optimisation de la réplication, il n’y a pas qu’une seule racine, mais cinq !
Chacune de ces racines s’appelle une partition (dialecte AD), ou un NC en dialecte LDAP.
Comme on le voit ici, la même chose peut avoir deux noms différents en fonction du contexte, en fonction du fait que l’on parle d’un domaine AD ou bien d’un LDAP.
Les cinq partitions / Naming Context sont les suivants :
DC=test,DC=lan ;
CN=Configuration,DC=test,DC=lan ;
CN=Schema,CN=Configuration,DC=test,DC=lan ;
DC=DomainDnsZones,DC=test,DC=lan ;
DC=ForestDNSZones,DC=test,DC=lan ;
D’un point de vue extérieur, les partitions sont toutes situées en dessous de la racine DC=test,DC=lan, mais dans l’implémentation, dans la partie réplication, et quand on se connecte avec un client LDAP, on voit bien ces cinq partitions individuellement.
Le port par défaut LDAP est le port 389 / tcp. Attention : un Active Directory ouvre aussi le port 389 / udp pour le protocole CLDAP. Le protocole CLDAP est utilisé lors du démarrage d’un poste pour trouver sur quel site (au sens AD) il se trouve. Le protocole CLDAP partage avec LDAP le nom, le port, le format de la première connexion, mais c’est à peut près tout. Les ingénieurs Microsoft avait besoin d’un port pour le CLDAP, ils ont pris le 389 / udp.
Pour visualiser le contenu de la LDAP, le mieux est d’utiliser Apache Directory Studio, c’est le meilleur outil généraliste LDAP sur le marché. Pour ouvrir une connexion sur un AD, vous pouvez utiliser ApacheDirectoryStudio.
STARTTLS vs LDAPS : l’extension STARTTLS permet de négocier une connexion SSL / TLS sur le même port que le port non chiffré d’un protocole standard. Donc une connexion LDAP avec STARTTLS se passe sur le même port 389 / TCP. Le port LDAPS 636 / TCP fournit une connexion sécurisé SSL / TLS par défaut. Contrairement à un AD Microsoft, Samba-AD active STARTTLS et LDAPS par défaut. Pour cela un certificat auto-signé est généré à la création du domaine. Il est bien évidemment recommandé de remplacer ces certificats auto-signés par des certificats reconnus par les clients du domaine. Toutefois il est important de noter qu’il n’est pas nécessaire d’avoir un certificat SSL pour avoir un réseau AD fonctionnel : en effet les informations d’authentification entre les postes et l’AD sont chiffrés (Kerberos ou NTLM) par défaut.
Port |
Usage |
|---|---|
389 |
TCP et UDP |
636 |
LDAPS |
3268 |
Global Catalog |
3269 |
Global Catalog SSL |