Hispanopedia Wiki
Articulo de referencia

Protocolo ligero de acceso a directorios

El Protocolo ligero de acceso a directorios ( LDAP / ˈ ɛ l d æ p / ) es un protocolo de Internet para acceder a servicios de información de directorios que actúan de acuerdo con...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo ligero de acceso a directorios ( LDAP / ˈ ɛ l d æ p / ) es un protocolo de Internet para acceder a servicios de información de directorios que actúan de acuerdo con los modelos de datos y servicios X.500 ." [ 1 ] Una descripción completa del protocolo se puede encontrar en la "Hoja de ruta de la especificación técnica del Protocolo ligero de acceso a directorios (LDAP)" RFC 4510 y sus referencias. 

Los servicios de directorio desempeñan un papel importante en el desarrollo de aplicaciones de intranet e Internet, ya que permiten compartir información sobre usuarios, sistemas, redes, servicios y aplicaciones en toda la red. [ 2 ] Por 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.

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

LDAP es un subconjunto más simple ( ligero ) de los estándares de la serie X.500 , en particular del Protocolo de Acceso a Directorios X.511 . [ 4 ] [ 5 ] Debido a esta relación, a veces se denomina a LDAP X.500 Lite . [ 6 ]

Los componentes principales de LDAP son:

  • Protocolo ( RFC 4511 ): Un protocolo de aplicación que se ejecuta sobre una red de Protocolo de Internet (IP) y se utiliza para comunicarse con un servicio de directorio. 
  • Modelos de información de directorio ( RFC 4512 ): una especificación para sistemas que implementan servicios de directorio, es decir, "una colección de sistemas abiertos que cooperan para proporcionar servicios de directorio" [ 7 ]. 
  • Esquema para aplicaciones de usuario ( RFC 4519 ): Un esquema de datos estándar y extensible para la información que se utilizará en un servicio de directorio: una "especificación de tipos de atributos y clases de objetos destinados a ser utilizados por LDAP" [ 8 ]. 

Historia

Tras unos 70 años produciendo y gestionando directorios telefónicos, las empresas de telecomunicaciones tenían un profundo conocimiento de los requisitos de los directorios. Estas empresas introdujeron el concepto de servicios de directorio en la tecnología de la información y las redes informáticas , y su contribución culminó en la especificación integral X.500 , [ 9 ] 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 mediante el protocolo de acceso a directorios X.511 (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 sencilla (y ahora ampliamente utilizada) . Este modelo de acceso a directorios se basó en los protocolos DIXIE y del Servicio de Asistencia a Directorios (DAS) .

El protocolo fue creado originalmente [ 10 ] 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 [ 11 ] 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 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 Autenticación y Seguridad Simple y alineó mejor el protocolo con la edición de 1993 de X.500. El desarrollo posterior de las especificaciones de LDAPv3 y de numerosas extensiones que agregan características a LDAPv3 ha sido a través del IETF .

En las primeras etapas de desarrollo de LDAP, se le conocía como Protocolo ligero de exploración de directorios ( LDBP ). Su nombre cambió al ampliarse el alcance del protocolo más allá de la exploración y búsqueda de directorios, para incluir funciones de actualización. Se le denominó "ligero" porque requería menos ancho de banda que su predecesor, DAP, y, por lo tanto, su implementación en Internet era más sencilla debido a su consumo relativamente moderado de ancho de banda.

LDAP ha influido en protocolos de Internet posteriores, incluidas 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), por defecto en el puerto TCP y UDP 389, o en el puerto 636 para LDAPS (LDAP sobre TLS/SSL, véase más abajo). [ 12 ] A continuación, el cliente envía una solicitud de operación al servidor, y este responde. Salvo 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 Básicas de Codificación (BER).

El cliente puede solicitar las siguientes operaciones:

  • StartTLS : utilice la extensión LDAPv3 Transport Layer Security (TLS) para una conexión segura.
  • Enlace: autenticar y especificar la versión del protocolo LDAP.
  • Buscar: buscar y/o recuperar entradas del directorio.
  • Comparar: comprueba si una entrada con nombre contiene un valor de atributo determinado.
  • Agregar una nueva entrada
  • Eliminar una entrada
  • Modificar una entrada
  • Modificar nombre distintivo (DN): mover o cambiar el nombre de una entrada.
  • Abandonar – cancelar una solicitud anterior
  • Operación extendida: operación genérica utilizada para definir otras operaciones.
  • Desvincular: cerrar la conexión (no es lo contrario de Vincular).

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 espera de la conexión.

Un método alternativo común para proteger la comunicación LDAP es mediante un túnel SSL . El puerto predeterminado para LDAP sobre SSL es el 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 se ha dejado de utilizar junto con LDAPv2, que se retiró oficialmente en 2003. [ 13 ]

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 del atributo ) y uno o más valores. Los atributos se definen en un esquema (véase más abajo).
  • Cada entrada tiene un identificador único: su Nombre Distinguido (DN). Este consta de su Nombre Distinguido Relativo (RDN), construido a partir de uno o más atributos de la entrada, seguido del DN de la entrada principal. Considere el DN como la ruta completa del archivo y el RDN como su nombre de archivo relativo en la carpeta principal (por ejemplo, si /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 las entradas de forma fiable e inequívoca, 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 plano (a diferencia de un protocolo binario como el propio LDAP):

dn : cn = John Doe , dc = example , dc = com cn : John Doe givenName : John sn : Doe telephoneNumber : +1 888 555 6789 telephoneNumber : +1 888 555 1232 mail : john@example.com manager : cn=Barbara Doe,dc=example,dc=com objectClass : inetOrgPerson objectClass : organizationalPerson objectClass : person objectClass : top

" 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 en 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. [ 14 ]

Un servidor contiene un subárbol que comienza en una entrada específica, por ejemplo, " dc=example,dc=com" y sus elementos secundarios. 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 reenvío o continuación a un servidor que contenga esa parte del árbol de directorios. El cliente puede entonces contactar con el otro servidor. Algunos servidores también admiten el encadenamiento , lo que significa que el servidor contacta 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 en 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, un atributo como un conjunto de valores, y los conjuntos no tienen por qué estar ordenados.

Operaciones

Agregar

La operación ADD inserta una nueva entrada en la base de datos del servidor de directorio. [ 15 ] Si el nombre distinguido en la solicitud de adición ya existe en el directorio, 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". [ 16 ]

  • Los servidores compatibles con LDAP nunca desreferenciarán el nombre distinguido transmitido en la solicitud de adición al intentar localizar la entrada; es decir, los nombres distinguidos nunca se desaliasan.
  • Los servidores compatibles con LDAP garantizarán que el nombre distintivo y todos los atributos cumplan con los estándares de nomenclatura.
  • La entrada que se va a añadir no debe existir, y el superior inmediato debe existir.
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.

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 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 plano , por lo que las conexiones que utilicen Simple o SASL PLAIN deben cifrarse mediante Transport Layer Security (TLS). El servidor suele comprobar la contraseña comparándola con el userPassword atributo de la entrada con nombre. 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. [ 17 ]

BIND también establece la versión del protocolo LDAP enviando un número de versión como un entero. Si el cliente solicita una versión que el servidor no admite, este debe establecer el código de resultado en la respuesta de BIND al código de error del protocolo. Normalmente, los clientes deberían usar LDAPv3, que es la versión predeterminada del protocolo, aunque no siempre en las bibliotecas LDAP.

En LDAPv2, la operación BIND debía ser la primera de una sesión, pero ya no es necesaria 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 lo restablece.

Borrar

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

  • Una solicitud de eliminación debe contener el nombre distintivo de la entrada que se va a eliminar.
  • Los controles de solicitud también pueden adjuntarse a la solicitud de eliminación.
  • Los servidores no desreferencian los alias al procesar una solicitud de eliminación.
  • Solo las entradas hoja (entradas sin subordinadas) pueden ser eliminadas mediante una solicitud de eliminación. Algunos servidores admiten un atributo operacional hasSubordinatescuyo valor indica si una entrada tiene entradas subordinadas, y algunos servidores admiten un atributo operacional numSubordinates[ 19 ] que indica el número de entradas subordinadas a la entrada que contiene el numSubordinatesatributo.
  • Algunos servidores admiten el control de solicitudes de eliminación de subárboles, lo que permite eliminar el DN y todos los objetos subordinados a este, 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 tendrá permiso para eliminar una entrada específica depende de los mecanismos de control de acceso propios del servidor.

Buscar y comparar

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

objeto base
El nombre de la entrada del objeto base (o posiblemente la raíz) con respecto a la cual se realizará la búsqueda.
alcance
¿Qué elementos debajo del objeto base se deben buscar? Esto puede ser BaseObject(buscar solo la entrada nombrada, que normalmente se usa para leer una sola entrada), singleLevel(entradas inmediatamente debajo del DN base) o wholeSubtree(todo el subárbol que comienza en el DN base).
filtrar
Criterios para usar en la selección de elementos dentro del ámbito. Por ejemplo, el filtro (&(objectClass=person)(|(givenName=John)(mail=john*)))seleccionará "personas" (elementos de objectClass person) donde las reglas de coincidencia para givenNamey maildeterminen si los valores de esos atributos coinciden con la aserción del filtro. Tenga en cuenta que una idea errónea 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 ordenación determinan la coincidencia, las comparaciones y las relaciones de valores relativos. Si los filtros de ejemplo requirieran que coincidieran con las mayúsculas y minúsculas del valor del atributo, se debe usar un filtro de coincidencia extensible , por ejemplo,(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
derefAliases
Si se deben seguir las entradas de alias (entradas que hacen referencia a otras entradas) y cómo hacerlo.
atributos
Qué atributos devolver en las entradas de resultados.
límite de tamaño, límite de tiempo
Número máximo de resultados a devolver y tiempo máximo permitido para que se ejecute la búsqueda. Sin embargo, estos valores no pueden anular las restricciones que el servidor imponga en cuanto al límite de tamaño y de tiempo.
Solo tipos
Devuelve únicamente los tipos de atributos, no los valores de los atributos.

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

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

Modificar

La operación MODIFY es utilizada por los clientes LDAP para solicitar al servidor LDAP que realice cambios en las entradas existentes. [ 20 ] Los intentos de modificar entradas que no existen fallarán. Las solicitudes MODIFY están sujetas a los controles de acceso implementados por el servidor.

La operación MODIFICAR 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 los siguientes:

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

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

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

Para reemplazar el valor de un atributo existente, utilice la replacepalabra clave. Si el atributo es multivalor, el cliente debe especificar el valor del atributo que desea actualizar.

Para eliminar un atributo de una entrada, utilice la palabra clave deletey el identificador changetype modify. Si el atributo es multivalor, el cliente debe especificar el valor del atributo que desea eliminar.

También existe una extensión Modify-Increment [ 21 ] que permite incrementar un valor de atributo incrementable en una cantidad específica. El siguiente ejemplo, utilizando LDIF, incrementa employeeNumberen 5:

dn : uid = user.0 , ou = people , dc = example , dc = com changetype : modify increment : employeeNumber employeeNumber : 5 -

Cuando los servidores LDAP se encuentran en una topología replicada, los clientes LDAP deberían considerar usar el control de post-lectura para verificar las actualizaciones en lugar de realizar una búsqueda después de una actualización. [ 22 ] 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; no es recomendable recuperar una entrada con el único propósito de verificar que una actualización se haya realizado debido al modelo de consistencia eventual de la replicación . Un cliente LDAP no debe asumir que se conecta al mismo servidor de directorio para cada solicitud, ya que los arquitectos pueden haber colocado balanceadores de carga o proxies LDAP, o ambos, entre los clientes y servidores LDAP.

Modificar DN

La función Modificar DN (mover/renombrar entrada) toma el nuevo RDN (Nombre Distinguido Relativo), opcionalmente el nuevo DN del directorio padre, y un indicador que especifica 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 directorio completos.

Una operación de actualización es atómica: otras operaciones verán la entrada nueva o la antigua. Por otro lado, LDAP no define transacciones de múltiples operaciones: si se lee una entrada y luego se modifica, otro cliente podría haberla actualizado mientras tanto. Sin embargo, los servidores pueden implementar extensiones [ 23 ] que admiten esta funcionalidad.

Operaciones extendidas

La Operación Extendida es una operación LDAP genérica que permite definir nuevas operaciones que no formaban parte de la especificación original del protocolo. StartTLS es una de las extensiones más importantes. Otros ejemplos incluyen Cancelar y Modificar Contraseña.

StartTLS

La operación StartTLS establece la Seguridad de la Capa de Transporte (descendiente de SSL ) en la conexión. Proporciona confidencialidad de datos (para protegerlos de la observación de terceros) y/o protección de la integridad de los datos (que los protege de manipulaciones). 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 la suya. Posteriormente, el cliente puede utilizar SASL /EXTERNAL. Mediante SASL/EXTERNAL, el cliente solicita al servidor que derive su identidad a partir de las credenciales proporcionadas en un nivel inferior (como TLS). Si bien técnicamente el servidor puede utilizar cualquier información de identidad establecida en cualquier nivel inferior, normalmente 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 el 636. LDAPS se diferencia de LDAP en dos aspectos: 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 finalizar la conexión TLS.

Algunas bibliotecas cliente "LDAPS" solo cifran la comunicación; no verifican el nombre del host con el nombre del certificado proporcionado. [ 24 ]

Abandonar

La operación Abandon solicita al servidor que aborte una operación identificada por un ID de mensaje. El servidor no está obligado a atender la solicitud. Ni Abandon ni una operación abandonada con éxito envían una respuesta. Una operación extendida similar, Cancel, sí envía respuestas, pero no todas las implementaciones la 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 opuesto a la operación Bind. [ 25 ]

Los clientes pueden abortar una sesión simplemente cerrando la conexión, pero deberían usar Unbind. [ 26 ] Unbind permite al servidor cerrar la conexión de forma segura y liberar recursos que de otro modo mantendría durante un tiempo hasta detectar que el cliente ha 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. [ 27 ]

esquema URI

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 continuaciones (véase RFC 4516):

ldap://host:puerto/DN?atributos?ámbito?filtro?extensiones

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

  • El host es el nombre de dominio completo (FQDN) o la dirección IP del servidor LDAP que se va a buscar.
  • El puerto es el puerto de red (puerto predeterminado 389) del servidor LDAP.
  • DN es el nombre distintivo que se utilizará como base de búsqueda.
  • attributes es una lista de atributos separados por comas que se van a recuperar.
  • scope especifica el ámbito de búsqueda y puede ser "base" (el valor predeterminado), "one" o "sub".
  • El filtro es un filtro de búsqueda. Por ejemplo, (objectClass=*)como se define en la RFC 4515.
  • Las extensiones son extensiones del formato de URL 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 (nótese 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 porcentaje .

Existe un ldapsesquema 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 el servidor puede almacenar. Tiene varios elementos, entre ellos:

  • Sintaxis de atributos: proporciona información sobre el tipo de información que se puede almacenar en un atributo.
  • Reglas de coincidencia: Proporcionan información sobre cómo realizar comparaciones con los valores de los atributos.
  • Usos de las reglas de coincidencia: indique qué tipos de atributos se pueden utilizar junto con una regla de coincidencia específica.
  • Tipos de atributos: definen un identificador de objeto (OID) y un conjunto de nombres que pueden referirse a un atributo determinado, y asocian ese atributo con una sintaxis y un conjunto de reglas de coincidencia.
  • Clases de objetos: definen colecciones de atributos con nombre y las clasifican en conjuntos de atributos obligatorios y opcionales.
  • Formularios de nombres: defina las reglas para el conjunto de atributos que deben incluirse en el RDN de una entrada.
  • Reglas de contenido: definen restricciones adicionales sobre las clases de objetos y los atributos que se pueden usar junto con una entrada.
  • Regla de estructura: define 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 sobre 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 apropiada.

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 de las clases de una entrada en el esquema determina qué tipo de objeto puede representar, por ejemplo, una persona, una organización o un dominio. Las definiciones de las clases de objetos también definen la lista de atributos que deben contener valores y la lista de atributos que pueden contenerlos.

Por ejemplo, una entrada que representa 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 también contuviera "userPassword", "telephoneNumber" y otros atributos. Dado que las entradas pueden tener múltiples valores de ObjectClasses, cada entrada tiene un conjunto complejo de atributos opcionales y obligatorios formados por la unión de las clases de objeto que representa. Las ObjectClasses pueden heredarse, y una sola entrada puede tener múltiples valores de ObjectClasses que definen los atributos disponibles y obligatorios de la propia entrada. Un equivalente al esquema de una objectClass es la definición de una clase y una instancia en la programación orientada a objetos , que representan, respectivamente, una objectClass LDAP y una entrada LDAP.

Los servidores de directorio pueden publicar el esquema de directorio que controla una entrada en un DN base dado por el atributo operacional subschemaSubentry de la entrada. (Un atributo operacional describe el funcionamiento del directorio, no la información del usuario, y solo se devuelve en 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 .

Vulnerabilidades de seguridad

Inyección LDAP

La inyección LDAP es un ataque de seguridad informática similar a la inyección SQL que puede ocurrir cuando una aplicación que implementa LDAP no sanitiza correctamente la entrada del usuario. [ 28 ]

Como ejemplo, consideremos una consulta de búsqueda LDAP que permite al usuario buscar personas por su nombre, el cnatributo. Un usuario malintencionado podría reemplazar un nombre válido con el *carácter, que coincide con cualquier objeto que tenga dicho cnatributo. Si la aplicación es vulnerable a este ataque, podría mostrar atributos que el usuario que realiza la búsqueda no está autorizado a ver. [ 29 ]

Las vulnerabilidades de inyección LDAP se mitigan mediante el escape de variables. El escape se logra con dos funciones de codificación distintas : una para nombres distinguidos y otra para cadenas de búsqueda , ya que cada una permite caracteres especiales diferentes. Algunos frameworks web incluyen el escape integrado. [ 30 ]

Ataques de intermediario

Al igual que otras partes de TCP/IP, LDAP se creó originalmente sin cifrado. Esto lo hace vulnerable a ataques de intermediario (man-in-the-middle) , en los que los atacantes interceptan las credenciales durante el proceso de enlace. Este ataque se puede mitigar exigiendo LDAPS o StartTLS durante cada enlace que involucre credenciales. [ 31 ]

Variaciones

Gran parte del funcionamiento del servidor queda a criterio del implementador o administrador. Por consiguiente, los servidores pueden configurarse para dar soporte a una amplia variedad de escenarios.

Por ejemplo, el almacenamiento de datos en el servidor no está especificado: puede usar archivos planos, bases de datos o simplemente servir como puerta de enlace a otro servidor. El control de acceso no está estandarizado, aunque existen modelos de uso común. Las contraseñas de los usuarios pueden almacenarse en sus perfiles o en otro lugar. El servidor puede rechazar realizar operaciones cuando lo desee e imponer diversos límites.

La mayoría de los componentes de LDAP son extensibles. Por ejemplo: se pueden definir nuevas operaciones. Los controles pueden modificar las 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 modifican su semántica.

Otros modelos de datos

A medida que LDAP ha ganado popularidad, los proveedores lo han ofrecido como protocolo de acceso a otros servicios. La implementación luego reformula los datos para imitar el modelo LDAP/X.500, pero el grado de fidelidad a 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. [ 32 ] Los servidores X.500 también pueden ser compatibles con LDAP.

De forma similar, los datos almacenados previamente en otros tipos de bases 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 acceder a ella mediante los módulos PAM y NSS . Otros servicios suelen utilizar LDAP para la autenticación y/o autorización (qué acciones puede realizar un usuario ya autenticado en cada servicio). Por ejemplo, en Active Directory, Kerberos se utiliza en la autenticación, mientras que LDAP se utiliza en la autorización.

Un ejemplo de este modelo de datos es el esquema GLUE, [ 33 ] 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 Grid y obtener más información sobre su estructura y estado.

Uso

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

Una organización con el dominio example.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 nomenclatura tanto en X.500 [2008] como en LDAPv3. Estos están documentados en las especificaciones de la UIT y en los RFC de la IETF. El formato original toma el objeto de nivel superior como el 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 nomenclatura basada en el 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.

Véase también

Referencias

  1. ↑ Zeilenga, Kurt (junio de 2006). Protocolo ligero de acceso a directorios (LDAP): Hoja de ruta de especificaciones técnicas (Informe). Grupo de trabajo de ingeniería de Internet.
  2. ↑ "Servicios de directorio LDAP" . Oracle.com . Consultado el 4 de abril de 2014 .
  3. ↑ "Introducción a los servicios de directorio OpenLDAP" . OpenLDAP . Consultado el 1 de febrero de 2016 .
  4. ↑ J. Sermersheim (junio de 2006). Protocolo ligero de acceso a directorios (LDAP): El protocolo . Grupo de trabajo de redes. doi : 10.17487/RFC4511 . RFC 4511 .Estándar propuesto. Sustituye a los RFC 3771 , 2830 y 2251. Las operaciones principales del protocolo definidas en este documento pueden asignarse a un subconjunto del Servicio de Resumen de Directorio X.500 (1993) [X.511]. Sin embargo, no existe una correspondencia uno a uno entre las operaciones LDAP y las operaciones del Protocolo de Acceso a Directorio (DAP) X.500. 
  5. ↑ "¿Qué es la autenticación del protocolo ligero de acceso a directorios (LDAP)?" . Red Hat . 3 de junio de 2022.
  6. ↑ "LDAP - Protocolo ligero de acceso a directorios" . Webopedia.com. 4 de diciembre de 1996. Consultado el 5 de abril de 2014 .
  7. ↑ Zeilenga, Kurt (junio de 2006). Protocolo ligero de acceso a directorios (LDAP): modelos de información de directorios (informe). Grupo de trabajo de ingeniería de Internet.
  8. ↑ Sciberras, Anew (junio de 2006). Protocolo ligero de acceso a directorios (LDAP): esquema para aplicaciones de usuario (informe). Grupo de trabajo de ingeniería de Internet.
  9. ↑ La serie X.500 - Recomendación ITU-T X.500 a X.521
  10. ↑ Howes, Tim. "El protocolo ligero de acceso a directorios: X.500 Lite" (PDF) . Consultado el 26 de diciembre de 2012 .
  11. ↑ "Prehistoria de LDAP" . Asuntos Cibernéticos . 9 de abril de 2013. Consultado el 5 de octubre de 2014 .
  12. ↑ "Registro de nombres de servicio y números de puerto de protocolo de transporte" . IANA . Consultado el 24 de marzo de 2021 .
  13. ↑ RFC3494
  14. ↑ Este artículo se basa en material tomado de Lightweight+Directory+Access+Protocol en el Free On-line Dictionary of Computing antes del 1 de noviembre de 2008 e incorporado bajo los términos de "relicencia" de la GFDL , versión 1.3 o posterior.
  15. ↑ Agregar sección de RFC4511
  16. ↑ Códigos de resultado LDAP
  17. ↑ Mecanismos SASL en IANA
  18. ↑ RFC4511: solicitud de eliminación
  19. ↑ Borrador de Boreham (numSubordinados)
  20. ↑ Modificar la sección de RFC4511
  21. ↑ Zeilenga, K. Extensión de modificación-incremento de LDAP . IETF . doi : 10.17487/RFC4525 . RFC 4525 .
  22. ↑ Zeilenga, K. Controles de entrada de lectura del Protocolo ligero de acceso a directorios (LDAP) . IETF . doi : 10.17487/RFC4527 . RFC 4527 .
  23. ↑ Borrador de Internet Transacciones LDAP draft-zeilenga-ldap-txn-15.txt
  24. ↑ Alerta de seguridad de Shibboleth 20120227
  25. ↑ Herramientas.ietf.org
  26. ↑ Herramientas.ietf.org
  27. ↑ Herramientas.ietf.org
  28. ↑ "Descripción de la inyección LDAP" . OWASP . Fundación OWASP.
  29. ↑ Abdollahi, Ali (2025). Guía para principiantes sobre pruebas de penetración en aplicaciones web . Wiley. ISBN 9781394295609.
  30. ↑ Guía rápida para la prevención de inyecciones LDAP (Informe). Fundación OWASP.
  31. ↑ Johnson, Richard (2025). Arquitectura e implementación de LDAP: Referencia definitiva para desarrolladores e ingenieros . HiTeX Press.
  32. ↑ Openldap.org
  33. ↑ Foro de Open Grid  : Página principal del proyecto

Fuentes

Lecturas adicionales

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