Protocolo ligero de acceso a directorios

AddEdit

la operación Agregar inserta una nueva entrada en la base de datos del servidor de directorios. Si el nombre distinguido en la solicitud add ya existe en el directorio, entonces el servidor no agregará una entrada duplicada, sino que establecerá el código de resultado en el resultado add en decimal 68, «entryAlreadyExists».

  • Los servidores compatibles con LDAP nunca desreferenciarán el nombre distintivo transmitido en la solicitud add al intentar localizar la entrada, es decir, los nombres distintivos nunca se des-aliadean.,
  • Los servidores compatibles con LDAP se asegurarán de que el nombre distinguido y todos los atributos cumplan con los estándares de nomenclatura.
  • La entrada a añadir no debe existir, y el superior inmediato debe existir.

En el ejemplo anterior, uid=user,ou=people,dc=example,dc=com no debe existir, y ou=people,dc=example,dc=com debe existir.

Bind (authenticate)Edit

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 plano, por lo que las conexiones que utilizan Simple o SASL Plain deberían cifrarse utilizando Transport Layer Security (TLS). El servidor normalmente comprueba la contraseña con el atributo userPassword en la entrada con nombre. Enlace anónimo (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.,

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 enlace al código para un error de protocolo. Normalmente los clientes deben usar LDAPv3, que es el default en el protocolo pero no siempre en las bibliotecas LDAP.

BIND tuvo que ser la primera operación en una sesión en LDAPv2, pero no se requiere a partir de LDAPv3., En LDAPv3, cada solicitud de enlace exitosa cambia el estado de autenticación de la sesión y cada solicitud de enlace no exitosa restablece el estado de autenticación de la sesión.

DeleteEdit

para eliminar una entrada, un cliente LDAP transmite una solicitud de eliminación correctamente formada al servidor.,

  • una solicitud de eliminación debe contener el nombre distintivo de la entrada que se va a eliminar
  • Los controles de solicitud también se pueden adjuntar 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 subordinados) se pueden eliminar mediante una solicitud de eliminación., Algunos servidores de apoyo operacional atributo hasSubordinates cuyo valor indica si una entrada tiene cualquier subordinado entradas, y algunos servidores de apoyo operacional atributo numSubordinates indica el número de entradas subordinado a la entrada que contiene el numSubordinates atributo.
  • Algunos servidores admiten el control de solicitud de eliminación de subárbol que permite eliminar el DN y todos los objetos subordinados al DN, sujetos a controles de acceso., Las solicitudes de eliminación están sujetas a controles de acceso, es decir, si se permitirá que una conexión con un estado de autenticación determinado elimine una entrada determinada se rige por mecanismos de control de acceso específicos del servidor.

buscar y CompareEdit

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

baseObject el nombre de la entrada del objeto base (o posiblemente la raíz) relativa a la cual se va a realizar la búsqueda. alcance qué elementos debajo del baseObject buscar., Esto puede serBaseObject(buscar solo la entrada con nombre, normalmente se usa para leer una entrada),singleLevel(entradas inmediatamente debajo del DN base), owholeSubtree(todo el subárbol que comienza en el DN base). criterios de filtro a utilizar en la selección de elementos dentro del ámbito., Por ejemplo, el filtro(&(objectClass=person)(|(givenName=John)(mail=john*)))seleccionará» persons»(elementos de objectClassperson) donde las reglas coincidentes paragivenNameymaildeterminan si los valores de esos atributos coinciden con la aserción del filtro. Tenga en cuenta que un error 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 orden determinan la coincidencia, las comparaciones y las relaciones de valor relativo., Si los filtros de ejemplo eran necesarios para coincidir con el caso del valor del atributo, se debe usar un filtro de coincidencia extensible, por ejemplo,(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))derefAliases si y cómo seguir las entradas de alias (entradas que se refieren a otras entradas), atributos que atributos devolver en las entradas de resultados. sizeLimit, timeLimit número máximo de entradas a devolver y tiempo máximo para permitir que se ejecute la búsqueda. Estos valores, sin embargo, no pueden anular ninguna restricción que el servidor Coloque en el límite de tamaño y el límite de tiempo. typesOnly devuelve solo tipos de atributos, No valores de atributos.,

el servidor devuelve las entradas coincidentes y potencialmente referencias de continuación. Estos pueden ser devueltos en cualquier orden. El resultado final incluirá el código de resultado.

La operación de comparación 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.

ModifyEdit

los clientes LDAP utilizan la operación MODIFY para solicitar que el servidor LDAP realice cambios en las entradas existentes. Los intentos de modificar entradas que no existen fallará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 distintivo (DN) de la entrada, y una secuencia de cambios. Cada cambio en la secuencia debe ser uno de:

  • add (agregar un nuevo valor, que no debe existir ya en el atributo)
  • delete (Eliminar un valor existente)
  • replace (reemplazar un valor existente con un nuevo valor)

LDIF ejemplo de agregar un valor a un atributo:

dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added-

para reemplazar el valor de un atributo existente, utilice la palabra clave reemplazar., 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 delete y el designador changetype modify. Si el atributo tiene varios valores, el cliente debe especificar el valor del atributo a eliminar.

también hay una extensión Modify-Increment que permite que un valor de atributo incrementable se incremente en una cantidad especificada., El siguiente ejemplo usando LDIF incrementa el número de empleo en 5:

dn: uid=user.0,ou=people,dc=example,dc=comchangetype: modifyincrement: employeeNumberemployeeNumber: 5-

Cuando los servidores LDAP están en una topología replicada, los clientes LDAP deben considerar usar el control de lectura posterior para verificar las actualizaciones en lugar de una búsqueda después de una actualización. El control post-lectura está diseñado para que las aplicaciones no necesiten emitir una solicitud de búsqueda después de una actualización – es una mala forma recuperar una entrada con el único propósito de comprobar que una actualización funcionó debido al modelo de consistencia 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 clientes LDAP y servidores.

Modify DNEdit

Modify DN (move / rename entry) toma el nuevo RDN (Relative Distinguished Name), opcionalmente el nuevo DN del Padre, y un indicador que indica si se deben eliminar los valores de la entrada que coincidan 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 que admitan esto.

Extended operationsEdit

La operación extendida es una operación LDAP genérica que puede definir nuevas operaciones que no formaban parte de la especificación del protocolo original. StartTLS es una de las extensiones más significativas., Otros ejemplos incluyen Cancelar y modificar la contraseña.

StartTLSEdit

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 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 probar su identidad. El cliente también puede enviar un certificado que acredite su identidad. Después de hacerlo, el cliente puede usar SASL / EXTERNAL., Mediante el uso de SASL / EXTERNAL, 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 a menudo soportan el protocolo no estándar «LDAPS» («LDAP seguro», comúnmente conocido como «LDAP sobre SSL») en un puerto separado, por defecto 636., LDAPS difiere de LDAP en dos formas: 1) al conectarse, el cliente y el servidor establecen TLS antes de transferir cualquier mensaje LDAP (sin una operación StartTLS) Y2) la conexión LDAPS debe cerrarse al cerrar TLS.

algunas bibliotecas cliente «LDAPS» solo cifran la comunicación; no cotejan el nombre del host con el nombre del certificado suministrado.

AbandonEdit

La operación Abandon solicita que el servidor cancele una operación nombrada por un ID de mensaje. El servidor no necesita cumplir con la solicitud. Ni el abandono ni una operación abandonada con éxito envían una respuesta., Una operación extendida de cancelación similar envía respuestas, pero no todas las implementaciones admiten esto.

UnbindEdit

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 contrario de la operación Bind.

Los clientes pueden abortar una sesión simplemente cerrando la conexión, pero deben usar Unbind. Unbind permite al servidor cerrar correctamente la conexión 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 pueden cancelar y que no envíe respuestas para las operaciones que no se pueden cancelar.

Share

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *