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 para el proveedor, 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 ejemplo, 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, una guía telefónica 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) denominadas Solicitud de comentarios (RFC), que utilizan el lenguaje de descripción ASN.1 . La última especificación es la Versión 3, publicada como RFC 4511 [3] (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. [4]
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. [5]
La comprensión de las empresas de telecomunicaciones sobre los requisitos de los directorios estaba bien desarrollada después de unos 70 años de producir y gestionar 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 aportaciones culminaron en la completa especificación X.500 , [6] un conjunto de protocolos producidos por la Unión Internacional de Telecomunicaciones (UIT) en los años 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 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 al directorio 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 los auspicios del 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 IETF ha llevado a cabo un mayor desarrollo de las propias especificaciones LDAPv3 y de numerosas extensiones que añaden características a LDAPv3 .
En las primeras etapas de ingeniería de LDAP, se lo conocía como Protocolo ligero de navegación de directorios o LDBP . Se le cambió el nombre 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 Ligero porque no requería tanta 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 .
Un cliente inicia una sesión LDAP conectándose a un servidor LDAP, llamado 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, ver más abajo). [9] Luego, el cliente envía una solicitud de operación al servidor, y el 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 utilizar 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, entonces 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 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 = ejemplo , dc = com cn : John Doe Nombre dado : John sn : Doe Número de teléfono : +1 888 555 6789 Número de teléfono : +1 888 555 1232 correo : [email protected] gerente : cn=Barbara Doe,dc=ejemplo,dc=com clase de objeto : inetOrgPerson clase de objeto : persona organizacional clase de objeto : persona clase de objeto : arriba " dn" es el nombre completo de la entrada; no es un atributo ni 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" 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 del dominio, " mail" para la dirección de correo electrónico y " sn" para el apellido. [11]
Un servidor contiene un subárbol que comienza 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. El cliente puede entonces contactar con el otro servidor. Algunos servidores también admiten encadenamiento , lo que significa que el servidor contacta al otro servidor y devuelve los resultados al cliente.
LDAP rara vez define algún 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 no es necesario ordenar los conjuntos.
La operación ADD inserta una nueva entrada en la base de datos del servidor de directorio. [12] Si el nombre distintivo 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 el decimal 68, "entryAlreadyExists". [13]
dn : uid = usuario , ou = personas , dc = ejemplo , dc = com tipo de cambio : agregar clase de objeto : clase de objeto superior : 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.
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 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 cifrarse mediante Transport Layer Security (TLS). El servidor normalmente comprueba la contraseña con el userPasswordatributo de la entrada nombrada. BIND anónimo (con DN y contraseña vacíos) restablece la conexión al estado anónimo.
SASL (Capa de seguridad y autenticación simple) 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 número entero. Si el cliente solicita una versión que el servidor no admite, el servidor debe configurar el código de resultado en la respuesta BIND al código de un error de protocolo. Normalmente los clientes deberían usar 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 en una sesión en LDAPv2, pero no es necesario 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 el número de entradas subordinadas a la entrada que contiene el numSubordinatesatributo.La operación de búsqueda se utiliza para buscar y leer entradas. Sus parámetros son:
BaseObject(buscar solo la entrada con nombre, que 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 se encuentran las reglas de coincidencia givenNamey maildeterminará si los valores de esos atributos coinciden con la aserción del filtro. Tenga en cuenta que un error común es creer 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 los filtros de ejemplo fueran necesarios para coincidir con el caso 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 potencialmente referencias de continuación. Estos 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 fracasarán. Las solicitudes de MODIFICACIÓN están sujetas a controles de acceso implementados por el servidor.
La operación MODIFICAR requiere que se especifique el nombre completo (DN) de la entrada y una secuencia de cambios. Cada cambio en la secuencia debe ser uno de:
Ejemplo LDIF de cómo agregar un valor a un atributo:
dn : dc = ejemplo , dc = com tipo de cambio : modificar agregar : cn cn : el-nuevo-valor-cn-a-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 a 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 Modificar-Incrementar [18] que permite incrementar el valor de un atributo incrementable en una cantidad específica. El siguiente ejemplo que utiliza incrementos LDIF employeeNumberen 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 de lectura posterior para verificar las actualizaciones en lugar de una búsqueda después de una actualización. [19] 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 de mala educación recuperar una entrada con el único propósito de comprobar que una actualización funcionó debido al modelo de coherencia eventual de replicación . Un cliente LDAP no debe asumir 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 los clientes y servidores LDAP.
Modificar DN (mover/renombrar 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 entrada nueva o la anterior. Por otro lado, LDAP no define transacciones de múltiples operaciones: si lees una entrada y luego la modificas, es posible que otro cliente haya 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 necesaria ]
La operación StartTLS establece la seguridad de la capa de transporte (el 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 podrá enviar un certificado que acredite su identidad. Después de hacerlo, el cliente podrá utilizar SASL /EXTERNAL. Al utilizar SASL/EXTERNO, el cliente solicita que el servidor derive su identidad a partir 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, de forma predeterminada 636. LDAPS se diferencia de LDAP en dos formas: 1) al conectarse, el 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 cerrar TLS.
Algunas bibliotecas cliente "LDAPS" sólo cifran la comunicación; no verifican el nombre del host con el nombre en el certificado proporcionado. [21]
La operación Abandonar solicita que el servidor cancele una operación denominada por un ID de mensaje. El servidor no necesita cumplir con la solicitud. Ni Abandono 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.
La operación Desvincular 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 cancelar una sesión simplemente cerrando la conexión, pero deben usar Unbind. [23] Unbind permite al servidor cerrar elegantemente la conexión y liberar recursos que de otro modo conservarí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 pueden cancelar y que no envíe respuestas para las operaciones que no se pueden cancelar. [24]
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.
(objectClass=*)como se define en RFC 4515.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 (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 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.
El contenido de las entradas de 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 Directory Server define un conjunto de reglas que gobiernan los tipos de información que el servidor puede contener. Tiene una serie de 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 esos atributos pueden tener 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 del 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 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 "arriba" y "persona". La membresía en la clase "persona" requeriría que la entrada contenga los atributos "sn" y "cn", y permitiría 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 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 de ObjectClasses que definen los atributos disponibles y requeridos de la propia entrada. Un paralelo al esquema de una clase de objeto es una definición de clase y una instancia en programación orientada a objetos , que representan 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 dado 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 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 las organizaciones se denomina esquema de páginas blancas .
Gran parte de la operación del servidor queda en manos del implementador o administrador. En consecuencia, se pueden configurar servidores 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 entrada 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 podrá 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 vinculación. Los atributos pueden tener opciones que pueden modificar su semántica.
A medida que LDAP ha ganado impulso, los proveedores lo han proporcionado 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 para ello. [25] Los servidores X.500 también pueden admitir LDAP.
De manera similar, los datos que anteriormente se guardaban 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 se puede acceder a ella a través de módulos PAM y NSS . Otros servicios suelen utilizar LDAP para autenticación y/o autorización (qué acciones puede realizar un determinado usuario 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, [26] 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.
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 LDAP para que uno pueda encontrar un servidor que tenga un nombre distintivo (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 pasa a ser ldap://ldap.example.org/dc=example,dc=org.
Se utilizan principalmente 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 en los RFC del IETF. El formulario original toma el objeto de nivel superior como objeto de país, como por ejemplo 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 EE. UU.: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.