Dans LDAP, qu'est-ce exactement qu'un DN de liaison?

J'ai écrit différents morceaux de code qui se connectent aux serveurs LDAP et exécutent des requêtes, mais cela a toujours été un vaudou pour moi. Une chose que je ne comprends pas vraiment, c'est le concept d'un DN de liaison. Voici un exemple utilisant l' ldapsearchoutil de ligne de commande disponible depuis openldap. (Ignorez le manque d'authentification.)

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

Quel est le but et la fonction de cette -D dc=example,dc=compartie? Pourquoi devons-nous nous lier à un emplacement particulier dans la hiérarchie des répertoires? Est-ce pour déterminer à quelle partie du répertoire mes requêtes doivent s'appliquer? Par exemple, si le nœud racine du répertoire est dc=com, et qu'il a deux enfants ( dc=fooet dc=bar), peut-être que je veux que mes requêtes soient contre le dc=foo,dc=comsous - arbre et non contre le sous- dc=bar,dc=comarbre?

Un DN de liaison est un objet auquel vous vous liez dans LDAP pour vous donner les autorisations de faire tout ce que vous essayez de faire. Certaines (beaucoup?) Instances LDAP n'autorisent pas les liaisons anonymes, ou ne permettent pas que certaines opérations soient effectuées avec des liaisons anonymes, vous devez donc spécifier un bindDN pour obtenir une identité pour effectuer cette opération.

De la même manière non technique - et oui, c'est un tronçon - une banque vous permettra d'entrer et de regarder leurs taux d'intérêt sans leur donner aucune sorte d'identité, mais pour ouvrir un compte ou retirer de l'argent, vous avez d'avoir une identité qu'ils connaissent - cette identité est le bindDN.

Ne vous trompez pas entre le baseDN et le bindDN .

Le baseDN d'une recherche est le point de départ. Où il commencera à chercher. Assez explicite.

Le bindDN DN est essentiellement les informations d' identification que vous utilisez pour authentifier contre un LDAP. Lorsque vous utilisez un bindDN, il est généralement accompagné d'un mot de passe associé.

En d'autres termes, lorsque vous spécifiez un bindDN, vous utilisez cet accès de sécurité d'objet 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 composant de domaine 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 = com
• dc = mon domaine
• dc = avery, dc = long, dc = list, dc = of, dc = domaines

Mais, ces éléments racines sont indivisibles. Ils semblent être plusieurs éléments représentant un chemin comme le reste de l'arbre, mais ils ne le sont pas . Par exemple, dans le dernier exemple, un objet dc = of, dc = domaines n'existe pas.

Imaginez nommer votre lecteur C: comme "D: \ mon \ dossier \". Chaque chemin là-dedans ressemblera à quelque chose comme "D: \ mon \ dossier \ mon \ vrai \ chemin" qui serait déroutant car le vrai chemin du fichier serait \ mon \ vrai \ chemin n'est-ce pas? Eh bien, c'est à cela que ressemble la base (racine) d'un LDAP, avec un ensemble d'éléments dc =.

Lien pertinent: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html