Puis-je obtenir une explication de la syntaxe des suffixes de base de recherche LDAP?

Je sais qu'un suffixe de base de recherche LDAP correspond généralement au nom d'hôte du serveur d'annuaire. En d'autres termes, je sais que si le nom d'hôte est od.foobar.com, je dois utiliser le suffixe de base de recherche:dc=od,dc=foorbar,dc=com

Cela me dérange de ne pas comprendre pourquoi je fais ça. Quelqu'un pourrait-il fournir des informations générales et expliquer précisément ce que je fais?

Avant que Microsoft n'embrasse, étende et modifie LDAP, la plupart des implémentations avaient des objets pour représenter la racine de l'arborescence. C'est à dire que vous devez commencer quelque part.

Pour des raisons que je ne comprends pas bien, dans Active Directory, chaque domaine de l'arborescence / forêt est enraciné avec un nom qui dc = domaine, dc = com qui n'est pas vraiment deux objets distincts, mais plutôt une racine virtuelle du répertoire espace de nom.

Je pense que cela vient en partie du fait que, indépendamment de ce qui est dit sur Active Directory, il s'agit toujours d'une série de domaines liés, et chaque domaine doit être traité comme une entité autonome.

Maintenant, il existe des approbations transitives automatiques dans une arborescence AD, ce qui rend les choses moins importantes pour les utilisateurs finaux, mais même si l'espace de noms semble un peu contigu, ce n'est pas vraiment le cas.

Cela devient plus évident avec certaines des règles de dénomination avec AD. Par exemple, sAMAccountName doit être unique au sein d'un domaine, qu'il se trouve ou non dans le même conteneur. C'est-à-dire que le nom distinctif complet doit être unique (vous ne pouvez pas avoir deux utilisateurs John Smith dans le même conteneur), mais le nom abrégé utilisé pour de nombreuses choses en interne (sAMAccountName) doit être unique dans l'ensemble du domaine.

D'autres services d'annuaire ont des exigences quelque peu similaires, comme uniqueID devrait vraiment être unique dans l'ensemble du répertoire, mais c'est plus parce que les applications font généralement cette hypothèse, car les rédacteurs d'applications ont été trop paresseux pour traiter le problème complexe (je ne blâme pas eux, c'est un problème difficile) de savoir comment gérer deux utilisateurs avec des noms courts de jsmith essayant d'utiliser un service, mais existant dans deux conteneurs différents. (C'est-à-dire peut-être cn = jsmith, ou = Londres, dc = acme, dc = com et cn = jsmith, ou = Texas, dc = acme, dc = com).

Comment votre application utilisant ce répertoire devrait-elle décider quel utilisateur utiliser? La réponse habituelle est de laisser l'utilisateur décider. Mais cela signifie attraper ce cas, présenter une interface utilisateur au choix de l'utilisateur et ainsi de suite.

La plupart des rédacteurs d'applications ignorent simplement cette possibilité et utilisent simplement uniqueID ou sAMAccountName car c'est unique (en quelque sorte) et plus facile à faire.

La différence entre uniqueID et sAMAccountName serait que uniqueID devrait être unique dans tout l'espace de nom du répertoire. Alors que sAMAccountName est uniquement garanti unique au sein du domaine. Si l'arbre AD a plusieurs domaines, il n'y a pas de garantie d'unicité, entre domaines.

D'autres ont expliqué pourquoi l'utilisation d'un nom de domaine est une bonne idée (mais n'est pas obligatoire). J'ajoute simplement que la question est fausse: avoir un suffixe de base basé sur le nom d'une machine n'est pas du tout recommandé (pour des raisons évidentes: que se passe-t-il si vous remplacez gandalf.example.compar sarouman.example.com?). En règle générale, vous n'utilisez que le nom de domaine délégué. Si c'est le cas example.com, vous utilisez dc=example,dc=com.

La racine du répertoire doit être définie sur quelque chose. Il peut être réglé à votre guise. Le définir sur le nom de domaine est simplement une convention utile qui garantit que votre espace de nom de répertoire est unique.

Version courte: faites correspondre votre nom de domaine pour garantir que le chemin de base est unique.

Faites-le, et vous ne ressemblerez pas à un nouvel administrateur si votre entreprise fusionne avec une autre, et vous devez fusionner les systèmes :)

Ok, c'était une version très courte =)