El Protocolo ligero de acceso a directorios (LDAP) es originalmente unprotocolopara consultar y modificar servicios dedirectorio(es una evolución del protocolo DAP). Este protocolo se basa enTCP / IP. Sin embargo, se ha convertido en unestándarpara los sistemas de directorio, que incluye unmodelo dedatos, un modelo de nomenclatura, un modelo funcional basado en LDAP, un modelo de seguridad y un modelo de replicación. Es una estructura de árbol en la que cada uno de los nodos está formado por atributos asociados a sus valores. LDAP es menos complejo que el modelo X.500 decretado porITU-T.
La denominación de los elementos que constituyen el árbol (raíz, ramas, hojas) a menudo refleja el modelo político, geográfico u organizativo de la estructura representada. La tendencia actual es utilizar nombres DNS para los elementos básicos del directorio (raíz y primeras ramas, componentes del dominio o dc =… ). Las ramas más profundas del directorio pueden representar unidades organizativas o grupos ( unidades organizativas u ou =… ), personas ( nombre común o cn =… o incluso identificador de usuario uid =… ). El ensamblaje de todos los componentes (desde el más preciso al más general) de un nombre forma su nombre distinguido , el siguiente ejemplo presenta dos:
La última versión del protocolo es LDAPv3. Esta versión está definida por el IETF en varios RFC que comienzan con RFC 4510.
LDAP se diseñó originalmente para un acceso ligero a directorios X.500. Estos directorios se consultaban tradicionalmente mediante el protocolo de acceso a directorios (DAP) X.500, que requería el uso de la pila de protocolos del modelo OSI . El uso de una puerta de enlace LDAP / DAP permitió el acceso a un servidor DAP mientras estaba en una red TCP / IP. Este modelo de directorio se deriva de DIXIE y del Servicio de asistencia de directorio .
La aparición de directorios LDAP nativos siguió rápidamente, al igual que la aparición de servidores compatibles con DAP y LDAP. Los directorios se hicieron populares en las empresas porque ya no era necesario implementar una red OSI. Hoy en día, los protocolos de acceso a directorios X.500 (incluido DAP) se pueden utilizar directamente sobre TCP / IP.
El protocolo fue creado por Tim Howes de la Universidad de Michigan , Steve Kille de ISODE y Wengyik Yeong de Performance Systems International en 1993 . Los desarrollos que siguieron fueron dirigidos por el Grupo de Trabajo de Ingeniería de Internet (IETF).
Inicialmente, el protocolo se llamaba Protocolo ligero de exploración de directorios ( LDBP ), porque solo permitía búsquedas de datos. Se le cambió el nombre al agregar nuevas posibilidades (adición, modificación).
LDAP ha influido en varios protocolos de Internet, incluidas las últimas versiones de X.500 : XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML) y Service Location Protocol (SLP).
Un cliente inicia una sesión LDAP conectándose al puerto TCP 389 del servidor. Luego, el cliente envía solicitudes de operación al servidor. El servidor devuelve las respuestas. Con algunas excepciones, el cliente no necesita esperar una respuesta del servidor para enviar nuevas solicitudes, y el servidor puede enviar sus respuestas en cualquier orden.
Una vez establecida la conexión al servidor, las operaciones típicas son:
Además, el servidor puede enviar Notificaciones no solicitadas no solicitadas que no son respuestas a solicitudes, por ejemplo, antes de cerrar una conexión inactiva.
Un método para proteger las comunicaciones LDAP es utilizar un túnel TLS / SSL . Cuando se utilizan URL, este uso se traduce por el nombre del protocolo ldaps para reemplazar a ldap . El puerto TCP estándar para ldaps es 636.
El protocolo LDAP emplea la notación ASN.1 y los mensajes se codifican con el formato binario BER . Sin embargo, utiliza representación textual para varios atributos y tipos de ASN.1.
Los directorios LDAP siguen el modelo X.500 y su arquitectura multiinquilino nativa :
El hecho de que los atributos puedan tener varios valores es una gran diferencia entre los directorios LDAP y RDBMS . Además, si un atributo no tiene valor, simplemente falta en la entrada.
Cada entrada tiene un identificador único, el nombre distinguido (DN). Se compone de su nombre distinguido relativo (RDN) seguido del DN de su padre. Es una definición recursiva. Podemos hacer la analogía con otra estructura de árbol, los sistemas de archivos; el DN es la ruta absoluta y el RDN la ruta relativa a un directorio. Normalmente, el RDN de una entrada que representa a una persona es el atributo uid :
dc=org | dc=example / \ ou=people ou=groups | uid=totoEl RDN de foo es rdn: uid = foo , su DN es dn: uid = foo, ou = people, dc = example, dc = org .
Una entrada puede tener el aspecto de la siguiente representación cuando se formatea como LDIF :
dn: cn=John Doe, dc=example, dc=org cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: [email protected] manager: cn=Barbara Doe, dc=exemple, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: topdn es el nombre de la entrada, no es un atributo de la entrada. "cn = John Doe" es el RDN de la entrada y "dc = example, dc = org" es el DN de su padre. Las otras líneas muestran los atributos de la entrada. Los nombres de los atributos son a veces abreviaturas de los más comunes: "cn" para nombre común , "dc" para componente de dominio , "sn" para apellido .
Un servidor contiene un subárbol cuya raíz es una entrada específica y todos sus elementos secundarios, por ejemplo: "dc = ejemplo, dc = org". Los servidores también pueden contener referencias a otros servidores, por lo que acceder a una entrada ("ou = un servicio, dc = ejemplo, dc = org") puede devolver una referencia a otro servidor que contiene el subárbol deseado. El cliente puede entonces contactar (automáticamente o no) con el otro servidor. Algunos servidores admiten el encadenamiento, lo que permite que el servidor consulte a otros servidores para enviar la información deseada al cliente.
Los resultados devueltos por el servidor no están ordenados, ya sea por las entradas, por los atributos de las entradas o por los valores de los atributos.
El cliente le da a cada solicitud un ID de mensaje , el servidor responde a la solicitud con el mismo identificador. La respuesta incluye un código de resultado numérico que indica el estado de la solicitud (éxito, fracaso,…). La respuesta también incluye cualquier dato que pueda resultar de una búsqueda. También incluye un código de identificación.
La operación de vinculación autentica al cliente dentro del servidor. El enlace simple envía el DN del usuario y su contraseña en claro, por lo que la conexión debe estar asegurada por TLS . El servidor verifica la contraseña comparándola con el atributo userPassword (generalmente) de la entrada correspondiente. El valor del atributo que contiene la contraseña comienza con el nombre entre llaves del algoritmo utilizado para codificar la contraseña (por ejemplo: userPassword: {md5} aGZh5…).
El enlace anónimo , es decir, sin proporcionar un nombre de usuario o contraseña, pone la conexión en un estado anónimo. Por lo tanto, el cliente ya no podrá realizar ciertas operaciones en todo o parte del directorio, según las ACL implementadas.
El enlace SASL permite el uso de otros mecanismos de autenticación: Kerberos , certificado de cliente, etc.
El paso de vinculación también permite que el cliente y el servidor acuerden qué versión del protocolo utilizar. Normalmente se utiliza la versión 3. Incluso es posible que el servidor se niegue a comunicarse con los clientes en un protocolo inferior al suyo.
La operación StartTLS establece una conexión segura entre el cliente y el servidor mediante la técnica TLS , heredada de SSL . Esta seguridad opera en dos puntos: confidencialidad (un tercero no puede entender el intercambio) e integridad de los datos (los datos son validados por una firma). Durante la negociación de TLS, el servidor envía su certificado X.509 al cliente para probar su identidad. El cliente puede responder enviando su certificado, pero la identificación del cliente es opcional. Por lo general, es posible configurar clientes y servidores para saber si los certificados son opcionales o esenciales.
Los servidores generalmente admiten el protocolo no estándar “LDAPS” ( LDAP sobre SSL ). Este protocolo usa el puerto 636 a diferencia de TLS, que usa el puerto 389 (lo mismo que LDAP no seguro). El protocolo LDAPS se diferencia de LDAP de dos formas:
La operación de búsqueda se utiliza tanto para buscar como para recuperar entradas. Sus parámetros son:
El servidor devuelve las entradas que coinciden, seguidas del código de retorno del comando (código de retorno).
La operación de comparación toma un DN, un nombre de atributo y un valor de atributo como argumento, luego verifica si la entrada correspondiente realmente contiene un atributo con este valor.
Nota : No hay operación de tipo Lectura . La operación de búsqueda se utiliza para acceder directamente a una entrada. En este caso, el parámetro baseObject es el DN de la entrada que se va a leer y el parámetro de alcance se usa con el valor base .
Las operaciones de actualización Agregar , Eliminar , Modificar toman como argumento el DN de la entrada a actualizar.
La modificación necesita además de la lista de atributos a modificar así como la modificación a realizar: eliminación del atributo o de ciertos valores del atributo (los atributos pueden ser multivalor), adición de un valor, reemplazo un valor de.
La adición de una entrada también puede contener una lista de atributos y valores para asociar con la entrada.
La modificación de DN (mover / renombrar) toma como argumento el RDN de la entrada y, opcionalmente, el DN del nuevo padre, así como un marcador que indica si se borra o no el antiguo RDN. El soporte para cambiar el nombre de un subárbol completo depende del servidor.
Una operación de actualización es atómica, es decir, otras operaciones verán la nueva entrada o la anterior. Sin embargo, LDAP no define un principio de transacción, lo que permite que varios clientes modifiquen una entrada al mismo tiempo. Sin embargo, los servidores pueden usar extensiones para admitirlo.
Las operaciones extendidas son operaciones genéricas que le permiten definir nuevas operaciones. Por ejemplo, las operaciones Cancelar , Modificar contraseña y Iniciar TLS .
AbandonoLa operación Abandonar envía una solicitud al servidor para indicarle que cancele una operación proporcionándole su identificador. El servidor no tiene la obligación de cumplir con la solicitud. Desafortunadamente, la operación de Abandono , así como el abandono real de una operación, no devuelve una respuesta. Por lo tanto, la operación de cancelación extendida se ha definido para devolver una respuesta, pero no todos los servidores la admiten.
La operación Unbind aborta cualquier operación actual y cierra la conexión. No hay respuesta. Su nombre tiene razones históricas, no es la operación contraria a Bind .
Los clientes pueden finalizar una sesión cerrando la conexión, pero es más limpio usar Desvincular . Esto permite al servidor diferenciar los errores de red de los clientes descorteses.
Existe un formato LDAP URI , pero no todos los clientes lo admiten. Los servidores lo utilizan para informar a los clientes sobre referencias a otros servidores. El formato es el siguiente:
ldap://hôte:port/DN?attributs?profondeur?filtre?extensioncon :
Como en todos los URI, los caracteres especiales deben escaparse siguiendo el algoritmo proporcionado por RFC 3986 .
También puede encontrar URI que utilizan el patrón no estándar " ldaps ".
Por ejemplo :
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comdevuelve todos los atributos de la entrada "John Doe",
ldap:///dc=example,dc=com??sub?(givenName=John)busca la entrada con el nombre "John" en el directorio de la raíz.
El contenido de las entradas en un directorio LDAP se rige por esquemas .
Los esquemas definen los tipos de atributos que pueden contener las entradas del directorio. La definición de un atributo incluye la sintaxis, la mayoría de los atributos no binarios en LDAPv3 utilizan la sintaxis de cadena UTF-8 . Por ejemplo, el atributo de correo puede contener " [email protected] ", el atributo jpegPhoto puede contener una fotografía en formato JPEG binario , el atributo de miembro puede contener el DN de una entrada de directorio.
La definición de un atributo también indica si el atributo es monovalorizado o multivalor, según qué reglas se realizarán las búsquedas / comparaciones (sensibles al caso o no, búsqueda de subcadenas o no).
Los esquemas definen clases de objetos. Cada entrada de directorio debe tener al menos un valor para el atributo objectClass , que es una clase de objeto definida en los esquemas. Por lo general, el atributo objectClass tiene varios valores y contiene la clase superior , así como varias otras clases.
Al igual que en la programación orientada a objetos , las clases te permiten describir un objeto al asociarle atributos. Las clases LDAP representan personas, organizaciones ... El hecho de que una entrada pertenezca a una clase (por tanto, que el atributo objectClass contenga el nombre de la clase) permite utilizar los atributos de esta clase. Algunos atributos son obligatorios y otros son opcionales. Por ejemplo, si la entrada usa la clase person , debe tener un valor para los atributos sn y cn y, opcionalmente, puede tener un valor para los atributos userPassword y telephoneNumber . Dado que las entradas suelen tener varias clases, diferenciar entre atributos obligatorios y opcionales puede resultar bastante complejo.
Los elementos de un esquema tienen un nombre y un identificador único llamado identificador de objeto ( OID ).
Muchos servidores exponen esquemas de directorio como entradas LDAP accesibles desde el esquema DN cn =. Los administradores pueden definir su propio esquema además de los esquemas estándar.
Algunas operaciones posibles quedan a discreción del desarrollador o administrador. Por ejemplo, el protocolo no especifica el almacenamiento de datos. El servidor puede utilizar archivos planos o un RDBMS, o simplemente ser una puerta de enlace a otro servidor. Los controles de acceso ( ACL ) tampoco están estandarizados, aunque está surgiendo un uso común.
LDAP es un protocolo extensible, que hace que aparezcan nuevas operaciones en algunos servidores y no en otros. Por ejemplo, ordenar los resultados.
El principal interés de LDAP es la estandarización de la autenticación. Es muy fácil programar un módulo de autenticación usando LDAP desde un lenguaje que tenga una API LDAP. Es la operación Bind la que permite autenticar a un usuario. Cada vez más aplicaciones web tienen un módulo de autenticación que admite LDAP.
En los sistemas GNU / Linux recientes, hay una adopción creciente de una base de datos que usa LDAP en lugar de passwd y archivos planos de sombra . Los módulos PAM y NSS pueden acceder a los datos .
LDAP se define mediante una serie de solicitudes de comentarios :
Las siguientes RFC detallan las mejores prácticas a adoptar con respecto a LDAP:
La siguiente es una lista que contiene RFC que definen extensiones LDAPv3:
LDAPv2 ha sido definido por las siguientes RFC:
LDAPv2 se ha movido al estado histórico por la siguiente RFC:
Otras RFC: