OpoSERGASLDAP es el protocolo estándar para consultar y modificar un servicio de directorio, y en el examen de Técnico de Sistemas TI se pregunta sobre todo por tres cosas: cómo se escribe un nombre distinguido (DN), cómo se acota una búsqueda y cómo se protege la autenticación. Aparece en el tema 34 de la parte específica de técnico/a especialista de sistemas y tecnologías de la información (C1) (mensajería, correo, directorio y LDAP), y es el protocolo con el que se consultan directorios como Active Directory.
El DN: del elemento más concreto al más general
Cada entrada del directorio se identifica con un DN (Distinguished Name), formado por una secuencia de RDN (Relative Distinguished Name). El RFC 4514 fija la forma de escribirlo como texto: los RDN se separan con comas y se empieza por el último elemento de la secuencia, es decir, por el más específico, avanzando hacia la raíz. Un RDN con varios atributos los une con el signo +.
Ejemplos que recoge el propio RFC: UID=jsmith,DC=example,DC=net y OU=Sales+CN=J. Smith,DC=example,DC=net (este segundo tiene un RDN multivaluado).
Operación de búsqueda: base y ámbito
Una búsqueda LDAP parte de un objeto base y de un ámbito (scope) que el RFC 4511 define con tres valores:
| Ámbito | Valor | Qué recorre |
|---|---|---|
| baseObject | 0 | Solo la propia entrada base |
| singleLevel | 1 | Las entradas inmediatamente subordinadas a la base |
| wholeSubtree | 2 | La base y todo el subárbol que cuelga de ella |
Puertos que conviene saber
El RFC 4511 recomienda que los servidores LDAP sobre TCP escuchen en el puerto asignado por la IANA, el 389, aunque pueden usar otro. La documentación de Microsoft para controladores de dominio de Active Directory añade 636/TCP para LDAP con SSL, y 3268/TCP y 3269/TCP para el catálogo global (sin y con SSL, respectivamente).
Autenticación: bind simple y StartTLS
El RFC 4513 describe tres mecanismos del bind simple: anónimo, sin autenticar (se envía un DN pero con contraseña de longitud cero) y nombre/contraseña. Hay reglas muy preguntables:
- Una implementación que admita cualquier mecanismo distinto del anónimo debe soportar el de nombre/contraseña y ser capaz de protegerlo con TLS mediante la operación StartTLS.
- Se recomienda no permitir el uso de nombre/contraseña por defecto si no hay un servicio de seguridad adecuado de los datos.
- El bind «sin autenticar» no autentica de verdad: el DN solo sirve para trazas. Los servidores deberían rechazarlo por defecto con el código unwillingToPerform, y los clientes no deberían aceptar una contraseña vacía en la pantalla de acceso.
Ejemplo práctico (ilustrativo)
Un administrador quiere listar los usuarios del departamento de informática de un hospital ficticio. Define como base ou=Informatica,dc=hospital,dc=example y elige el ámbito singleLevel para ver solo las entradas directamente bajo esa unidad; con wholeSubtree obtendría también las de las subunidades. Antes de enviar ninguna credencial, el cliente negocia StartTLS por el puerto 389, para que el bind con contraseña viaje cifrado.
Truco para recordarlo
Regla mnemotécnica propia, no oficial: el DN se lee «de la hoja a la raíz», como una dirección postal que empieza por el piso y acaba en el país. Para el ámbito, 0-1-2: Base, Un nivel, Subárbol.
Practica con dos preguntas tipo test
1. En la forma textual de un DN según el RFC 4514, ¿por dónde se empieza a escribir?
- Por el elemento más general, la raíz del árbol.
- Por el último RDN de la secuencia, el más específico.
- Por el atributo DC, siempre.
- Por el orden alfabético de los atributos.
Solución: B. La conversión empieza por el último elemento de la secuencia y avanza hacia atrás, separando con comas. La A describe el orden inverso, la C no es una regla y la D tampoco existe en el RFC.
2. ¿Qué ámbito de búsqueda LDAP examina la entrada base y todo su subárbol?
- baseObject
- singleLevel
- wholeSubtree
- neverDerefAliases
Solución: C. wholeSubtree (valor 2) abarca la base y todo lo que cuelga de ella. baseObject solo mira la propia entrada, singleLevel solo los hijos inmediatos y neverDerefAliases no es un ámbito, sino una opción sobre cómo tratar los alias.
Referencias
- RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol, apartados 4.5.1 y 5.2: rfc-editor.org/rfc/rfc4511.
- RFC 4513, LDAP: Authentication Methods and Security Mechanisms, apartados 2, 3 y 5.1: rfc-editor.org/rfc/rfc4513.
- RFC 4514, LDAP: String Representation of Distinguished Names, apartados 2.1, 2.2 y 4 (ejemplos): rfc-editor.org/rfc/rfc4514.
- Microsoft Learn, Configure firewall for AD domain and trusts: learn.microsoft.com.
- Programa de la parte específica de técnico/a especialista de sistemas y tecnologías de la información (C1), tema 34, según la numeración del DOG núm. 126, de 5 de julio de 2021, al que remite el anexo II del DOG núm. 141/2025.
Sigue practicando
Relaciona LDAP con los conceptos clave de Active Directory, repasa DNS, DHCP y correo electrónico y los puertos TCP y UDP más preguntados.
Crea tu cuenta gratis y practica los temas de Técnico de Sistemas TI.