Protocolo ligero de acceso a directorios

El Protocolo ligero de acceso a directorios ( LDAP / ˈ ɛ l d æ p / ) es un protocolo de aplicación estándar de la industria, abierto y neutral respecto de los proveedores, para acceder y mantener servicios de información de directorio distribuidos a través de una red de Protocolo de Internet (IP). ^[1] Los servicios de directorio desempeñan un papel importante en el desarrollo de aplicaciones de intranet e Internet al permitir compartir información sobre usuarios, sistemas, redes, servicios y aplicaciones en toda la red. ^{[2] Como ejemplos, los servicios de directorio pueden proporcionar cualquier conjunto organizado de registros, a menudo con una estructura jerárquica, como un directorio} de correo electrónico corporativo . De manera similar, un directorio telefónico es una lista de suscriptores con una dirección y un número de teléfono.

LDAP se especifica en una serie de publicaciones de la Internet Engineering Task Force (IETF) denominadas Request for Comments (RFC), que utilizan el lenguaje de descripción ASN.1 . La última especificación es la versión 3, publicada como RFC 4511 ^[3] (la RFC 4510 proporciona una hoja de ruta para las especificaciones técnicas).

Un uso común de LDAP es proporcionar un lugar central para almacenar nombres de usuario y contraseñas. Esto permite que muchas aplicaciones y servicios diferentes se conecten al servidor LDAP para validar usuarios. ^[4]

LDAP se basa en un subconjunto más simple de los estándares incluidos en el estándar X.500 . Debido a esta relación, a LDAP a veces se lo denomina X.500-lite. ^[5]

La comprensión de las empresas de telecomunicaciones sobre los requisitos de los directorios se desarrolló bien después de unos 70 años de producción y gestión de directorios telefónicos. Estas empresas introdujeron el concepto de servicios de directorio en la tecnología de la información y las redes informáticas , y su aporte culminó en la especificación integral X.500 ^[6] , un conjunto de protocolos producidos por la Unión Internacional de Telecomunicaciones (UIT) en la década de 1980.

Tradicionalmente, se accedía a los servicios de directorio X.500 a través del Protocolo de acceso a directorios X.500 (DAP), que requería la pila de protocolos de interconexión de sistemas abiertos (OSI) . LDAP se concibió originalmente como un protocolo alternativo ligero para acceder a los servicios de directorio X.500 a través de la pila de protocolos TCP/IP más simple (y ahora muy extendida) . Este modelo de acceso a directorios se tomó prestado de los protocolos DIXIE y Directory Assistance Service .

El protocolo fue creado originalmente ^[7] por Tim Howes de la Universidad de Michigan , Steve Kille de Isode Limited, Colin Robbins de Nexor y Wengyik Yeong de Performance Systems International , alrededor de 1993, como sucesor ^[8] de DIXIE y DAS . Mark Wahl de Critical Angle Inc., Tim Howes y Steve Kille comenzaron a trabajar en 1996 en una nueva versión de LDAP, LDAPv3, bajo la égida del Grupo de Trabajo de Ingeniería de Internet (IETF). LDAPv3, publicado por primera vez en 1997, reemplazó a LDAPv2 y agregó soporte para extensibilidad, integró la Capa de seguridad y autenticación simple y alineó mejor el protocolo con la edición de 1993 de X.500. El desarrollo posterior de las propias especificaciones LDAPv3 y de numerosas extensiones que agregan características a LDAPv3 ha llegado a través del IETF .

En las primeras etapas de ingeniería de LDAP, se lo conocía como Protocolo ligero de exploración de directorios o LDBP . Se lo renombró cuando se amplió el alcance del protocolo más allá de la exploración y búsqueda de directorios, para incluir funciones de actualización de directorios. Se le dio el nombre de ligero porque no era tan intensivo en red como su predecesor DAP y, por lo tanto, se implementaba más fácilmente a través de Internet debido a su uso relativamente modesto de ancho de banda.

LDAP ha influido en los protocolos de Internet posteriores, incluidas las versiones posteriores de X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML) y Service Location Protocol (SLP). También se utiliza como base para Active Directory de Microsoft .

Un cliente inicia una sesión LDAP conectándose a un servidor LDAP, llamado Agente de Sistema de Directorio (DSA), de forma predeterminada en el puerto TCP y UDP 389, o en el puerto 636 para LDAPS (LDAP sobre TLS/SSL, consulte a continuación). ^[9] A continuación, el cliente envía una solicitud de operación al servidor, y un servidor envía respuestas a cambio. Con algunas excepciones, el cliente no necesita esperar una respuesta antes de enviar la siguiente solicitud, y el servidor puede enviar las respuestas en cualquier orden. Toda la información se transmite utilizando reglas de codificación básicas (BER).

El cliente podrá solicitar las siguientes operaciones:

• StartTLS: utiliza la extensión de seguridad de la capa de transporte (TLS) LDAPv3 para una conexión segura
• Vincular: autenticar y especificar la versión del protocolo LDAP
• Buscar: busca y/o recupera entradas de directorio
• Comparar: prueba si una entrada nombrada contiene un valor de atributo determinado
• Añadir una nueva entrada
• Eliminar una entrada
• Modificar una entrada
• Modificar nombre distinguido (DN): mover o cambiar el nombre de una entrada
• Abandonar – abortar una solicitud anterior
• Operación extendida: operación genérica utilizada para definir otras operaciones
• Desenlazar: cierra la conexión (no lo inverso de Enlazar)

Además, el servidor puede enviar "Notificaciones no solicitadas" que no son respuestas a ninguna solicitud, por ejemplo, antes de que se agote el tiempo de conexión.

Un método alternativo común para proteger la comunicación LDAP es el uso de un túnel SSL . El puerto predeterminado para LDAP sobre SSL es 636. El uso de LDAP sobre SSL era común en LDAP versión 2 (LDAPv2), pero nunca se estandarizó en ninguna especificación formal. Este uso ha quedado obsoleto junto con LDAPv2, que se retiró oficialmente en 2003. ^[10]

El protocolo proporciona una interfaz con directorios que siguen la edición de 1993 del modelo X.500 :

• Una entrada consta de un conjunto de atributos.
• Un atributo tiene un nombre (un tipo de atributo o una descripción de atributo ) y uno o más valores. Los atributos se definen en un esquema (ver a continuación).
• Cada entrada tiene un identificador único: su nombre distintivo (DN). Este consiste en su nombre distintivo relativo (RDN), construido a partir de algunos atributos de la entrada, seguido del DN de la entrada principal. Piense en el DN como la ruta completa del archivo y en el RDN como su nombre de archivo relativo en su carpeta principal (por ejemplo, si /foo/bar/myfile.txtfuera el DN, myfile.txtsería el RDN).

Un DN puede cambiar durante la vida útil de la entrada, por ejemplo, cuando las entradas se mueven dentro de un árbol. Para identificar entradas de manera confiable e inequívoca, se puede proporcionar un UUID en el conjunto de atributos operativos de la entrada .

Una entrada puede verse así cuando se representa en el formato de intercambio de datos LDAP (LDIF), un formato de texto simple (a diferencia de un protocolo binario como el propio LDAP):

dn : cn = John Doe , dc = ejemplo , dc = com cn : John Doe givenName : John sn : Doe númeroDeTeléfono : +1 888 555 6789 númeroDeTeléfono : +1 888 555 1232 correo electrónico : [email protected] gerente : cn=Barbara Doe,dc=ejemplo,dc=com claseObjeto : inetOrgPerson claseObjeto : organizationPerson claseObjeto : persona claseObjeto : top            

" dn" es el nombre distintivo de la entrada; no es un atributo ni una parte de la entrada. " cn=John Doe" es el RDN (nombre distintivo relativo) de la entrada y " dc=example,dc=com" es el DN de la entrada principal, donde " dc" denota ' Componente de dominio '. Las otras líneas muestran los atributos de la entrada. Los nombres de los atributos suelen ser cadenas mnemotécnicas, como " cn" para el nombre común, " dc" para el componente de dominio, " mail" para la dirección de correo electrónico y " sn" para el apellido. ^[11]

Un servidor contiene un subárbol que comienza con una entrada específica, por ejemplo, " dc=example,dc=com" y sus hijos. Los servidores también pueden contener referencias a otros servidores, por lo que un intento de acceder a " ou=department,dc=example,dc=com" podría devolver una referencia de referencia o de continuación a un servidor que contenga esa parte del árbol de directorios. El cliente puede entonces ponerse en contacto con el otro servidor. Algunos servidores también admiten el encadenamiento , lo que significa que el servidor se pone en contacto con el otro servidor y devuelve los resultados al cliente.

LDAP rara vez define un orden: el servidor puede devolver los valores de un atributo, los atributos de una entrada y las entradas encontradas mediante una operación de búsqueda en cualquier orden. Esto se desprende de las definiciones formales: una entrada se define como un conjunto de atributos y un atributo es un conjunto de valores, y los conjuntos no necesitan estar ordenados.

La operación ADD inserta una nueva entrada en la base de datos del servidor de directorio. ^[12] Si el nombre distinguido en la solicitud de adición ya existe en el directorio, entonces el servidor no agregará una entrada duplicada sino que establecerá el código de resultado en el resultado de la adición en decimal 68, "entryAlreadyExists". ^[13]

• Los servidores compatibles con LDAP nunca desreferenciarán el nombre distinguido transmitido en la solicitud de agregar cuando intenten localizar la entrada, es decir, los nombres distinguidos nunca pierden su alias.
• Los servidores compatibles con LDAP garantizarán que el nombre distinguido y todos los atributos cumplan con los estándares de nombres.
• El asiento a agregar no debe existir y debe existir el superior inmediato.

dn : uid = usuario , ou = personas , dc = ejemplo , dc = com changetype : agregar objectClass : superior objectClass : persona uid : usuario sn : apellido cn : nombre común userPassword : contraseña      

En el ejemplo anterior, uid=user,ou=people,dc=example,dc=comno debe existir y ou=people,dc=example,dc=comdebe existir.

Cuando se crea una sesión LDAP, es decir, cuando un cliente LDAP se conecta al servidor, el estado de autenticación de la sesión se establece como anónimo. La operación BIND establece el estado de autenticación de una sesión.

Simple BIND y SASL PLAIN pueden enviar el DN y la contraseña del usuario en texto sin formato , por lo que las conexiones que utilizan Simple o SASL PLAIN deben estar cifradas mediante Transport Layer Security (TLS). El servidor normalmente comprueba la contraseña con el userPasswordatributo en la entrada nombrada. Anonymous BIND (con DN y contraseña vacíos) restablece la conexión al estado anónimo.

SASL (Simple Authentication and Security Layer) BIND proporciona servicios de autenticación a través de una amplia gama de mecanismos, por ejemplo, Kerberos o el certificado de cliente enviado con TLS. ^[14]

BIND también establece la versión del protocolo LDAP enviando un número de versión en forma de entero. Si el cliente solicita una versión que el servidor no admite, el servidor debe establecer el código de resultado en la respuesta de BIND al código de error de protocolo. Normalmente, los clientes deben utilizar LDAPv3, que es el valor predeterminado en el protocolo, pero no siempre en las bibliotecas LDAP.

BIND tenía que ser la primera operación de una sesión en LDAPv2, pero no es obligatorio a partir de LDAPv3. En LDAPv3, cada solicitud BIND exitosa cambia el estado de autenticación de la sesión y cada solicitud BIND fallida restablece el estado de autenticación de la sesión.

Para eliminar una entrada, un cliente LDAP transmite una solicitud de eliminación correctamente formada al servidor. ^[15]

• Una solicitud de eliminación debe contener el nombre distinguido de la entrada que se va a eliminar
• Los controles de solicitud también se pueden adjuntar a la solicitud de eliminación.
• Los servidores no desreferencian los alias al procesar una solicitud de eliminación
• Solo las entradas de hoja (entradas sin subordinados) pueden eliminarse mediante una solicitud de eliminación. Algunos servidores admiten un atributo operativo hasSubordinatescuyo valor indica si una entrada tiene entradas subordinadas, y algunos servidores admiten un atributo operativo numSubordinates^[16] que indica la cantidad de entradas subordinadas a la entrada que contiene el numSubordinatesatributo.
• Algunos servidores admiten el control de solicitud de eliminación de subárboles, lo que permite la eliminación del DN y de todos los objetos subordinados al DN, sujetos a controles de acceso. Las solicitudes de eliminación están sujetas a controles de acceso, es decir, si se permitirá que una conexión con un estado de autenticación determinado elimine una entrada determinada, lo que se rige por mecanismos de control de acceso específicos del servidor.

La operación de búsqueda se utiliza tanto para buscar como para leer entradas. Sus parámetros son:

objeto base

El nombre de la entrada del objeto base (o posiblemente la raíz) respecto del cual se realizará la búsqueda.

alcance

Qué elementos debajo del objeto base se deben buscar. Esto puede ser BaseObject(buscar solo la entrada nombrada, generalmente se usa para leer una entrada), singleLevel(entradas inmediatamente debajo del DN base) o wholeSubtree(el subárbol completo comenzando en el DN base).

filtrar

Criterios a utilizar para seleccionar elementos dentro del ámbito. Por ejemplo, el filtro (&(objectClass=person)(|(givenName=John)(mail=john*)))seleccionará "personas" (elementos de objectClass person) donde las reglas de coincidencia para givenNamey maildeterminan si los valores de esos atributos coinciden con la afirmación del filtro. Tenga en cuenta que un error común es pensar que los datos LDAP distinguen entre mayúsculas y minúsculas, mientras que, de hecho, las reglas de coincidencia y las reglas de ordenación determinan las coincidencias, las comparaciones y las relaciones de valores relativos. Si se requiriera que los filtros de ejemplo coincidieran con las mayúsculas y minúsculas del valor del atributo, se debe utilizar un filtro de coincidencia extensible , por ejemplo,(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

desreferenciar alias

Si y cómo seguir entradas de alias (entradas que hacen referencia a otras entradas),

atributos

¿Qué atributos se deben devolver en las entradas de resultados?

límite de tamaño, límite de tiempo

Número máximo de entradas que se pueden devolver y tiempo máximo para permitir que se ejecute la búsqueda. Sin embargo, estos valores no pueden anular ninguna restricción que el servidor imponga sobre el límite de tamaño y el límite de tiempo.

tiposSolo

Devuelve únicamente tipos de atributos, no valores de atributos.

El servidor devuelve las entradas coincidentes y, en su caso, las referencias de continuación. Estas pueden devolverse en cualquier orden. El resultado final incluirá el código de resultado.

La operación Comparar toma un DN, un nombre de atributo y un valor de atributo, y verifica si la entrada nombrada contiene ese atributo con ese valor.

Los clientes LDAP utilizan la operación MODIFY para solicitar que el servidor LDAP realice cambios en las entradas existentes. ^[17] Los intentos de modificar entradas que no existen fallarán. Las solicitudes MODIFY están sujetas a controles de acceso implementados por el servidor.

La operación MODIFY requiere que se especifique el nombre distintivo (DN) de la entrada y una secuencia de cambios. Cada cambio en la secuencia debe ser uno de los siguientes:

• agregar (agrega un nuevo valor, que no debe existir ya en el atributo)
• eliminar (eliminar un valor existente)
• reemplazar (reemplazar un valor existente con un nuevo valor)

Ejemplo LDIF de cómo agregar un valor a un atributo:

dn : dc = ejemplo , dc = com changetype : modificar add : cn cn : el-nuevo-valor-cn-que-se-agregará -    

Para reemplazar el valor de un atributo existente, utilice la replacepalabra clave. Si el atributo tiene varios valores, el cliente debe especificar el valor del atributo que se va a actualizar.

Para eliminar un atributo de una entrada, utilice la palabra clave deletey el designador changetype modify. Si el atributo tiene varios valores, el cliente debe especificar el valor del atributo que se eliminará.

También existe una extensión Modify-Increment ^[18] que permite que el valor de un atributo incrementable se incremente en una cantidad especificada. El siguiente ejemplo utiliza LDIF employeeNumberpara incrementar 5:

dn : uid = usuario.0 , ou = personas , dc = ejemplo , dc = com tipo de cambio : modificar incremento : númeroEmpleado númeroEmpleado : 5 -   

Cuando los servidores LDAP están en una topología replicada, los clientes LDAP deberían considerar el uso del control de post-lectura para verificar actualizaciones en lugar de una búsqueda después de una actualización. ^[19] El control de post-lectura está diseñado para que las aplicaciones no necesiten emitir una solicitud de búsqueda después de una actualización; es de mala educación recuperar una entrada con el único propósito de verificar que una actualización funcionó debido al modelo de consistencia eventual de replicación . Un cliente LDAP no debería asumir que se conecta al mismo servidor de directorio para cada solicitud porque los arquitectos pueden haber colocado balanceadores de carga o proxies LDAP o ambos entre los clientes y servidores LDAP.

La modificación de DN (mover/renombrar entrada) toma el nuevo RDN (nombre distinguido relativo), opcionalmente el DN del nuevo padre y un indicador que indica si se deben eliminar los valores de la entrada que coinciden con el RDN anterior. El servidor puede admitir el cambio de nombre de subárboles de directorios completos.

Una operación de actualización es atómica: otras operaciones verán la nueva entrada o la antigua. Por otro lado, LDAP no define transacciones de múltiples operaciones: si lee una entrada y luego la modifica, otro cliente puede haber actualizado la entrada mientras tanto. Sin embargo, los servidores pueden implementar extensiones ^[20] que admitan esto.

La operación extendida es una operación LDAP genérica que puede definir nuevas operaciones que no formaban parte de la especificación del protocolo original. StartTLS es una de las extensiones más importantes. Otros ejemplos incluyen Cancelar y Modificar contraseña. ^{[ cita requerida ]}

La operación StartTLS establece la seguridad de la capa de transporte (descendiente de SSL ) en la conexión. Puede proporcionar confidencialidad de los datos (para protegerlos de ser observados por terceros) y/o protección de la integridad de los datos (que protege los datos de la manipulación). Durante la negociación TLS, el servidor envía su certificado X.509 para demostrar su identidad. El cliente también puede enviar un certificado para demostrar su identidad. Después de hacerlo, el cliente puede utilizar SASL /EXTERNAL. Al utilizar SASL/EXTERNAL, el cliente solicita al servidor que derive su identidad de las credenciales proporcionadas en un nivel inferior (como TLS). Aunque técnicamente el servidor puede utilizar cualquier información de identidad establecida en cualquier nivel inferior, normalmente el servidor utilizará la información de identidad establecida por TLS.

Los servidores también suelen admitir el protocolo no estándar "LDAPS" ("LDAP seguro", comúnmente conocido como "LDAP sobre SSL") en un puerto separado, por defecto 636. LDAPS se diferencia de LDAP en dos formas: 1) al conectarse, el cliente y el servidor establecen TLS antes de que se transfieran los mensajes LDAP (sin una operación StartTLS) y 2) la conexión LDAPS debe cerrarse al cerrarse TLS.

Algunas bibliotecas cliente "LDAPS" sólo cifran la comunicación; no verifican el nombre del host con el nombre en el certificado suministrado. ^[21]

La operación Abandon solicita que el servidor cancele una operación nombrada mediante un ID de mensaje. El servidor no necesita aceptar la solicitud. Ni Abandon ni una operación abandonada exitosamente envían una respuesta. Una operación extendida similar, Cancel, envía respuestas, pero no todas las implementaciones lo admiten.

La operación Unbind abandona cualquier operación pendiente y cierra la conexión. No tiene respuesta. El nombre es de origen histórico y no es lo opuesto a la operación Bind. ^[22]

Los clientes pueden abortar una sesión simplemente cerrando la conexión, pero deben usar Unbind. ^[23] Unbind permite al servidor cerrar la conexión sin problemas y liberar recursos que de otro modo mantendría durante algún tiempo hasta descubrir que el cliente había abandonado la conexión. También le indica al servidor que cancele las operaciones que se puedan cancelar y que no envíe respuestas para las operaciones que no se puedan cancelar. ^[24]

Existe un esquema de identificador uniforme de recursos (URI) LDAP , que los clientes admiten en distintos grados y que los servidores devuelven en referencias y referencias de continuación (consulte RFC 4516):

ldap://host:puerto/DN?atributos?alcance?filtro?extensiones

La mayoría de los componentes descritos a continuación son opcionales.

• host es el FQDN o la dirección IP del servidor LDAP para buscar.
• puerto es el puerto de red (puerto predeterminado 389) del servidor LDAP.
• DN es el nombre distinguido que se utilizará como base de búsqueda.
• atributos es una lista de atributos separados por comas para recuperar.
• El alcance especifica el alcance de la búsqueda y puede ser "base" (predeterminado), "uno" o "sub".
• El filtro es un filtro de búsqueda. Por ejemplo, (objectClass=*)como se define en RFC 4515.
• Las extensiones son extensiones del formato URL LDAP.

Por ejemplo, " ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" hace referencia a todos los atributos de usuario en la entrada de John Doe en ldap.example.com, mientras que " ldap:///dc=example,dc=com??sub?(givenName=John)" busca la entrada en el servidor predeterminado (observe la triple barra, que omite el host, y el doble signo de interrogación, que omite los atributos). Al igual que en otras URL, los caracteres especiales deben codificarse con porcentajes .

Existe un ldapsesquema de URI no estándar similar para LDAP sobre SSL. No debe confundirse con LDAP con TLS, que se logra mediante la operación StartTLS utilizando el ldapesquema estándar.

El contenido de las entradas de un subárbol está regido por un esquema de directorio , un conjunto de definiciones y restricciones relativas a la estructura del árbol de información de directorio (DIT).

El esquema de un servidor de directorio define un conjunto de reglas que rigen los tipos de información que puede almacenar el servidor. Tiene varios elementos, entre ellos:

• Sintaxis de atributos: proporcionan información sobre el tipo de información que se puede almacenar en un atributo.
• Reglas de coincidencia: proporcionan información sobre cómo realizar comparaciones con valores de atributos.
• Usos de reglas de coincidencia: indique qué tipos de atributos se pueden usar junto con una regla de coincidencia particular.
• Tipos de atributos: define un identificador de objeto (OID) y un conjunto de nombres que pueden hacer referencia a un atributo determinado, y asocia ese atributo con una sintaxis y un conjunto de reglas de coincidencia.
• Clases de objeto: definen colecciones de atributos con nombre y los clasifican en conjuntos de atributos obligatorios y opcionales.
• Formularios de nombre: define reglas para el conjunto de atributos que deben incluirse en el RDN de una entrada.
• Reglas de contenido: define restricciones adicionales sobre las clases de objetos y atributos que se pueden usar junto con una entrada.
• Regla de estructura: define reglas que rigen los tipos de entradas subordinadas que puede tener una entrada determinada.

Los atributos son los elementos responsables de almacenar información en un directorio, y el esquema define las reglas para qué atributos se pueden usar en una entrada, los tipos de valores que pueden tener esos atributos y cómo los clientes pueden interactuar con esos valores.

Los clientes pueden obtener información sobre los elementos del esquema que admite el servidor recuperando una subentrada de subesquema adecuada.

El esquema define las clases de objetos . Cada entrada debe tener un atributo objectClass, que contiene las clases con nombre definidas en el esquema. La definición del esquema de las clases de una entrada define qué tipo de objeto puede representar la entrada (por ejemplo, una persona, una organización o un dominio). Las definiciones de clases de objetos también definen la lista de atributos que deben contener valores y la lista de atributos que pueden contener valores.

Por ejemplo, una entrada que represente a una persona podría pertenecer a las clases "top" y "person". La pertenencia a la clase "person" requeriría que la entrada contuviera los atributos "sn" y "cn", y permitiría que la entrada también contuviera "userPassword", "telephoneNumber" y otros atributos. Dado que las entradas pueden tener múltiples valores ObjectClasses, cada entrada tiene un complejo de conjuntos de atributos opcionales y obligatorios formados a partir de la unión de las clases de objetos que representa. Las ObjectClasses se pueden heredar, y una sola entrada puede tener múltiples valores ObjectClasses que definen los atributos disponibles y requeridos de la entrada en sí. Un paralelo al esquema de una objectClass es una definición de clase y una instancia en la programación orientada a objetos , que representan objectClass LDAP y entrada LDAP, respectivamente.

Los servidores de directorio pueden publicar el esquema de directorio que controla una entrada en un DN base determinado por el atributo operativo subschemaSubentry de la entrada. (Un atributo operativo describe el funcionamiento del directorio en lugar de la información del usuario y solo se devuelve a partir de una búsqueda cuando se lo solicita explícitamente).

Los administradores de servidores pueden agregar entradas de esquema adicionales además de los elementos de esquema proporcionados. Un esquema para representar a personas individuales dentro de organizaciones se denomina esquema de páginas blancas .

Gran parte de la operación del servidor queda en manos del implementador o administrador, por lo que los servidores pueden configurarse para soportar una amplia variedad de escenarios.

Por ejemplo, el almacenamiento de datos en el servidor no está especificado: el servidor puede utilizar archivos planos, bases de datos o simplemente ser una puerta de enlace a algún otro servidor. El control de acceso no está estandarizado, aunque se ha trabajado en ello y existen modelos de uso común. Las contraseñas de los usuarios pueden almacenarse en sus entradas o en otro lugar. El servidor puede negarse a realizar operaciones cuando lo desee e imponer diversos límites.

La mayoría de las partes de LDAP son extensibles. Ejemplos: se pueden definir nuevas operaciones. Los controles pueden modificar solicitudes y respuestas, por ejemplo, para solicitar resultados de búsqueda ordenados. Se pueden definir nuevos ámbitos de búsqueda y métodos de enlace. Los atributos pueden tener opciones que pueden modificar su semántica.

A medida que LDAP ha ganado impulso, los proveedores lo han proporcionado como un protocolo de acceso a otros servicios. Luego, la implementación reformula los datos para imitar el modelo LDAP/X.500, pero el grado de seguimiento de este modelo varía. Por ejemplo, existe software para acceder a bases de datos SQL a través de LDAP, aunque LDAP no se presta fácilmente a esto. ^[25] Los servidores X.500 también pueden admitir LDAP.

De manera similar, los datos que antes se guardaban en otros tipos de almacenes de datos a veces se trasladan a directorios LDAP. Por ejemplo, la información de usuarios y grupos de Unix se puede almacenar en LDAP y se puede acceder a ella a través de módulos PAM y NSS . Otros servicios suelen utilizar LDAP para la autenticación o autorización (qué acciones puede realizar un determinado usuario ya autenticado en qué servicio). Por ejemplo, en Active Directory, Kerberos se utiliza en el paso de autenticación, mientras que LDAP se utiliza en el paso de autorización.

Un ejemplo de dicho modelo de datos es el esquema GLUE, ^[26] que se utiliza en un sistema de información distribuido basado en LDAP que permite a los usuarios, aplicaciones y servicios descubrir qué servicios existen en una infraestructura de Grid y más información sobre su estructura y estado.

Un servidor LDAP puede devolver referencias a otros servidores para solicitudes que no puede satisfacer por sí mismo. Esto requiere una estructura de nombres para las entradas LDAP, de modo que se pueda encontrar un servidor que contenga un nombre distinguido (DN) determinado, un concepto definido en el Directorio X.500 y también utilizado en LDAP. Otra forma de localizar servidores LDAP para una organización es un registro de servidor DNS (SRV).

Una organización con el dominio example.org puede utilizar el DN LDAP de nivel superior dc=example, dc=org(donde dc significa componente de dominio). Si el servidor LDAP también se llama ldap.example.org, la URL LDAP de nivel superior de la organización se convierte en ldap://ldap.example.org/dc=example,dc=org.

En X.500 [2008] y LDAPv3 se utilizan principalmente dos estilos comunes de denominación, que están documentados en las especificaciones de la UIT y en las RFC de la IETF. La forma original toma el objeto de nivel superior como objeto de país, como c=US, c=FR. El modelo de componente de dominio utiliza el modelo descrito anteriormente. Un ejemplo de denominación basada en país podría ser l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR, o en EE. UU.: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.

• Resolución de nombres ambiguos
• Servidor de nombres CCSO
• Servicio de nombres federado
• Hesíodo (nombre de servicio)
• Modelo de base de datos jerárquico
• Servidor de claves (criptográfico)
• Interfaz de programación de aplicaciones LDAP
• Lista de software LDAP
• Capa de seguridad y autenticación simple (SASL)

• Rec. UIT-T X.680 , "Notación de sintaxis abstracta uno (ASN.1) - Especificación de la notación básica", 1994
• Reglas de codificación básicas (BER) - Rec. UIT-T X.690, "Especificación de reglas de codificación ASN.1: reglas de codificación básica, canónica y distinguida", 1994
• RFC 3641 - Reglas de codificación de cadenas genéricas (GSER) para tipos ASN.1
• RFC 4346 - El protocolo TLS versión 1.1
• RFC 4422 - Capa de seguridad y autenticación simple ( SASL )
• Mecanismos SASL registrados en IANA

• Arkills, B (2003). Explicación de los directorios LDAP: Introducción y análisis. Addison-Wesley Professional . ISBN 978-0-201-78792-4.
• Carter, G (2003). Administración del sistema LDAP . O'Reilly Media . ISBN. 978-1-56592-491-8.
• Donley, C (2002). Programación, gestión e integración de LDAP . Publicaciones Manning . ISBN. 978-1-930110-40-3.
• Howes, T; Smith, M; Good, G (2003). Comprensión e implementación de servicios de directorio LDAP. Addison-Wesley Professional . ISBN 978-0-672-32316-4.
• Rhoton, J (1999). Guía del programador para correo de Internet: SMTP, POP, IMAP y LDAP . Elsevier. ISBN 978-1-55558-212-8.
• Voglmaier, R (2003). El ABC de LDAP: cómo instalar, ejecutar y administrar servicios LDAP . Publicaciones de Auerbach. ISBN 978-0-8493-1346-2.

• Lista de servidores LDAP públicos (2013): «Ldapwiki: Public LDAP Servers». ldapwiki.com . 2013 . Consultado el 18 de enero de 2020 .