Tema 12

12. Directorios e identidad centralizada: LDAP, Active Directory y proveedores cloud

La gestión de identidades necesita una base estructural: un lugar donde se representen usuarios, grupos, atributos y relaciones de forma centralizada. Los directorios cumplen ese rol desde hace décadas y siguen siendo piezas clave, aunque hoy conviven con proveedores de identidad cloud y arquitecturas híbridas más complejas.

Objetivo Entender cómo se centraliza la identidad en la práctica
Enfoque Arquitectónico, operativo y comparativo
Resultado Distinguir directorios clásicos de proveedores cloud modernos

12.1 Introducción

Un ecosistema IAM necesita saber dónde viven las identidades y cómo se consultan. Si cada aplicación guarda sus propios usuarios, grupos y atributos de forma aislada, el resultado suele ser fragmentación, inconsistencia y mayor costo operativo.

Por eso muchas organizaciones adoptan una fuente central o principal de identidad. Históricamente, ese papel lo ocuparon los directorios LDAP y, en el mundo Microsoft, Active Directory. Hoy además existen proveedores de identidad cloud que extienden o reemplazan parte de esas funciones en entornos modernos.

Este tema busca ordenar ese panorama: qué es un directorio, cómo funciona LDAP, qué agrega Active Directory, y cómo se integran proveedores cloud en arquitecturas híbridas.

12.2 Qué es un directorio de identidad

Un directorio es un repositorio estructurado optimizado para almacenar y consultar identidades, atributos y relaciones asociadas. Suele organizar objetos como usuarios, grupos, unidades organizativas, dispositivos o servicios bajo una jerarquía o esquema definido.

En términos prácticos, un directorio cumple varias funciones importantes:

  • Centraliza información básica de identidad.
  • Permite búsquedas y consultas eficientes.
  • Sirve como base para autenticación y autorización.
  • Reduce duplicación entre múltiples aplicaciones.
  • Facilita gobierno y administración más coherente.

El directorio no siempre resuelve por sí solo todo el problema IAM, pero suele ser una pieza estructural del ecosistema.

12.3 Identidad centralizada versus identidades aisladas

Cuando no existe una fuente central, cada sistema crea y mantiene sus propias cuentas. Eso genera varios problemas:

  • Los atributos se desalinean entre aplicaciones.
  • Las altas y bajas se vuelven lentas e inconsistentes.
  • Los permisos se acumulan sin una visión global.
  • La auditoría requiere recorrer múltiples silos.
  • La experiencia del usuario se degrada por multiplicidad de credenciales.

La identidad centralizada no elimina toda complejidad, pero reduce gran parte del desorden estructural. Permite que distintos sistemas consuman una base común de usuarios y relaciones, aunque luego cada uno aplique sus propias reglas de autorización.

12.4 LDAP: qué es y para qué sirve

LDAP significa Lightweight Directory Access Protocol. Es un protocolo para consultar y modificar información en servicios de directorio. Con el tiempo, el término “LDAP” se usa muchas veces tanto para el protocolo como para el tipo de servicio que lo implementa.

LDAP permite trabajar con entradas estructuradas en una jerarquía. Es común encontrar objetos como:

  • Usuarios.
  • Grupos.
  • Unidades organizativas.
  • Dispositivos o recursos.

Su fortaleza histórica está en ser un estándar ampliamente soportado para centralizar identidades y atributos en entornos empresariales.

12.5 Estructura lógica de un directorio LDAP

Un directorio LDAP suele organizarse como un árbol jerárquico. Cada entrada tiene un nombre distinguido y atributos asociados. Este modelo facilita organizar identidades por dominios, unidades organizativas o tipos de objeto.

Por ejemplo, una entrada puede representar a un usuario con atributos como nombre, correo, pertenencia a grupos, identificadores internos y datos de organización.

Esta estructura no debe verse solo como una cuestión técnica. La forma en que se modela el árbol afecta administración, búsquedas, delegación y coherencia de identidad.

12.6 Qué aporta un directorio LDAP en un ecosistema IAM

Un directorio LDAP bien usado puede aportar:

  • Una base central de identidades.
  • Grupos reutilizables para múltiples aplicaciones.
  • Un punto de consulta uniforme para atributos.
  • Integración relativamente estándar con muchos sistemas.
  • Mejor consistencia en altas, cambios y bajas.

Sin embargo, LDAP no resuelve por sí mismo autenticación moderna, MFA, SSO, federación o gobierno completo. Puede ser la base, pero no siempre la capa final del problema.

12.7 Active Directory: más que un simple directorio

Active Directory, o AD, es la solución de directorio de Microsoft para entornos de dominio y administración centralizada. Aunque se apoya en conceptos y protocolos relacionados con LDAP, su alcance práctico va mucho más allá de un repositorio de usuarios.

AD se integra profundamente con:

  • Autenticación en entornos Windows.
  • Gestión de dominios y controladores.
  • Políticas de grupo.
  • Administración de equipos unidos al dominio.
  • Delegación y organización empresarial a gran escala.

Por eso, cuando se habla de Active Directory, no se habla solo de identidad centralizada, sino también de gobierno de infraestructura y control operativo del entorno corporativo.

12.8 Qué diferencia a AD de un directorio LDAP genérico

Aunque ambos comparten ideas de base, AD suele diferenciarse por su integración nativa con el ecosistema Microsoft y por las capacidades operativas que agrega. Un directorio LDAP genérico puede centralizar usuarios y grupos; AD, además, se convierte en corazón del dominio empresarial.

Aspecto LDAP genérico Active Directory
Rol principal Directorio y consulta de identidad Directorio, dominio y administración corporativa
Integración Windows Variable Muy profunda
Políticas de grupo No nativas Parte central del ecosistema
Casos de uso Consulta y centralización de identidades Identidad, autenticación y gestión del entorno empresarial

12.9 Grupos, unidades organizativas y delegación

Tanto en LDAP como en AD, los grupos y la organización lógica son esenciales. Los grupos ayudan a representar conjuntos reutilizables de identidades para autenticación y autorización. Las unidades organizativas o estructuras equivalentes facilitan segmentar administración y reflejar parte de la estructura organizacional.

Sin embargo, conviene no confundir estructura organizativa con modelo de permisos definitivo. Un grupo puede servir como insumo útil, pero no debería convertirse automáticamente en política suficiente para cualquier caso sin análisis adicional.

12.10 Directorio como fuente para autenticación y autorización

Un directorio central puede participar en varias capas:

  • Como fuente de identidad y atributos.
  • Como repositorio de grupos o pertenencias.
  • Como backend para autenticación en aplicaciones tradicionales.
  • Como fuente que alimenta un proveedor de identidad o un sistema IAM más amplio.

Es importante entender que el directorio no siempre es quien toma la decisión final de autorización. Muchas veces aporta datos que luego otros componentes usan para evaluar políticas.

12.11 Limitaciones de los directorios clásicos

Los directorios tradicionales siguen siendo muy valiosos, pero presentan límites en escenarios modernos si se los usa como única respuesta al problema de identidad:

  • No resuelven por sí solos SSO moderno entre aplicaciones heterogéneas.
  • No cubren de forma nativa todos los flujos de MFA y federación actuales.
  • Pueden resultar rígidos para ecosistemas cloud-first y multi-tenant.
  • No siempre ofrecen la experiencia moderna esperada para aplicaciones SaaS y APIs.

Por eso muchas organizaciones los mantienen como base de identidad interna, mientras agregan capas nuevas por encima.

12.12 Proveedores de identidad cloud

Los proveedores de identidad cloud extienden o reemplazan parte del papel histórico del directorio. Suelen ofrecer identidad centralizada, autenticación moderna, SSO, MFA, políticas de acceso y capacidades de federación.

En lugar de limitarse a almacenar usuarios, estos servicios suelen operar como plataforma de identidad para múltiples aplicaciones y servicios. En muchos casos también integran APIs, aplicaciones SaaS, dispositivos y reglas contextuales.

La ventaja principal es que acercan funcionalidades que un directorio clásico no resolvía de forma simple: autenticación moderna, integración federada y experiencia más homogénea en entornos híbridos y distribuidos.

12.13 Identidad híbrida

En muchas organizaciones no existe una sustitución total de lo anterior por lo nuevo. Lo habitual es una arquitectura híbrida: directorio on-premise o AD como fuente interna principal, sincronizado o federado con un proveedor de identidad cloud.

Este enfoque permite mantener compatibilidad con sistemas tradicionales mientras se incorporan capacidades modernas para SaaS, trabajo remoto, MFA, SSO y aplicaciones web.

La contracara es que aumenta la complejidad. Aparecen problemas de sincronización, precedencia de atributos, coherencia de grupos y definición de cuál sistema actúa como fuente autoritativa para cada dato.

12.14 Sincronización y consistencia

Cuando conviven múltiples repositorios de identidad, la sincronización se vuelve crítica. No basta con “copiar usuarios”. Hay que decidir:

  • Qué atributos viajan.
  • Con qué frecuencia se actualizan.
  • Qué sistema gana ante conflictos.
  • Qué pasa con bajas y suspensiones.
  • Cómo se reflejan grupos y roles derivados.

Una mala sincronización puede dejar accesos activos en cloud aunque la identidad ya no deba operar, o puede generar atributos desalineados que afecten autorización.

12.15 Directorio no es lo mismo que IdP

Es común confundir directorio con proveedor de identidad. Están relacionados, pero no son lo mismo.

Componente Rol principal
Directorio Almacena y organiza identidades, atributos y grupos
IdP Autentica sujetos y emite afirmaciones o tokens para otros sistemas

Un IdP puede apoyarse en un directorio como fuente de verdad, pero además agrega login, políticas de acceso, SSO, MFA y emisión de identidad hacia aplicaciones consumidoras.

12.16 Riesgos frecuentes en identidad centralizada

La centralización aporta consistencia, pero también concentra riesgo. Algunos problemas típicos son:

  • Un error de configuración impacta múltiples sistemas.
  • Un atributo incorrecto se propaga a muchos consumidores.
  • La caída del servicio central afecta autenticación general.
  • Un compromiso del directorio o del IdP tiene alcance transversal.

Eso no invalida la centralización, pero obliga a diseñarla con alta disponibilidad, controles de cambio, monitoreo y buen gobierno de datos.

12.17 Buenas prácticas al usar directorios centralizados

  • Definir claramente qué datos son autoritativos y dónde.
  • No convertir grupos heredados en políticas implícitas sin revisión.
  • Proteger administración y cambios sobre el directorio con controles fuertes.
  • Auditar sincronizaciones, altas, bajas y cambios sensibles.
  • Evitar usar el directorio como solución total si el problema requiere capas modernas adicionales.
  • Diseñar resiliencia y tolerancia a fallos del servicio central.

12.18 Qué debes recordar de este tema

  • Los directorios centralizan identidades, atributos y relaciones reutilizables.
  • LDAP es un estándar clásico para acceso a servicios de directorio.
  • Active Directory combina funciones de directorio con control profundo del entorno Windows empresarial.
  • Los proveedores de identidad cloud agregan autenticación moderna, SSO, MFA y federación.
  • En muchas organizaciones conviven directorios on-premise e IdP cloud en arquitecturas híbridas.
  • Centralizar identidad mejora consistencia, pero concentra impacto si hay errores o compromisos.

12.19 Conclusión

Directorios e identidad centralizada son piezas fundamentales del ecosistema IAM porque ordenan dónde vive la identidad y cómo otros sistemas la consumen. LDAP y Active Directory siguen siendo muy relevantes, mientras que los proveedores cloud amplían el alcance hacia autenticación moderna y federación. Entender cómo conviven estas piezas es clave para diseñar arquitecturas de identidad realistas.

En el próximo tema abordaremos Single Sign-On, federación de identidad y confianza entre dominios, donde estas bases de identidad empiezan a interoperar entre múltiples aplicaciones.