El servicio de directorio puede estar centralizado o distribuido:
- Centralizado: En este caso un único servidor ofrece todo el servicio de directorio respondiendo a todas las consultas de los clientes.
- Distribuido: Si el directorio está distribuido, varios servidores proporcionan el servicio de directorio. Cuando está distribuido, los datos pueden estar fraccionados y/o replicados:
- Cuando está fraccionada, cada servidor de directorio almacena un subconjunto único y no solapado de la información, es decir, una entrada es almacenada en un solo servidor.
- Cuando la información está replicada, una entrada puede estar almacenada en varios servidores.
Generalmente cuando el servicio de directorio es distribuido, parte de la información está fraccionada y parte está replicada.
En 1988, la CCITT (ahora ITU-T) creó el estándar X.500 sobre servicios de directorio, el cual organiza las entradas en el directorio de manera jerárquica, capaz de almacenar gran cantidad de datos, con grandes capacidades de búsqueda y fácilmente escalable. X.500 especifica que la comunicación entre el cliente y el servidor de directorio debe emplear el protocolo DAP, pero DAP es un protocolo a nivel de aplicación, por lo que, tanto al cliente como el servidor debían implementar completamente la torre de protocolos OSI.
LDAP surge como una alternativa a DAP. Las claves del éxito de LDAP en comparación con DAP de X.500 son:
- El modelo funcional de LDAP es más simple y ha eliminado opciones raramente utilizadas en X.500, siendo más fácil de comprender e implementar.
- LDAP representa la información mediante cadenas de caracteres en lugar de complicadas estructuras ASN.1.
El directorio LDAP tiene una estructura en forma de árbol denominado DIT. Cada entrada del directorio describe un objeto: persona, impresora, etc. La ruta completa a una entrada la identifica de modo inequívoco y se conoce como DN y está compuesto por una secuencia de partes más pequeñas llamadas RDN, de forma similar a como el nombre de un fichero consiste en un camino de directorios en muchos sistemas operativos.
Una clase de objeto (objectClass) es una descripción general de un tipo de objeto. Todos los objetos de LDAP deben tener el atributo objectClass. La definición de objectClass especifica qué atributos requiere un objeto LDAP, así como las clases de objetos que pueden existir. Los valores de este atributo los pueden modificar los clientes, pero el atributo objectClass en sí no puede eliminarse.
Un esquema (schema) define: qué clases de objetos se pueden almacenar en el directorio, qué atributos deben contener, qué atributos son opcionales y el formato de los atributos.
Por lo general, existen dos tipos de objetos:
- Contenedor: Este tipo de objeto puede contener a su vez otros objetos. Algunos ejemplos de estos elementos son:
Root(elemento raíz del árbol de directorios que no existe en realidad),c(country),ou(OrganizationalUnit) ydc(domainComponent).La figura análoga al contenedor es el directorio (carpeta) de un sistema de archivos.
- Hoja: Este tipo de objeto se encuentra al final de una rama y carece de objetos subordinados. Algunos ejemplos son:
Person/InetOrgPersonogroupofNames.
En la cúspide de la jerarquía del directorio se encuentra el elemento raíz Root. A este elemento le puede seguir en un nivel inferior c (country), dc (domainComponent) ó o (organization).
La siguiente imagen ilustra las relaciones jerárquicas dentro de un árbol de directorios LDAP:
La figura representa un DIT ficticio con entradas en cuatro niveles. Cada entrada se corresponde con una casilla en la figura. En este caso, el nombre válido completo DN del empleado ficticio upruebas es:
dn: uid=upruebas,ou=People,dc=ejemplo,dc=comLa definición global de qué tipo de objetos han de guardarse en el DIT se realiza mediante un esquema. El tipo de objeto se determina mediante la clase de objeto. La clase de objeto especifica qué atributos deben o pueden ser asignados a un objeto determinado. Por lo tanto, un esquema debe contener definiciones de todas las clases de objetos y atributos que van a utilizarse en el escenario de aplicación. Existen algunos esquemas de uso extendido (véase RFC 2252 y 2256). No obstante, si el entorno en el que va a utilizarse el servidor LDAP lo requiere, también pueden crearse nuevos esquemas en función del usuario o pueden combinarse varios esquemas entre sí.