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) Standard Track llamadas 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:
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 :
/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]
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]
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.La operación de búsqueda se utiliza tanto para buscar como para leer entradas. Sus parámetros son:
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).(&(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 la coincidencia, 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*)))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:
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 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 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 Cancel similar 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.
(objectClass=*)como se define en RFC 4515.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á gobernado 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:
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 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 "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 ofrecido como 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.