Protocolo ligero de acceso a directorios (LDAP)

El Protocolo ligero de acceso a directorios o LDAP por su siglas en inglés Lightweight Directory Access Protocol es un protocolo de aplicación estándar de la industria, abierto e independiente del proveedor para acceder y mantener servicios de información de directorio distribuidos a través de una red de Protocolo de Internet (IP). 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. 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 seguimiento estándar del Grupo de trabajo de ingeniería de Internet (IETF) denominada Solicitud de comentarios (RFC), que utiliza el lenguaje de descripción ASN.1. La especificación más reciente es la Versión 3, publicada como RFC 4511 (el RFC4510 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 a los usuarios.

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

Historia

Los conocimientos de las empresas de telecomunicaciones sobre los requisitos de los directorios estaban bien desarrollados 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 sus aportes culminaron en la especificación integral X.500, 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 (DAP) X.500, que requería la pila de protocolos de interconexión de sistemas abiertos (OSI). Originalmente, LDAP estaba destinado a ser un protocolo alternativo liviano para acceder a los servicios de directorio X.500 a través de la pila de protocolos TCP/IP más simple (y ahora extendida). Este modelo de acceso a directorios se tomó prestado de los protocolos DIXIE y Directory Assistance Service.

El protocolo fue creado originalmente 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 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 los auspicios de Internet Engineering Task Force (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 adicional de las propias especificaciones de 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 conocía como Protocolo ligero de exploración de directorios o LDBP. Fue renombrado con la expansión del 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 su nombre de peso ligero porque no era tan intensivo en la red como su predecesor DAP y, por lo tanto, se implementó más fácilmente a través de Internet debido a su uso de ancho de banda relativamente modesto.

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.

Descripción general del protocolo

Un cliente inicia una sesión LDAP conectándose a un servidor LDAP, denominado Agente del 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). Luego, 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 mediante reglas de codificación básicas (BER).

El cliente podrá solicitar las siguientes operaciones:

• StartTLS: use la extensión LDAPv3 Transport Layer Security (TLS) para una conexión segura
• Bind: autentica y especifica la versión del protocolo LDAP
• Buscar: busque y/o recupere entradas de directorio
• Comparar: prueba si una entrada nombrada contiene un valor de atributo dado
• Agregar 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
• Desvincular: cerrar la conexión (no al revés de Bind)

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 asegurar la comunicación LDAP es usar un túnel SSL. El puerto predeterminado para LDAP sobre SSL es 636. El uso de LDAP sobre SSL era común en la versión 2 de LDAP (LDAPv2), pero nunca se estandarizó en ninguna especificación formal. Este uso ha quedado obsoleto junto con LDAPv2, que se retiró oficialmente en 2003.

Estructura de directorios

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 más abajo).
• Cada entrada tiene un identificador único: su Nombre Distinguido (DN). Este consiste en su Nombre Distinguido Relativo (RDN), construido a partir de algunos atributos en la entrada, seguido por el 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, entonces myfile.txtsería el RDN).

Un DN puede cambiar durante la vigencia de la entrada, por ejemplo, cuando las entradas se mueven dentro de un árbol. Para identificar las entradas de manera confiable y sin ambigüedades, se puede proporcionar un UUID en el conjunto de atributos operativos de la entrada.

Una entrada puede verse así cuando se representa en formato de intercambio de datos LDAP (LDIF) (LDAP en sí mismo es un protocolo binario):

dn: cn=John Doe,dc=ejemplo,dc=com
 cn: John Doe
 nombre dado: John
 sn: cierva
 Número de teléfono: +1 888 555 6789
 Número de teléfono: +1 888 555 1232
 correo: juan@ejemplo.com
 gerente: cn=Barbara Doe,dc=ejemplo,dc=com
 clase de objeto: inetOrgPerson
 clase de objeto: persona organizativa
 clase de objeto: persona
 clase de objeto: arriba

" dn" es el nombre distinguido de la entrada; no es ni un atributo ni una parte de la entrada. " cn=John Doe" es el RDN (Nombre Distinguido 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 atributo suelen ser cadenas mnemotécnicas, como " cn" para nombre común, " dc" para componente de dominio, " mail" para dirección de correo electrónico y " sn" para apellido.

Un servidor tiene un subárbol a partir de 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 o una referencia de continuación a un servidor que contiene esa parte del árbol de directorios. A continuación, el cliente puede 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 en una entrada y las entradas encontradas por una operación de búsqueda en cualquier orden. Esto se deriva de las definiciones formales: una entrada se define como un conjunto de atributos y un atributo es un conjunto de valores, y no es necesario ordenar los conjuntos.

Operaciones

Agregar

La operación ADD inserta una nueva entrada en la base de datos del servidor de directorio. Si el nombre distinguido en la solicitud de adición ya existe en el directorio, entonces el servidor no agregará una entrada duplicada pero establecerá el código de resultado en el resultado de la adición en decimal 68, "entryYaExists".

• Los servidores compatibles con LDAP nunca eliminarán la referencia al nombre distinguido transmitido en la solicitud de adición cuando intenten ubicar la entrada, es decir, los nombres distinguidos nunca perderán el alias.
• Los servidores compatibles con LDAP garantizarán que el nombre distinguido y todos los atributos se ajusten a los estándares de nomenclatura.
• El asiento a agregar no debe existir, y debe existir el superior inmediato.

dn: uid=usuario,ou=personas,dc=ejemplo,dc=com
tipo de cambio: agregar
clase de objeto: arriba
claseobjeto:persona
uid: usuario
sn: apellido
cn: nombre común
contraseña de usuario: contraseña

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

Vincular (autenticar)

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 en anónimo. La operación BIND establece el estado de autenticación para 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 cifrarse mediante Transport Layer Security (TLS). El servidor normalmente compara la contraseña con el userPassword atributo en la entrada nombrada. BIND anónimo (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.

BIND también establece la versión del protocolo LDAP enviando un número de versión en forma de número 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 BIND al código de un error de protocolo. Normalmente, los clientes deben usar LDAPv3, que es el predeterminado en el protocolo pero no siempre en las bibliotecas LDAP.

BIND tenía que ser la primera operación en una sesión en LDAPv2, pero no se requiere 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.

Borrar

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

• Una solicitud de eliminación debe contener el nombre distinguido de la entrada que se eliminará
• Los controles de solicitud también se pueden adjuntar a la solicitud de eliminación
• Los servidores no desreferencian los alias cuando procesan 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 que numSubordinatesindica el número de entradas subordinadas a la entrada que contiene el numSubordinatesatributo.
• Algunos servidores admiten el control de solicitud de eliminación de subárbol que permite la eliminación del DN y todos los objetos subordinados al DN, sujeto a controles de acceso. Las solicitudes de eliminación están sujetas a controles de acceso, es decir, si una conexión con un estado de autenticación determinado podrá eliminar una entrada determinada se rige por mecanismos de control de acceso específicos del servidor.

Busca y compara

La operación de búsqueda se utiliza tanto para buscar como para leer entradas. Sus parámetros son:objeto baseEl nombre de la entrada del objeto base (o posiblemente la raíz) con respecto a la cual se realizará la búsqueda.alcanceQué elementos debajo del objeto base buscar. Esto puede ser BaseObject(buscar solo la entrada con nombre, que normalmente se usa para leer una entrada), singleLevel(entradas inmediatamente debajo del DN base) o wholeSubtree(el subárbol completo que comienza en el DN base).filtrarCriterios a utilizar en la selección de elementos dentro del alcance. Por ejemplo, el filtro (&(objectClass=person)(|(givenName=John)(mail=john*)))seleccionará "personas" (elementos de objectClass person) donde las reglas coincidentes givenNamey maildeterminarán si los valores de esos atributos coinciden con la afirmación del filtro. Tenga en cuenta que un concepto erróneo común es que los datos LDAP distinguen entre mayúsculas y minúsculas, mientras que, de hecho, las reglas de coincidencia y las reglas de orden determinan las coincidencias, las comparaciones y las relaciones de valores relativos. Si se requería que los filtros de ejemplo coincidieran con el caso del valor del atributo, se debe usar un filtro de coincidencia extensible, por ejemplo,(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))derefAliasSi y cómo seguir las entradas de alias (entradas que se refieren a otras entradas),atributosQué atributos devolver en las entradas de resultados.límite de tamaño, límite de tiempoNúmero máximo de entradas para devolver y tiempo máximo para permitir que se ejecute la búsqueda. Estos valores, sin embargo, no pueden anular ninguna restricción que el servidor establezca sobre el límite de tamaño y el límite de tiempo.solo tiposDevuelve solo tipos de atributos, no valores de atributos.

El servidor devuelve las entradas coincidentes y potencialmente las referencias de continuación. Estos pueden ser devueltos 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.

Modificar

Los clientes LDAP utilizan la operación MODIFY para solicitar que el servidor LDAP realice cambios en las entradas existentes. Los intentos de modificar las 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 distinguido (DN) de la entrada y una secuencia de cambios. Cada cambio en la secuencia debe ser uno de:

• add (añadir 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 de LDIF de agregar un valor a un atributo:

dn: dc=ejemplo,dc=com
tipo de cambio: modificar
añadir: cn
cn: el-nuevo-valor-cn-a-ser-agregado
-

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 para actualizar.

Para eliminar un atributo de una entrada, utilice la palabra clave deletey el designador de tipo de cambio modify. Si el atributo tiene varios valores, el cliente debe especificar el valor del atributo a eliminar.

También hay una extensión Modify-Increment que permite incrementar un valor de atributo incrementable en una cantidad específica. El siguiente ejemplo usando incrementos LDIF employeeNumberpor 5:

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

Cuando los servidores LDAP están en una topología replicada, los clientes LDAP deberían considerar usar el control posterior a la lectura para verificar las actualizaciones en lugar de buscar una actualización. El control posterior a la lectura está diseñado para que las aplicaciones no necesiten emitir una solicitud de búsqueda después de una actualización; es una mala forma recuperar una entrada con el único propósito de verificar que una actualización funcionó debido al modelo de coherencia eventual de replicación. Un cliente LDAP no debe suponer que se conecta al mismo servidor de directorio para cada solicitud porque los arquitectos pueden haber colocado equilibradores de carga o proxies LDAP o ambos entre clientes y servidores LDAP.

Modificar DN

Modificar DN (mover/cambiar nombre de entrada) toma el nuevo RDN (Nombre Distinguido Relativo), opcionalmente el DN del nuevo padre, y una bandera que indica si se deben eliminar los valores en 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 anterior. Por otro lado, LDAP no define transacciones de operaciones múltiples: si lee una entrada y luego la modifica, es posible que otro cliente haya actualizado la entrada mientras tanto. Sin embargo, los servidores pueden implementar extensiones que admitan esto.

Operaciones extendidas

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 significativas. Otros ejemplos incluyen Cancelar y Modificar contraseña.

InicioTLS

La operación StartTLS establece la seguridad de la capa de transporte (el descendiente de SSL) en la conexión. Puede proporcionar confidencialidad de datos (para proteger los datos 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 de TLS, el servidor envía su certificado X.509 para probar su identidad. El cliente también podrá enviar un certificado para acreditar su identidad. Después de hacerlo, el cliente puede usar SASL/EXTERNAL. Al usar SASL/EXTERNAL, el cliente solicita que el servidor derive su identidad de las credenciales proporcionadas en un nivel inferior (como TLS). Aunque técnicamente el servidor puede usar cualquier información de identidad establecida en cualquier nivel inferior, normalmente el servidor usará la información de identidad establecida por TLS.

Los servidores a menudo también admiten el protocolo no estándar "LDAPS" ("LDAP seguro", comúnmente conocido como "LDAP sobre SSL") en un puerto separado, por defecto 636. LDAPS difiere de LDAP de dos maneras: 1) al conectarse, el el cliente y el servidor establecen TLS antes de que se transfiera cualquier mensaje LDAP (sin una operación StartTLS) y 2) la conexión LDAPS debe cerrarse al cerrar TLS.

Algunas bibliotecas cliente "LDAPS" solo cifran la comunicación; no comparan el nombre de host con el nombre en el certificado proporcionado.

Abandonar

La operación de abandono solicita que el servidor cancele una operación nombrada por un ID de mensaje. El servidor no necesita cumplir con la solicitud. Ni Abandon ni una operación abandonada con éxito envían una respuesta. Una operación extendida Cancelar similar envía respuestas, pero no todas las implementaciones lo admiten.

Desatar

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 contrario de la operación Bind.

Los clientes pueden cancelar una sesión simplemente cerrando la conexión, pero deben usar Desvincular. Unbind permite que el servidor cierre correctamente la conexión y libere recursos que, de lo contrario, mantendría durante algún tiempo hasta que descubriera que el cliente había abandonado la conexión. También le indica al servidor que cancele las operaciones que se pueden cancelar y que no envíe respuestas para las operaciones que no se pueden cancelar.

Esquema URI

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

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

La mayoría de los componentes que se describen 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 utiliza como base de búsqueda.
• atributos es una lista de atributos separados por comas para recuperar.
• scope especifica el ámbito de búsqueda y puede ser "base" (el valor predeterminado), "one" o "sub".
• filter es un filtro de búsqueda. Por ejemplo, (objectClass=*)como se define en RFC 4515.
• Las extensiones son extensiones del formato URL de LDAP.

Por ejemplo, " ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" se refiere 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 (tenga en cuenta la barra triple, que omite el host, y el signo de interrogación doble, que omite los atributos). Como en otras URL, los caracteres especiales deben estar codificados en porcentaje.

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

Esquema

El contenido de las entradas en un subárbol se rige 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 contener el servidor. Tiene una serie de elementos, que incluyen:

• Sintaxis de atributos: proporciona información sobre el tipo de información que se puede almacenar en un atributo.
• Reglas de coincidencia: brindan información sobre cómo realizar comparaciones con valores de atributos.
• Usos de la regla de coincidencia: indique qué tipos de atributos se pueden usar junto con una regla de coincidencia en particular.
• Tipos de atributos: defina un identificador de objeto (OID) y un conjunto de nombres que pueden hacer referencia a un atributo dado, y asocia ese atributo con una sintaxis y un conjunto de reglas de coincidencia.
• Clases de objetos: defina colecciones de atributos con nombre y clasifíquelas en conjuntos de atributos obligatorios y opcionales.
• Formularios de nombre: defina reglas para el conjunto de atributos que deben incluirse en el RDN para una entrada.
• Reglas de contenido: defina restricciones adicionales sobre las clases de objetos y los atributos que se pueden usar junto con una entrada.
• Regla de estructura: defina las 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 las cuales se pueden usar los atributos 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 conocer 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 contenga clases con nombre definidas en el esquema. La definición de esquema de las clases de una entrada define qué tipo de objeto puede representar la entrada, por ejemplo, una persona, organización o dominio. Las definiciones de clase de objeto 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 "superior" y "persona". La pertenencia a la clase "persona" requeriría que la entrada contuviera los atributos "sn" y "cn", y permitiría que la entrada también contuviera "contraseña de usuario", "número de teléfono" y otros atributos. Dado que las entradas pueden tener múltiples valores de ObjectClasses, cada entrada tiene un conjunto de conjuntos de atributos obligatorios y opcionales formados a partir de la unión de las clases de objetos que representa. Las clases de objetos se pueden heredar y una sola entrada puede tener varios valores de clases de objetos que definen los atributos disponibles y necesarios de la entrada en sí. Un paralelo al esquema de una clase de objeto es una definición de clase y una instancia en la programación orientada a objetos, que representa la clase de objeto LDAP y la entrada LDAP,

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

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

Variaciones

Gran parte de la operación del servidor se deja en manos del implementador o administrador. En consecuencia, los servidores pueden configurarse para soportar una amplia variedad de escenarios.

Por ejemplo, no se especifica el almacenamiento de datos en el servidor: el servidor puede usar 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 varios 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 vinculación. Los atributos pueden tener opciones que pueden modificar su semántica.

Otros modelos de datos

A medida que LDAP ganó impulso, los proveedores lo proporcionaron como un protocolo de acceso a otros servicios. La implementación luego refunde los datos para imitar el modelo LDAP/X.500, pero varía cuán de cerca se sigue este modelo. Por ejemplo, hay software para acceder a bases de datos SQL a través de LDAP, aunque LDAP no se presta fácilmente para esto. Los servidores X.500 también pueden admitir LDAP.

De manera similar, los datos que antes estaban en otros tipos de almacenes de datos a veces se mueven a directorios LDAP. Por ejemplo, la información de usuarios y grupos de Unix se puede almacenar en LDAP y acceder a ella a través de módulos PAM y NSS. LDAP a menudo es utilizado por otros servicios para la autenticación y/o autorización (qué acciones puede hacer un usuario dado ya autenticado en qué servicio). Por ejemplo, en Active Directory, Kerberos se usa en el paso de autenticación, mientras que LDAP se usa en el paso de autorización.

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

Uso

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

Una organización con el dominio ejemplo.org puede usar el DN de 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.

Principalmente, se utilizan dos estilos comunes de denominación tanto en X.500 [2008] como en LDAPv3. Estos están documentados en las especificaciones de la UIT y los RFC de 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íses podría ser l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR, o en los EE. UU.: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.