Servicios de directorio: dónde viven realmente las identidades

Por qué el módulo de protocolos empieza aquí

Bienvenido a Access Management, y a su módulo fundacional: estándares, protocolos y servicios de directorio. La apuesta pedagógica de este módulo es simple — antes de poder razonar sobre autenticación, federación o gobernanza, hay que hablar el idioma común de IAM. Ese idioma es un stack de protocolos, y bajo todos ellos hay una cosa con la que todo protocolo termina hablando: el directorio.

Un directorio es donde las identidades viven realmente. Cuando SAML afirma quién eres, cuando OAuth emite un token, cuando SCIM aprovisiona una cuenta, cuando el ciclo JML crea un joiner — todo ello lee de o escribe en un directorio. El directorio responde la pregunta más básica de toda la IAM: ¿quién es esto, y a qué pertenece? Si te equivocas con el directorio, cada protocolo encima de él hereda el error. Así que empezamos por el fondo del stack y construimos hacia arriba.

Qué es realmente un servicio de directorio

Un servicio de directorio es una base de datos especializada, pero no de propósito general. Está optimizada para una carga de trabajo muy particular: búsquedas jerárquicas de datos de identidad, intensivas en lectura. Las aplicaciones le hacen el mismo tipo de preguntas miles de veces por segundo — “¿existe este usuario?”, “¿cuál es su correo?”, “¿en qué grupos está?” — y rara vez le escriben. Esa asimetría moldea todo sobre cómo se construyen los directorios: favorecen lecturas rápidas y replicación por encima de las garantías transaccionales de escritura que obsesionan a una base de datos relacional.

La analogía clásica es una guía telefónica. Una guía está organizada jerárquicamente (por región, luego nombre), optimizada para la búsqueda más que para la edición, y replicada ampliamente para que todos tengan una copia. Un servicio de directorio es la misma idea para identidades digitales: un árbol de entradas, cada una describiendo una cosa — una persona, un grupo, una impresora, una cuenta de servicio — con un conjunto de atributos, consultable sobre un protocolo estándar.

Tres propiedades distinguen a un directorio de una base de datos ordinaria:

• Estructura jerárquica: las entradas viven en un árbol, no en tablas planas, reflejando cómo piensan las organizaciones (empresa → departamento → persona).
• Protocolo de acceso estándar: los clientes le hablan por LDAP (o, en la era cloud, APIs HTTP), así que cualquier aplicación puede leerlo de la misma forma.
• Replicación y distribución: se mantienen copias sincronizadas entre servidores para que una búsqueda siempre sea rápida y esté disponible localmente, y la caída de un servidor no tumbe 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 estructurar sus datos. Es “ligero” en relación con los estándares de directorio X.500 más pesados de los que desciende, y ha sido la lingua franca de los directorios on-premise desde finales de los años 90.

El árbol: DIT, entradas y distinguished names

LDAP organiza los datos como un Directory Information Tree (DIT). Cada nodo del árbol es una entrada, y cada entrada tiene un distinguished name (DN) — su ruta única y completa leída desde la entrada hacia la raíz.

flowchart TD
  accTitle: Un Directory Information Tree de LDAP
  accDescr: El árbol está enraizado en los componentes de dominio dc=example,dc=com. Bajo la raíz hay dos unidades organizativas, ou=People y ou=Groups. Bajo ou=People hay dos entradas de persona, cn=Sara Lopez y cn=Daniel Ortiz. Bajo ou=Groups hay una entrada de grupo, cn=Engineering. El distinguished name de una entrada es la ruta desde esa entrada hacia la raíz.
  ROOT["dc=example,dc=com"] --> P["ou=People"]
  ROOT --> G["ou=Groups"]
  P --> S["cn=Sara Lopez"]
  P --> D["cn=Daniel Ortiz"]
  G --> E["cn=Engineering"]

Lectura del árbol: la raíz es la organización, expresada como componentes de dominio (dc=example,dc=com). Debajo hay unidades organizativas (ou=People, ou=Groups) que agrupan entradas relacionadas. Las hojas son los objetos reales — una persona llamada Sara Lopez tiene el DN cn=Sara Lopez,ou=People,dc=example,dc=com. Cada pieza separada por comas es un relative distinguished name (RDN) que nombra un nivel; el DN es la concatenación de todos ellos, exactamente como una ruta de sistema de archivos identifica de forma única un archivo.

Atributos, objectClasses y schema

Cada entrada guarda atributos — pares nombre/valor como mail: sara@example.com, telephoneNumber: 4521, memberOf: cn=Engineering,.... Qué atributos puede y debe tener una entrada lo gobiernan sus objectClasses, y el conjunto completo de objectClasses y atributos permitidos es el schema del directorio (estandarizado en RFC 4519 y extendido por despliegue).

Por ejemplo, una entrada con objectClass inetOrgPerson debe tener un apellido (sn) y un nombre común (cn), y puede tener mail, mobile, title y decenas más. El schema es el contrato: es por lo que cualquier cliente LDAP puede leer cualquier directorio LDAP y saber que mail significa una dirección de correo. Extender el schema (agregar atributos propios) es poderoso pero permanente y disruptivo, por lo que los equipos maduros tratan los cambios de schema con el mismo cuidado que las migraciones de base de datos.

Operaciones de LDAP

El protocolo en sí es un pequeño conjunto de operaciones, y conocerlas desmitifica buena parte de la IAM:

• Bind: autenticarse contra el directorio (así hace LDAP la autenticación — una app hace “bind” como un usuario con su contraseña para verificarla).
• Search: el caballo de batalla — consultar entradas que coincidan con un filtro, p. ej. “todas las entradas bajo ou=People donde department=Finance”.
• Add / Modify / Delete: operaciones de escritura, usadas por el aprovisionamiento.
• Compare y Unbind: verificar el valor de un atributo, y cerrar la sesión.

La operación bind merece detenerse, porque es un mecanismo de autenticación fundacional: cuando una app legacy “se autentica contra LDAP”, está literalmente intentando hacer bind al directorio usando las credenciales que el usuario escribió. Si el bind tiene éxito, la contraseña era correcta. Este es el sustrato original del single sign-on, y todavía corre debajo de una cantidad sorprendente de software empresarial.

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, durante dos décadas, la mayor parte del mundo corporativo lo ha hablado. Introducido por Microsoft en 2000, AD es mucho más que un directorio LDAP — es una plataforma de identidad y gestión construida en torno a él, y sigue siendo la columna vertebral de la TI empresarial on-premise.

Dominios, árboles y bosques

AD organiza el mundo en una jerarquía propia:

• Un dominio es la frontera administrativa central — una colección de usuarios, computadoras y grupos bajo una política común, servida por controladores de dominio (DCs) que guardan el directorio y autentican los inicios de sesión.
• Un árbol es un conjunto de dominios que comparten un espacio de nombres contiguo.
• Un bosque es la frontera de seguridad de nivel superior — uno o más árboles que confían entre sí y comparten un schema y un catálogo global (un índice parcial de todo el bosque para búsquedas cruzadas rápidas).

El bosque es la línea que más importa para la seguridad: es la frontera de confianza. Todo dentro de un bosque confía implícitamente en todo lo demás, por lo que “el compromiso de un dominio puede significar el compromiso del bosque” es una frase que mantiene despiertos a los administradores de AD.

Más que LDAP

AD agrupa varios protocolos y servicios que juntos lo vuelven una plataforma de gestión, no solo un almacén de búsqueda:

• Kerberos para autenticación — el protocolo basado en tickets que permite a una máquina unida al dominio probar quién es su usuario sin reenviar la contraseña (lo veremos de nuevo en el artículo de tokens).
• Group Policy (GPO) para empujar configuración y ajustes de seguridad a miles de máquinas de forma centralizada.
• Integración con DNS, porque los clientes localizan los controladores de dominio vía DNS.
• LDAP, todavía, para lecturas y escrituras del directorio.

Este empaquetamiento es justo por lo que AD se volvió tan dominante y tan pegajoso: no solo almacenaba identidades, gestionaba la flota. También es por lo que migrar lejos de él es tan difícil, y por lo que la mayoría de las empresas no reemplazan AD sino que lo extienden hacia la nube.

El lugar del directorio en el ciclo de IAM

Vale la pena ser preciso sobre dónde se sitúa el directorio respecto al ciclo operativo. El directorio no suele ser la fuente autoritativa original de la identidad — esa típicamente es el sistema de RR. HH., que sabe quién fue contratado. En cambio, el directorio es la fuente de verdad en tiempo de ejecución: el lugar que las aplicaciones realmente consultan en el momento del acceso.

El flujo es: RR. HH. declara que una persona existe → el aprovisionamiento JML crea y mantiene su entrada en el directorio → las aplicaciones leen el directorio en cada login para autenticarla y resolver sus membresías de grupo. El directorio es el corazón operativo que convierte “RR. HH. dice que esta persona es analista de Finanzas” en “este login tiene éxito y esta persona puede abrir la app de Finanzas”. La membresía de grupo en el directorio es, en la práctica, cómo se otorga y revoca la mayor parte del acceso.

El salto a los directorios cloud

El mundo on-premise de LDAP-y-Kerberos asumía que tus usuarios se sentaban frente a máquinas unidas al dominio en la red corporativa, alcanzando servidores internos. Esa suposición se rompió. Los usuarios ahora trabajan desde cualquier parte, en cualquier dispositivo, alcanzando aplicaciones SaaS que viven en la infraestructura de otro. Las apps SaaS no hablan LDAP ni Kerberos — hablan protocolos basados en HTTP. Así que surgió una nueva generación de directorios.

Los directorios cloud — Microsoft Entra ID (antes Azure AD), Okta Universal Directory, el directorio de Google — almacenan identidades de forma muy parecida a sus predecesores pero las exponen sobre protocolos modernos y amigables con internet: SAML, OAuth, OIDC y SCIM (el resto de este módulo). Crucialmente, Entra ID no es “Active Directory en la nube”, a pesar del nombre antiguo. Las diferencias son arquitectónicas, no cosméticas:

• No es jerárquico. No hay DIT, ni unidades organizativas, ni DN. Las identidades viven en un tenant plano, organizadas por grupos y unidades administrativas en lugar de un árbol.
• Es API-first, no LDAP. No haces bind y search por LDAP; llamas a una API REST — Microsoft Graph — sobre HTTPS. El modelo de consulta es nativo de la web, no nativo de directorio.
• No tiene dominios, árboles, bosques ni Group Policy. Todo el aparato de gestión de AD está ausente, porque Entra ID no gestiona flotas de Windows unidas al dominio — broker-ea identidad a apps cloud y SaaS sobre la web abierta.

Alternativas y cuándo usarlas

AD y Entra ID dominan, pero están lejos de ser los únicos directorios, y conocer las alternativas es parte de hablar el idioma común con fluidez:

El patrón a notar: las opciones open-source (OpenLDAP, FreeIPA) mantienen vivo el modelo clásico LDAP/Kerberos para entornos centrados en Unix, mientras que las plataformas cloud (JumpCloud, Okta) apuntan a organizaciones que nunca construyeron un directorio on-premise y quieren identidad entregada como servicio. No hay un único directorio “correcto” — está el que encaja con tu mezcla de plataformas, tu escala y si eres broker-first o source-first (una distinción que afinamos más abajo).

Identidad híbrida: vivir en ambos mundos

Casi ninguna empresa grande es puramente on-prem o puramente cloud. Corren identidad híbrida: Active Directory on-premise para máquinas unidas al dominio y apps legacy, sincronizado a un directorio cloud para SaaS. Un motor de sincronización copia identidades y atributos de AD hacia Entra ID, para que un usuario tenga una identidad que funcione en ambos mundos. Microsoft lo ha enviado bajo varios nombres que conviene reconocer:

• Azure AD Connect — el servidor de sincronización original, más pesado (ahora marca legacy).
• Entra Connect Sync — el nombre actual de ese servidor de sincronización con todas las funciones.
• Entra Cloud Sync — un agente más ligero y gestionado desde la nube para topologías más simples, cada vez más el predeterminado para nuevos despliegues.

flowchart LR
  accTitle: Flujo de sincronización de identidad híbrida
  accDescr: El sistema de RR. HH. alimenta el Active Directory on-premise, que autentica máquinas unidas al dominio y apps legacy vía LDAP y Kerberos. Un motor de sincronización, Entra Connect, proyecta identidades y atributos del AD on-prem hacia el directorio cloud, Entra ID. El directorio cloud luego broker-ea el acceso a aplicaciones SaaS usando los protocolos SAML, OIDC y SCIM.
  HR[Sistema RR. HH.] --> AD[(Active Directory<br/>on-premise)]
  AD -->|LDAP / Kerberos| LEGACY[Máquinas unidas al dominio<br/>y apps legacy]
  AD -->|sync: Entra Connect| CLOUD[(Directorio cloud<br/>Entra ID)]
  CLOUD -->|SAML / OIDC| SAAS[Apps SaaS]
  CLOUD -->|SCIM| SAAS

Esta forma híbrida es la realidad que encontrarás en el campo mucho más a menudo que un directorio cloud greenfield y limpio. También explica por qué importa el resto de este módulo: el trabajo entero del directorio cloud es hablar los protocolos que permiten que identidades de tu directorio inicien sesión en aplicaciones que no controlas. El directorio es el sustantivo; SAML, OIDC y SCIM son cómo ese sustantivo viaja a la nube.

Fuente autoritativa vs. broker de identidad

Un directorio puede jugar dos roles muy distintos, y confundirlos causa errores de diseño reales. Puede ser una fuente autoritativa — el sistema que posee las identidades, el lugar donde se crean y se administran. O puede ser un broker de identidad — un sistema que media la autenticación entre muchas aplicaciones y una o más fuentes upstream, sin necesariamente poseer las identidades en sí.

El Active Directory clásico es abrumadoramente una fuente autoritativa: las identidades nacen y viven ahí. Un IdP cloud moderno como Okta o Entra ID a menudo juega ambos roles a la vez — administra algunas identidades directamente mientras broker-ea otras. Como broker, federa las apps downstream a un único login, y federa upstream hacia otras fuentes: tu AD on-prem, el IdP de un socio, o logins sociales/de consumidor. El usuario inicia sesión una vez en el broker, y el broker responde por él ante cada app conectada.

El directorio son las joyas de la corona

Ningún sistema en una empresa es un objetivo de mayor valor que el directorio, y entender por qué es esencial para entender la seguridad de IAM. El directorio conoce cada identidad y otorga cada membresía de grupo. Compromételo y no vulneras una cuenta — puedes suplantar a todas ellas.

En Active Directory específicamente, los controladores de dominio son las llaves del reino. Un atacante que gana control de un DC puede ejecutar ataques con nombres que se han vuelto infames en seguridad:

• DCSync — suplantar a un controlador de dominio para pedir el hash de contraseña de cada usuario.
• Kerberoasting — extraer credenciales de cuentas de servicio de los tickets Kerberos para crackearlas offline.
• Golden Ticket — forjar tickets Kerberos que otorgan acceso arbitrario, habiendo robado la llave maestra del dominio.

Estos (catalogados en detalle en el framework MITRE ATT&CK) comparten un tema: una vez que cae el directorio, la autenticación normal se vuelve teatro, porque el atacante puede acuñar credenciales válidas a voluntad. “Administrador de dominio” es efectivamente “posee todo”.

Proteger el sustrato

Como las apuestas son totales, la seguridad del directorio está entre el trabajo de mayor palanca en IAM. Las prácticas en las que los profesionales convergen:

• Administración por niveles: el modelo de niveles 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 una laptop comprometida no pueda pivotar a un DC. Esto es mínimo privilegio aplicado al directorio mismo.
• Minimizar y monitorear cuentas privilegiadas: pocos administradores de dominio, sin membresía fija donde se pueda evitar, y alertas sobre cambios en grupos sensibles — el principio JIT aplicado al grupo más peligroso de la empresa.
• Proteger las credenciales en reposo: herramientas como LAPS (contraseñas de admin local aleatorizadas) y los grupos Protected Users encogen el radio de impacto de cualquier credencial robada.
• Tratar el directorio como infraestructura monitoreada: alimentar los logs del directorio y de los DCs a un SIEM, porque los ataques de arriba dejan rastros detectables — si estás mirando.

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

Todo lo que sigue en este módulo trata, en cierto sentido, de sacar la identidad del directorio y meterla en los sistemas que la necesitan, de forma segura. Un mapa rápido de hacia dónde vamos:

• SAML federa una identidad del directorio hacia una app web: el directorio es la fuente, SAML es la afirmación que lleva “esta es Sara, y está en Ingeniería” a la app.
• OAuth delega autorización — permitiendo que una app actúe en nombre de un usuario — con el directorio respaldando quién es ese usuario.
• OIDC agrega una capa de identidad estándar sobre OAuth, para que las apps puedan iniciar sesión a los usuarios contra el directorio sobre la web abierta.
• SCIM escribe de vuelta en directorios y apps — el verbo de aprovisionamiento que mantiene el directorio y las cuentas downstream sincronizados, el protocolo detrás de la automatización JML.

En cada caso el directorio es el ancla. Los protocolos son sofisticados, pero existen para servir un propósito simple: tomar el “quién” autoritativo que vive en el directorio y hacerlo utilizable, de forma segura, en todas partes.

Recapitulación

El directorio es el sustrato bajo todo el stack de protocolos de IAM:

1. Un servicio de directorio es un almacén de identidades y sus atributos optimizado para lectura, jerárquico y replicado, consultado sobre un protocolo estándar.
2. LDAP es el modelo de datos y el idioma — el DIT de entradas, cada una con un distinguished name, atributos gobernados por objectClasses y schema, accedidos mediante un pequeño conjunto de operaciones (bind, search, modify).
3. Active Directory es la plataforma on-prem dominante construida sobre LDAP más Kerberos y Group Policy, organizada en dominios y bosques.
4. Los directorios cloud (Entra ID, Okta) almacenan identidad para la era SaaS y la exponen sobre SAML, OAuth, OIDC y SCIM — normalmente sincronizados con el AD on-prem en una configuración híbrida.
5. El directorio son las joyas de la corona: conoce a todos y otorga cada grupo, así que su compromiso es total, y su protección está entre el trabajo de mayor valor en IAM.

Ejercicios prácticos

Estos son prácticos — hazlos, no solo los leas:

1. Consulta un directorio real. Apunta ldapsearch (o una GUI como Apache Directory Studio) a un servidor de prueba público como ldap.forumsys.com, haz bind, y busca un subárbol. Identifica los distinguished names de tres entradas, sus objectClasses, y los atributos que lleva cada una.
2. Rastrea tu propio acceso. En un directorio que puedas ver — un tenant de desarrollo gratuito de Entra ID o Google Workspace, o tu propia cuenta si se permite — encuentra tu objeto de usuario y lista cada grupo al que perteneces. Luego mapea dos de esos grupos al acceso de app que realmente otorgan.
3. Diseña un DIT (caso de uso). Esboza el Directory Information Tree para una empresa de 200 personas con tres departamentos más contratistas: elige la estructura de OUs, decide dónde viven los grupos, y escribe el DN completo de un usuario de ejemplo.
4. Planifica una topología híbrida (caso de uso). Una empresa corre AD on-prem y está adoptando SaaS. Decide qué debería sincronizarse a Entra ID, si usarías Entra Connect Sync o Cloud Sync y por qué, y qué apps se autentican contra qué directorio.
5. Clasifica las joyas de la corona por niveles (caso de uso). Dado un controlador de dominio, un servidor de archivos y la laptop de un analista de finanzas, asigna cada uno a un nivel de admin de Microsoft (0/1/2) y nombra un control que impida que una laptop comprometida alcance el controlador de dominio.

Tres preguntas para autoevaluarte

1. Una aplicación “autentica usuarios contra LDAP”. Explica qué ocurre realmente a nivel de protocolo, qué operación LDAP está involucrada, y por qué esto es una forma de single sign-on.
2. Un colega dice “nos movemos a la nube, así que solo haremos lift-and-shift de Active Directory hacia Entra ID”. ¿Qué tiene de malo ese modelo mental, y cómo describirías la relación real entre AD y Entra ID?
3. ¿Por qué comprometer un único controlador de dominio puede significar comprometer el bosque entero, y nombra dos controles específicos que limitarían el radio de impacto?