Servicios de directorio: dónde viven realmente las identidades

Adonde llegan todos los protocolos

Cuando entras a una aplicación de la empresa por la mañana, pasan muchas cosas que nunca ves. Una aserción SAML puede viajar hasta la aplicación diciendo quién eres. Un token de OAuth puede dejar que una app móvil lea tu calendario. Durante la noche, SCIM puede haber creado tu cuenta en una herramienta nueva, porque ayer RR. HH. registró que te sumaste a un proyecto. Protocolos distintos, trabajos distintos, y todos, tarde o temprano, leen o escriben en el mismo lugar: un directorio.

Este artículo abre el dominio de gestión de accesos y su primer módulo, sobre estándares, protocolos y servicios de directorio. La apuesta del módulo es simple. Antes de poder razonar sobre autenticación, federación o gobierno, hace falta hablar el idioma común de IAM, y ese idioma es un conjunto de protocolos apoyados en una sola cosa con la que todos hablan. El directorio responde la pregunta más básica de IAM: ¿quién es esta persona y a qué pertenece? Si eso está mal, cada protocolo que va encima hereda el error. Por eso el módulo empieza por la base.

Una forma útil de tener todo el módulo en la cabeza: el directorio es el sustantivo de IAM, el registro de quién existe, y los protocolos, SAML, OAuth, OIDC, SCIM, son los verbos, cómo viaja la información de identidad entre sistemas. Este artículo trata del sustantivo.

Qué es un servicio de directorio

Un servicio de directorio es una base de datos, pero no una de propósito general. Está hecho para un trabajo concreto: leer datos de identidad, una y otra vez, desde una jerarquía. Las aplicaciones le hacen las mismas preguntas miles de veces por segundo, si existe este usuario, cuál es su correo, en qué grupos está, y rara vez escriben en él. Ese desequilibrio define cómo se construyen los directorios. Priorizan las lecturas rápidas y la replicación por encima de las garantías transaccionales estrictas que le importan a una base de datos relacional.

La analogía de siempre es la guía telefónica. Está ordenada por región y después por nombre, está pensada para buscar y no para editar, y hay copias en todas partes. Un directorio es la misma idea aplicada a las identidades digitales: un árbol de entradas, cada una describe una cosa, una persona, un grupo, una impresora, una cuenta de servicio, con un conjunto de atributos, todo consultable con un protocolo estándar.

Tres cosas distinguen a un directorio de una base de datos común. Es jerárquico, un árbol y no tablas planas, lo que refleja cómo se piensan las organizaciones a sí mismas: empresa, área, persona. Se accede a él con un protocolo estándar, LDAP en el mundo clásico y APIs HTTP en la nube, así que cualquier aplicación puede leerlo de la misma forma. Y está replicado, con copias sincronizadas entre servidores, para que las consultas sean rápidas y locales y la caída de un servidor no se lleve consigo la identidad.

LDAP: el modelo de datos y el idioma

LDAP, el Lightweight Directory Access Protocol, es a la vez un protocolo para hablar con un directorio y un modelo para organizar sus datos. Es “liviano” en comparación con los estándares X.500 de los que viene, y es el idioma común de los directorios locales desde finales de los noventa.

El árbol: DIT, entradas y nombres distintivos

LDAP organiza los datos en un árbol de información del directorio (DIT). Cada nodo del árbol es una entrada, y cada entrada tiene un nombre distintivo (DN): su ruta completa y única, leída desde la entrada hasta la raíz.

flowchart TD
  accTitle: Un árbol de información de directorio LDAP
  accDescr: La raíz del árbol son los componentes de dominio dc=example,dc=com. Debajo de la raíz hay dos unidades organizativas, ou=People y ou=Groups. Bajo ou=People hay dos entradas de persona, cn=Sara López y cn=Daniel Ortiz. Bajo ou=Groups hay una entrada de grupo, cn=Engineering. El nombre distintivo de una entrada es la ruta desde esa entrada hasta la raíz.
  ROOT["dc=example,dc=com"] --> P["ou=People"]
  ROOT --> G["ou=Groups"]
  P --> S["cn=Sara López"]
  P --> D["cn=Daniel Ortiz"]
  G --> E["cn=Engineering"]

La raíz es la organización, escrita como componentes de dominio (dc=example,dc=com). Debajo están las unidades organizativas (ou=People, ou=Groups), que agrupan entradas relacionadas. Las hojas son los objetos en sí: la entrada de Sara López tiene el DN cn=Sara López,ou=People,dc=example,dc=com. Cada parte separada por comas es un nombre distintivo relativo que nombra un nivel, y el DN las une todas, igual que una ruta identifica un único archivo en un disco.

Atributos, objectClasses y esquema

Cada entrada guarda atributos, pares de nombre y valor como mail: sara@example.com, telephoneNumber: 4521 o memberOf: cn=Engineering,.... Qué atributos puede y debe tener una entrada lo definen sus objectClasses, y el conjunto completo de objectClasses y atributos permitidos es el esquema del directorio, estandarizado en la RFC 4519 y ampliado en cada implantación.

Una entrada de objectClass inetOrgPerson, por ejemplo, debe tener un apellido (sn) y un nombre común (cn), y puede tener mail, mobile, title y decenas más. El esquema es un contrato: es la razón por la que cualquier cliente LDAP puede leer cualquier directorio LDAP y saber que mail guarda una dirección de correo. Ampliarlo con atributos propios es potente pero difícil de deshacer, y por eso los equipos con experiencia tratan los cambios de esquema con el mismo cuidado que una migración de base de datos.

Qué se puede hacer con LDAP

El protocolo es un conjunto chico de operaciones, y conocerlas le quita mucho misterio a IAM. Bind autentica ante el directorio. Search, la que más trabaja, busca entradas que cumplan un filtro, como todas las personas bajo ou=People cuya área es Finanzas. Add, modify y delete son las escrituras, que usa el aprovisionamiento. Compare comprueba el valor de un atributo y unbind cierra la sesión.

Bind merece una mirada más atenta, porque es un mecanismo de autenticación por sí mismo. Cuando una aplicación heredada dice que “autentica contra LDAP”, lo que hace literalmente es intentar un bind en el directorio con el usuario y la contraseña que escribió la persona. Si el bind funciona, la contraseña era correcta. Esa fue la base original del inicio de sesión único dentro de las empresas, y todavía corre por debajo de una cantidad sorprendente de software corporativo.

Active Directory: el directorio que hace funcionar a la empresa

Si LDAP es el idioma, Active Directory (AD) es el sistema a través del cual casi todo el mundo corporativo lo ha hablado durante dos décadas. Microsoft lo lanzó en 2000, y es mucho más que un directorio LDAP. Es una plataforma de identidad y de gestión construida alrededor de uno, y sigue siendo la columna vertebral de la TI corporativa local.

Dominios, árboles y bosques

AD organiza el mundo con su propia jerarquía. Un dominio es el límite administrativo básico: usuarios, equipos y grupos bajo una política común, atendidos por controladores de dominio que guardan el directorio y gestionan los inicios de sesión. Un árbol es un conjunto de dominios que comparten un espacio de nombres continuo. Un bosque es el límite de seguridad superior, uno o varios árboles que confían entre sí y comparten un esquema y un catálogo global, un índice parcial de todo el bosque para buscar rápido entre dominios.

El bosque es la línea que más importa para la seguridad, porque es el verdadero límite de confianza. Todo lo que está dentro de un bosque confía en todo lo demás, y por eso “comprometer un dominio puede significar comprometer el bosque” es una frase que les quita el sueño a los administradores de AD.

Más que LDAP

AD reúne varios protocolos y servicios que lo convierten de un almacén de consultas en una plataforma de gestión. Kerberos se encarga de la autenticación, el protocolo basado en tickets que permite que un equipo unido al dominio demuestre quién es su usuario sin volver a enviar la contraseña; vuelve a aparecer en el artículo de tokens. Las directivas de grupo envían configuración y ajustes de seguridad a miles de equipos desde un solo lugar. La integración con DNS permite que los clientes encuentren los controladores de dominio. Y LDAP sigue ahí para leer y escribir en el directorio.

Ese paquete es justamente lo que hizo a AD tan dominante y tan difícil de abandonar. No solo guardaba identidades; gestionaba la flota. La mayoría de las empresas no reemplazan AD, más bien lo extienden hacia la nube.

Dónde está el directorio en el ciclo de IAM

Conviene ser preciso sobre el lugar del directorio en el ciclo operativo. Normalmente no es la fuente autoritativa original de la identidad. Esa suele ser el sistema de RR. HH., que sabe a quién se contrató. El directorio es la fuente de verdad en tiempo de ejecución: el lugar que consultan de verdad las aplicaciones cuando alguien inicia sesión.

El flujo es así. RR. HH. registra que una persona existe. El aprovisionamiento de altas, traslados y bajas crea y mantiene su entrada en el directorio. Las aplicaciones leen el directorio en cada inicio de sesión para autenticar a la persona y resolver sus grupos. El directorio es lo que convierte “RR. HH. dice que esta persona es analista de finanzas” en “este inicio de sesión funciona y esta persona puede abrir la aplicación de finanzas”.

En la práctica, la pertenencia a grupos del directorio es como se otorga y se quita casi todo el acceso: estás en cn=Finance-App-Users o no estás. Eso hace a los grupos muy poderosos y muy propensos a multiplicarse, y es donde vive de forma concreta la acumulación de privilegios. Un directorio con diez mil grupos que nadie sabe explicar es la señal más común de que un programa de IAM perdió el control de su propia base.

El paso a los directorios cloud

El mundo local de LDAP y Kerberos suponía que la gente estaba sentada frente a equipos unidos al dominio, en la red corporativa, llegando a servidores internos. Ese supuesto se rompió. Hoy se trabaja desde cualquier lugar y desde cualquier dispositivo, con aplicaciones SaaS que corren en infraestructura de otros. Esas aplicaciones no hablan LDAP ni Kerberos; hablan protocolos web. Así apareció una nueva generación de directorios.

Los directorios cloud, Microsoft Entra ID (antes Azure AD), Okta Universal Directory, el directorio de Google, guardan identidades de forma parecida a sus antecesores, pero las exponen con protocolos pensados para internet: SAML, OAuth, OIDC y SCIM, el resto de este módulo. Entra ID no es “Active Directory en la nube”, por mucho que su nombre anterior lo sugiriera. Las diferencias son de arquitectura. No es jerárquico: no hay DIT, ni unidades organizativas, ni DNs, solo un tenant plano organizado en grupos y unidades administrativas. Está pensado primero como API y no como LDAP: no haces bind ni search, llamas a una API REST, Microsoft Graph, por HTTPS. Y no tiene dominios, árboles, bosques ni directivas de grupo, porque no gestiona flotas de Windows unidas al dominio. Su trabajo es llevar la identidad a aplicaciones cloud y SaaS a través de la web abierta.

Otros directorios que vale la pena conocer

AD y Entra ID dominan, pero no son las únicas opciones, y conocer las demás es parte de hablar el idioma con soltura.

El patrón es que las opciones de código abierto mantienen vivo el modelo clásico de LDAP y Kerberos en entornos con mucho Unix, mientras que las plataformas cloud atienden a organizaciones que nunca construyeron un directorio local y quieren la identidad como servicio. No hay un directorio correcto, solo el que encaja con tu mezcla de plataformas, tu tamaño y si lo piensas sobre todo como fuente o como intermediario, una distinción que las secciones siguientes afinan.

Identidad híbrida: vivir en los dos mundos

Casi ninguna empresa grande es solo local o solo cloud. Funcionan con identidad híbrida: Active Directory local para los equipos unidos al dominio y las aplicaciones más viejas, sincronizado con un directorio cloud para el SaaS. Un motor de sincronización copia identidades y atributos de AD a Entra ID, así que cada persona tiene una sola identidad que funciona en los dos. Microsoft lo ha llamado de varias formas que conviene reconocer: Azure AD Connect, el servidor de sincronización original y más pesado, hoy un nombre antiguo; Entra Connect Sync, el nombre actual de ese servidor completo; y Entra Cloud Sync, un agente más liviano gestionado desde la nube para escenarios más simples y cada vez más la opción por defecto en implantaciones nuevas.

flowchart LR
  accTitle: Sincronización de identidad híbrida
  accDescr: El sistema de RR. HH. alimenta el Active Directory local, que autentica los equipos unidos al dominio y las aplicaciones más viejas con LDAP y Kerberos. Un motor de sincronización, Entra Connect, proyecta identidades y atributos del AD local en el directorio cloud, Entra ID. Después, el directorio cloud gestiona el acceso a las aplicaciones SaaS con SAML, OIDC y SCIM.
  HR[Sistema de RR. HH.] --> AD[(Active Directory<br/>local)]
  AD -->|LDAP / Kerberos| LEGACY[Equipos unidos al dominio<br/>y apps más viejas]
  AD -->|sync: Entra Connect| CLOUD[(Directorio cloud<br/>Entra ID)]
  CLOUD -->|SAML / OIDC| SAAS[Apps SaaS]
  CLOUD -->|SCIM| SAAS

En el terreno vas a encontrar esta forma híbrida mucho más a menudo que un directorio limpio y solo cloud. También explica por qué importa el resto del módulo: todo el trabajo del directorio cloud es hablar los protocolos que permiten que las identidades de tu directorio entren en aplicaciones que no controlas.

Fuente autoritativa o intermediario de identidad

Un directorio puede cumplir dos papeles bastante distintos, y confundirlos provoca errores de diseño reales. Puede ser una fuente autoritativa, el sistema dueño de las identidades, donde se crean y se mantienen. O puede ser un intermediario de identidad (broker), un sistema que se sitúa entre muchas aplicaciones y una o varias fuentes y gestiona la autenticación en su nombre, sin ser necesariamente dueño de las identidades.

El Active Directory clásico es casi siempre una fuente: las identidades nacen y viven ahí. Un proveedor de identidad cloud moderno como Okta o Entra ID suele cumplir los dos papeles. Mantiene algunas identidades directamente e intermedia otras. Como intermediario, federa hacia abajo las aplicaciones en un único inicio de sesión, y federa hacia arriba con otras fuentes: tu AD local, el proveedor de identidad de un socio o los inicios de sesión sociales de consumidores. La persona entra una vez en el intermediario, y el intermediario responde por ella ante cada aplicación conectada.

Cuando llegas a un entorno nuevo, una buena primera pregunta es qué sistema es la fuente autoritativa de cada población de identidades y cuál es solo el intermediario que está delante del inicio de sesión. Una identidad tiene una sola fuente autoritativa pero puede pasar por varios intermediarios. Tratar a un intermediario como si fuera dueño de identidades que solo federa es como los equipos terminan sin poder decir de dónde viene de verdad un usuario, que es el problema de la fuente autoritativa con otro disfraz.

Las joyas de la corona

Ningún sistema de una empresa es un objetivo más valioso que el directorio. Conoce todas las identidades y otorga todas las pertenencias a grupos. Si lo comprometes, no vulneraste una cuenta; puedes hacerte pasar por todas.

En Active Directory, los controladores de dominio son las llaves del reino, y un atacante que controla uno tiene a mano técnicas con nombres tristemente famosos. DCSync se hace pasar por un controlador de dominio para pedir el hash de la contraseña de cada usuario. Kerberoasting extrae credenciales de cuentas de servicio de los tickets de Kerberos para romperlas sin conexión. Un Golden Ticket es un ticket de Kerberos falsificado que otorga cualquier acceso que el atacante quiera, posible tras robar la clave maestra del dominio. Todas están catalogadas en MITRE ATT&CK, y todas comparten una idea: cuando cae el directorio, la autenticación normal se vuelve teatro, porque el atacante puede fabricar credenciales válidas a voluntad. Administrador de dominio significa, en la práctica, dueño de todo.

Proteger la base

Como lo que está en juego es todo, la seguridad del directorio es de lo más valioso que se puede hacer en IAM, y los profesionales han llegado a un puñado de prácticas.

La primera es la administración por niveles. El modelo de acceso privilegiado de Microsoft separa el control de los controladores de dominio (nivel 0) del de los servidores (nivel 1) y las estaciones de trabajo (nivel 2), para que un portátil comprometido no sirva para llegar a un controlador de dominio. Es el mínimo privilegio aplicado al propio directorio.

La segunda es mantener pocas cuentas privilegiadas y bien vigiladas: pocos administradores de dominio, ninguna pertenencia permanente donde se pueda evitar y alertas ante cambios en grupos sensibles. Es la idea del acceso justo a tiempo aplicada al grupo más peligroso de la empresa.

La tercera es proteger las credenciales donde se guardan. Herramientas como LAPS, que aleatoriza las contraseñas de administrador local, y el grupo Protected Users reducen lo que puede hacer una credencial robada.

Y la cuarta es tratar el directorio como infraestructura vigilada. Los ataques anteriores dejan rastros, pero solo si alguien mira, así que los registros del directorio y de los controladores de dominio tienen que llegar a un sistema de monitoreo de seguridad.

Cómo sostiene el directorio el resto del módulo

Todo lo que sigue en este módulo trata, de una forma u otra, de sacar la identidad del directorio y llevarla, de forma segura, a los sistemas que la necesitan.

SAML federa una identidad del directorio hacia una aplicación web: el directorio es la fuente y SAML es la aserción que lleva “esta es Sara y está en Ingeniería” hasta la aplicación. OAuth delega la autorización, para que una aplicación actúe en nombre de un usuario, con el directorio respaldando quién es ese usuario. OIDC añade una capa de identidad estándar sobre OAuth, para que las aplicaciones puedan iniciar sesión contra el directorio a través de la web abierta. Y SCIM escribe de vuelta en los directorios y las aplicaciones, el verbo del aprovisionamiento que mantiene al directorio y a las cuentas de las aplicaciones en sintonía y hace posible la automatización de altas, traslados y bajas.

En todos los casos el directorio es el ancla. Los protocolos son sofisticados, pero existen para algo simple: tomar el “quién” autoritativo que vive en el directorio y volverlo utilizable, de forma segura, en todos los demás lugares.

Resumen

El directorio es la base sobre la que descansa todo el stack de protocolos de IAM.

1. Un servicio de directorio es un almacén jerárquico, replicado y optimizado para lectura de identidades y sus atributos, consultado con un protocolo estándar.
2. LDAP es su modelo de datos y su idioma: un árbol de entradas, cada una con un nombre distintivo, atributos definidos por objectClasses y esquema, y un conjunto chico de operaciones como bind, search y modify.
3. Active Directory es la plataforma local dominante, construida sobre LDAP más Kerberos y directivas de grupo y organizada en dominios y bosques.
4. Los directorios cloud como Entra ID y Okta guardan la identidad de la era SaaS y la exponen con SAML, OAuth, OIDC y SCIM, normalmente sincronizados con el AD local en un esquema híbrido.
5. Un directorio puede ser fuente autoritativa, intermediario o las dos cosas, y conviene saber cuál es para cada población.
6. El directorio son las joyas de la corona: conoce a todos y otorga todos los grupos, así que comprometerlo es total, y protegerlo es de lo más valioso que se puede hacer en IAM.

Ejercicios prácticos

Están pensados para hacerlos, no solo para leerlos.

1. Consulta un directorio real. Apunta ldapsearch, o un cliente gráfico como Apache Directory Studio, a un servidor de prueba público como ldap.forumsys.com, haz bind y busca en un subárbol. Anota los nombres distintivos de tres entradas, sus objectClasses y los atributos que tiene cada una.
2. Rastrea tu propio acceso. En un directorio que puedas ver, como un tenant gratuito de desarrollo de Entra ID o de Google Workspace, o tu propia cuenta si está permitido, busca tu objeto de usuario y enumera todos los grupos a los que perteneces. Después relaciona dos de esos grupos con el acceso a aplicaciones que otorgan.
3. Diseña un DIT. Dibuja el árbol del directorio de una empresa de 200 personas con tres áreas y algunos contratistas: elige las unidades organizativas, decide dónde viven los grupos y escribe el DN completo de un usuario de ejemplo.
4. Planifica un esquema híbrido. Una empresa usa AD local y está adoptando SaaS. Decide qué debería sincronizarse con Entra ID, si usarías Entra Connect Sync o Cloud Sync y por qué, y qué aplicaciones autentican contra qué directorio.
5. Clasifica por niveles las joyas de la corona. Dado un controlador de dominio, un servidor de archivos y el portátil de un analista de finanzas, asigna cada uno a un nivel de administración de Microsoft (0, 1 o 2) y nombra un control que impida que un portátil comprometido llegue al controlador de dominio.

Tres preguntas para ponerte a prueba

1. Una aplicación “autentica a los usuarios contra LDAP”. Explica qué pasa de verdad a nivel de protocolo, qué operación de LDAP interviene y por qué eso cuenta como una forma de inicio de sesión único.
2. Un colega dice: “Nos vamos a la nube, así que vamos a llevar Active Directory tal cual a Entra ID”. ¿Qué tiene de malo esa idea y cómo describirías la relación real entre AD y Entra ID?
3. ¿Por qué comprometer un solo controlador de dominio puede significar comprometer todo el bosque, y qué dos controles concretos limitarían el daño?