¿Puedo obtener una explicación de la sintaxis de los sufijos de base de búsqueda LDAP?

Sé que un sufijo de base de búsqueda LDAP generalmente coincide con el nombre de host del servidor de directorio. En otras palabras, sé que si el nombre de host es od.foobar.com, debería usar el sufijo de base de búsqueda:dc=od,dc=foorbar,dc=com

Me molesta no entender por qué estoy haciendo esto. ¿Podría alguien proporcionar algunos antecedentes y explicar exactamente lo que estoy haciendo?

Antes de que Microsoft abrazara, extendiera y cambiara el LDAP, la mayoría de las implementaciones tenían objetos para representar la raíz del árbol. Es decir, tienes que empezar desde algún lado.

Por razones que no tengo completamente claras, en Active Directory, cada Dominio en el árbol / bosque está enraizado con un nombre que dc = dominio, dc = com que en realidad no son dos objetos separados, sino que es una raíz virtual del directorio nombre del espacio

Creo que parte de ello proviene del hecho de que, independientemente de lo que se diga sobre Active Directory, sigue siendo una serie de dominios vinculados, y cada dominio debe tratarse como una entidad independiente.

Ahora hay confianzas transitivas automáticas dentro de un árbol de AD, lo que hace que sea menos importante para los usuarios finales, pero a pesar de que el espacio de nombres parece un poco contiguo, en realidad no lo es.

Esto se hace más evidente con algunas de las reglas de nomenclatura con AD. Por ejemplo, sAMAccountName debe ser único dentro de un dominio, independientemente de si están en el mismo contenedor o no. Es decir, el nombre completo debe ser único (no puede tener dos usuarios de John Smith en el mismo contenedor), pero el nombre corto que se usa internamente para muchas cosas (sAMAccountName) debe ser único en todo el dominio.

Otros servicios de directorio tienen requisitos algo similares, como uniqueID realmente debería ser único dentro de todo el directorio, pero eso es más porque las aplicaciones generalmente asumen eso, ya que los escritores de aplicaciones han sido demasiado vagos para lidiar con el problema complejo (no culpo ellos, es un problema difícil) de cómo manejar dos usuarios con nombres cortos de jsmith que intentan usar un servicio, pero que existen en dos contenedores diferentes. (Es decir, cn = jsmith, ou = Londres, dc = acme, dc = com y cn = jsmith, ou = Texas, dc = acme, dc = com).

¿Cómo debe decidir su aplicación el uso de este directorio? La respuesta habitual es dejar que el usuario decida. Pero eso significa detectar este caso, presentar una interfaz de usuario para que el usuario elija y otras cosas.

La mayoría de los escritores de aplicaciones simplemente ignoran esa posibilidad y simplemente usan uniqueID o sAMAccountName porque eso es único (más o menos) y más fácil de hacer.

La diferencia entre uniqueID y sAMAccountName sería que uniqueID debería ser único en todo el espacio del nombre del directorio. Mientras que sAMAccountName solo se garantiza como único dentro del dominio. Si el árbol AD ​​tiene varios dominios, no hay garantía de unicidad entre dominios.

Otros han explicado por qué usar un nombre de dominio es una buena idea (pero no es obligatorio). Solo agrego que la pregunta es incorrecta: no se recomienda tener un sufijo base basado en el nombre de una máquina (por razones obvias: ¿qué sucede si lo reemplaza gandalf.example.compor sarouman.example.com?). Por lo general, solo usa el nombre de dominio delegado, por lo que, si lo tiene example.com, lo usa dc=example,dc=com.

La raíz del directorio debe establecerse en algo. Se puede configurar a lo que quieras. Establecerlo en el nombre de dominio es simplemente una convención útil que garantiza que su espacio de nombre de directorio sea único.

Versión corta: haga coincidir su nombre de dominio como garantía de que la ruta base es única.

Hágalo, y no se verá como un administrador newb si su empresa se fusiona con otra, y necesita fusionar sistemas :)

Ok, esa fue una versión muy corta =)