Protocolo ligero de acceso a directorios

El Protocolo ligero de acceso a directorios (LDAP) 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 un Protocolo de Internet (IP) red. 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), utilizando 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

Empresas de telecomunicaciones' la comprensión de los requisitos del directorio estaba bien desarrollada después de unos 70 años de producir y administrar 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.

Los servicios de directorio X.500 se accedían tradicionalmente 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 Ligero porque no era tan intensivo en la red como su predecesor DAP y, por lo tanto, se implementaba 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 – autenticar y especificar la versión de protocolo LDAP
• Buscar – buscar y/o recuperar entradas del directorio
• Comparar – probar si una entrada llamada contiene un valor de atributo dado
• Añadir una nueva entrada
• Suprimir una entrada
• Modificar la entrada
• Modificar el Nombre Distinguido (DN) – mover o renombrar una entrada
• Abandonar – abortar una solicitud anterior
• Operación extendida – operación genérica utilizada para definir otras operaciones
• Unbind – cerrar la conexión (no el inverso de Bind)

Además, el servidor puede enviar "Notificaciones no solicitadas" que no son respuestas a ninguna solicitud, p. antes de que se agote el tiempo de espera de la 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 consiste en un conjunto de atributos.
• Un atributo tiene un nombre (un tipo o descripción) y uno o más valores. Los atributos se definen en un schema (véase infra).
• Cada entrada tiene un identificador único: su Nombre distinguido (DN). Esto consiste en su Distinguido relativo Nombre (RDN), construido a partir de algunos atributos en la entrada, seguido por el DN de la entrada padre. Piense en el DN como la ruta completa del archivo y el RDN como su nombre de archivo relativo en su carpeta padre (por ejemplo, si /foo/bar/myfile.txt eran el DN, entonces myfile.txt serí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 forma fiable y sin ambigüedades, se puede proporcionar un UUID en el conjunto de atributos operativos de la entrada.

Una entrada puede tener este aspecto cuando se representa en formato de intercambio de datos LDAP (LDIF), un formato de texto sin formato (a diferencia de un protocolo binario como el propio LDAP):

 dn: cn=John Doe,dc=example,dc=com
cn: John Doe
dado Nombre: John
sn: Doe
teléfonoNúmero: +1 888 555 6789
teléfonoNúmero: +1 888 555 1232
correo: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
categoría: organización Persona
objetoClass: persona
objetoClass: top

"dn" es el nombre distinguido de la entrada; no es ni un atributo ni una parte de la entrada. "cn=Juan Pérez" es el RDN (nombre distinguido relativo) de la entrada y "dc=example,dc=com" es el DN de la entrada principal, donde "dc" indica 'Componente de dominio'. Las otras líneas muestran los atributos de la entrada. Los nombres de 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" por apellido

Un servidor contiene un subárbol a partir de una entrada específica, p. "dc=ejemplo,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 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 encadenamiento, lo que significa que el servidor se comunica 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 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

Añadir

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, sino que establecerá el código de resultado en el resultado de la adición en decimal 68, "la entrada ya existe".

• Los servidores compatibles con LDAP nunca derreferirán el nombre distinguido transmitido en la solicitud de adición al intentar localizar la entrada, es decir, nombres distinguidos nunca son de-aliased.
• Los servidores compatibles con LDAP garantizarán que el nombre distinguido y todos los atributos se ajusten a los estándares de nombres.
• La entrada a añadir no debe existir, y el superior inmediato debe existir.

dn: uid=user,ou= people,dc=example,dc=com
cambio: añadir
objetoClass:top
objectClass:person
uid: usuario
sn: apellido
cn: nombre común
userPassword: contraseña

En el ejemplo anterior, uid=user,ou=people,dc=example,dc=com no debe existir, y ou=people,dc=example,dc=com< /código> debe existir.

Enlazar (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 está configurado como 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 debe cifrarse mediante Transport Layer Security (TLS). El servidor normalmente compara la contraseña con 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 (Autenticación simple y capa de seguridad) BIND proporciona servicios de autenticación a través de un amplia gama de mecanismos, p. 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 soporta, 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 utilizar 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 la 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

Eliminar

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 debe suprimirse
• Los controles de solicitud también pueden adjuntarse a la solicitud de supresión
• Los servidores no dereferencias alias cuando procesan una solicitud de eliminación
• Sólo las entradas de hoja (entries sin subordinados) pueden ser eliminadas por una solicitud de eliminación. Algunos servidores soportan un atributo operativo hasSubordinates cuyo valor indica si una entrada tiene entradas subordinadas, y algunos servidores apoyan un atributo operacional numSubordinates indicando el número de entradas subordinadas a la entrada que contiene numSubordinates atributo.
• Algunos servidores soportan el control de solicitud de eliminación del subárbol permitiendo la eliminación del DN y todos los objetos subordinados al DN, sujetos a controles de acceso. Las solicitudes de supresión están sujetas a controles de acceso, es decir, si se permitirá una conexión con un estado de autenticación determinado eliminar una entrada determinada se rige por mecanismos de control de acceso específicos para servidores.

Busca y compara

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

baseObjeto

El nombre de la entrada de objeto base (o posiblemente la raíz) relativa a la cual se debe realizar la búsqueda.

alcance

Qué elementos debajo de la base Objeto a buscar. Esto puede ser BaseObject (búsqueda sólo la entrada nombrada, típicamente usada para leer una entrada), singleLevel (entries immediately below the base DN), or wholeSubtree (todo el subárbol que comienza en la base DN).

filtro

Criterios para usar en la selección de elementos dentro del alcance. Por ejemplo, el filtro (&(objectClass=person)(|(givenName=John)(mail=john*))) seleccionará "personas" (elementos de objetoClass person) donde las reglas de juego para givenName y mail determinar si los valores para esos atributos coinciden con la afirmación del filtro. Tenga en cuenta que un error común es que los datos de LDAP son sensibles a los casos, mientras que de hecho las reglas y reglas de orden determinan las relaciones de coincidencia, comparaciones y valor relativo. Si los filtros de ejemplo eran necesarios para igualar el caso del valor de atributo, un filtro de partido extensible debe ser utilizado, por ejemplo, (&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

derefAliases

Ya sea y cómo seguir las entradas de alias (entros que se refieren a otras entradas),

atributos

Lo que atribuye a volver en las entradas de resultados.

tamañoLimit, tiempoLimit

Número máximo de entradas para volver, y tiempo máximo para permitir que la búsqueda funcione. Estos valores, sin embargo, no pueden anular ninguna restricción que el servidor coloca en el límite de tamaño y límite de tiempo.

tipos Sólo

Devuelve los tipos de atributos solamente, no los valores de atributo.

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:

• añadir (add un nuevo valor, que no debe existir ya en el atributo)
• eliminar (deletar un valor existente)
• reemplazar (sustituir un valor existente con un nuevo valor)

Ejemplo de LDIF de agregar un valor a un atributo:

dn: dc=example,dc=com
cambio: modificación
añadir: cn
cn: el nuevo valor a medida
-

Para reemplazar el valor de un atributo existente, use la palabra clave replace. Si el atributo tiene varios valores, el cliente debe especificar el valor del atributo para actualizar.

Para eliminar un atributo de una entrada, use la palabra clave delete y 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 que un valor de atributo incrementable se incremente en una cantidad específica. El siguiente ejemplo que usa LDIF incrementa employeeNumber en 5:

dn: uid=user.0,ou= people,dc=example,dc=com
cambio: modificación
aumento: empleadoNúmero
empleadoNúmero: 5
-

Cuando los servidores LDAP están en una topología replicada, los clientes LDAP deben considerar usar el control posterior a la lectura para verificar las actualizaciones en lugar de buscar después de 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 (Relative Distinguished Name), opcionalmente el nuevo DN principal y una marca que indica si se deben eliminar los valores en la entrada que coinciden con el RDN antiguo. 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.

Iniciar TLS

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 también suelen admitir el "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 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.

Algunos "LDAPS" las bibliotecas cliente 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.

Desvincular

La operación Unbind abandona cualquier operación pendiente y cierra la conexión. No tiene respuesta. El nombre tiene un origen histórico y no es lo opuesto a 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 de 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:port/DN?attributes?scope?filter?extensions

La mayoría de los componentes que se describen a continuación son opcionales.

• anfitrión es la dirección FQDN o IP del servidor LDAP para buscar.
• puerto es el puerto de red (puerto predeterminado 389) del servidor LDAP.
• DN es el nombre distinguido para usar como base de búsqueda.
• atributos es una lista separada de los atributos a recuperar.
• alcance especifica el alcance de búsqueda y puede ser "base" (el predeterminado), "uno" o "sub".
• filtro es un filtro de búsqueda. Por ejemplo, (objectClass=*) como se define en RFC 4515.
• extensiones son extensiones al 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 ?(nombre dado=Juan)" busca la entrada en el servidor predeterminado (observe la triple barra, omitiendo el host, y el doble signo de interrogación, omitiendo los atributos). Como en otras URL, los caracteres especiales deben estar codificados en porcentaje.

Existe un esquema de URI ldaps 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 esquema estándar ldap.

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:

• Attribute Syntaxes—Proporcione información sobre el tipo de información que se puede almacenar en un atributo.
• Reglas de juego: Provee información sobre cómo hacer comparaciones con valores de atributo.
• Regla de coincidencia Usos—Indicar qué tipos de atributos se pueden utilizar junto con una regla de coincidencia particular.
• Tipos de atributo: Define un identificador de objeto (OID) y un conjunto de nombres que pueden referirse a un atributo dado, y asociados que atribuyen con una sintaxis y conjunto de reglas de juego.
• Clases de objetos: Definir colecciones de atributos nombradas y clasificarlas en conjuntos de atributos requeridos 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 atributos que puedan utilizarse conjuntamente con una entrada.
• Regla de estructura: Defina reglas que gobiernan los tipos de entradas subordinadas que una entrada determinada puede tener.

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 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, p. 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 representa a una persona podría pertenecer a las clases "top" y "persona". Membresía en la "persona" la clase requeriría que la entrada contuviera el "sn" y "cn" y permitir que la entrada también contenga "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, respectivamente.

Los servidores de directorio pueden publicar el esquema de directorio que controla una entrada en un DN base proporcionado 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 proporcionados. 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. Usuarios' las contraseñas 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, p. 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.

Del mismo modo, 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 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. El formulario 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=Localidad, ou=Alguna unidad organizativa, o=Alguna organización, c=FR, o en EE. UU.: cn=Nombre común, l=Localidad, ou=Alguna unidad organizativa, o=Alguna organización, st=CA, c=US.