Ne confondez pas entre le baseDN et le bindDN.
-
Le baseDN d'une recherche est le point de départ. Où la recherche va commencer. Assez explicite.
-
Le bindDN DN est essentiellement l'identifiant que vous utilisez pour vous authentifier contre un LDAP.
Lorsque vous utilisez un bindDN, il est habituellement associé à un mot de passe.
En d'autres termes, lorsque vous spécifiez un bindDN, vous utilisez cet objet d'accès à la sécurité pour parcourir l'arborescence LDAP.
Maintenant, la chaîne dc=exemple,dc=com n'est pas le meilleur exemple pour un bindDN car c'est un "domaine" pour une arborescence LDAP. dc signifie domain component et chaque arborescence LDAP définit sa racine avec une chaîne sous la forme dc=chaîne,dc=chaîne,... Mais ces chaînes NE sont PAS un "chemin" comme le reste de l'arborescence.
Des exemples valides sont:
dc=exemple,dc=comdc=mondomainedc=une,dc=longue,dc=liste,dc=de,dc=domaines
Mais, ces éléments racines sont indivisibles. Bien qu'ils semblent être plusieurs éléments représentant un chemin comme le reste de l'arborescence, mais ils ne le sont pas. (Ainsi pour ces éléments la virgule "," n'est PAS un séparateur d'éléments.)
Ainsi, pour l'exemple dc=une,dc=longue,dc=liste,dc=de,dc=domaines cela signifie que ceci est le nom de l'élément entier. Ce n'est PAS un chemin d'éléments. Il ne peut PAS être décomposé en sous-éléments : IL N'Y A PAS d'objet dc=de,dc=domaines.
Pour faire une analogie avec les chemins de fichiers :
Imaginez nommer votre disque C: comme D:\mon\dossier\. Chaque chemin là-dedans ressemblera à quelque chose comme D:\mon\dossier\mon\vrai\chemin ce qui serait confus car le vrai chemin du fichier serait \mon\vrai\chemin non? Eh bien, c'est ainsi que ressemble la base (racine) d'un LDAP, avec un ensemble d'éléments dc=.
Lien pertinent: Documentation Oracle : "L'outil ldapsearch" http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html
Lecture complémentaire
Il n'y a aucune norme qui impose une structure particulière pour les DIT LDAP, donc les serveurs de répertoire peuvent contenir des entrées dans n'importe quel arrangement hiérarchique. Cependant, il existe quelques conventions courantes. [...]
Par exemple, si l'organisation a un domaine de exemple.com, alors le contexte de nommage serait probablement quelque chose comme dc=exemple,dc=com. Il est parfaitement légal pour un contexte de nommage d'avoir plusieurs composants, donc juste parce que le serveur a une entrée avec un DN de dc=exemple,dc=com ne signifie pas nécessairement qu'il doit y avoir une entrée avec un DN de dc=com.
