Integración de identidad y directorio: dónde empiezan y acaban Entra ID, LDAP y el SSO

El fracaso más silencioso de una intranet vive en su lista de usuarios. Al arrancar se importa una hoja de cálculo de RR. HH. y todo el mundo queda satisfecho durante un mes; seis meses después siguen ahí tres personas que ya se fueron, faltan cinco que entraron y nadie confía ya en el organigrama. No es un problema de contenido sino de fuente de verdad: la realidad de la plantilla vive en otro sistema.

Conectarse al directorio corporativo lo resuelve. Pero «integración de directorio» no es una sola cosa: son dos trabajos que se confunden con frecuencia.

El SSO autentica, el directorio abastece

Trazar esta línea desde el principio simplifica todas las decisiones posteriores.

El SSO (SAML u OIDC) es un trabajo de autenticación. Las personas entran con su cuenta corporativa, no mantienen una contraseña propia de la intranet y pierden el acceso en cuanto esa cuenta se cierra. La pregunta que responde el SSO es: «¿Esta persona es realmente quien dice ser?».

La conciliación con el directorio es un trabajo de suministro de datos. Lee quién está empleado, en qué departamento y con qué puesto, y lo escribe en los perfiles de la intranet. Su pregunta es distinta: «¿Quiénes componen hoy la plantilla?».

Ninguno sustituye al otro. Si se despliega solo el SSO, los accesos mejoran mientras el directorio sigue envejeciendo, porque quien nunca ha iniciado sesión no aparece en absoluto. Si se despliega solo la conciliación, el listado se mantiene al día pero cada persona sigue cargando con una contraseña aparte. Las instalaciones maduras usan ambos.

El lado de Entra ID

En Microsoft Entra ID (antes Azure AD) la configuración empieza con un registro de aplicación. La intranet se conecta al directorio con identidad propia a través de ese registro; no se utiliza la cuenta personal de nadie.

Hacen falta tres valores: el identificador de directorio (inquilino), el de aplicación (cliente) y un secreto de cliente. Además un permiso: para leer la plantilla, la aplicación recibe User.Read.All, y esa concesión pasa por el consentimiento del administrador. Cuando se olvida ese paso, la prueba de conexión obtiene un token pero la lista de usuarios vuelve vacía; por eso una prueba solvente no debe detenerse en el token, sino consultar de verdad el punto de acceso de usuarios.

Conviene anotar también que el secreto de cliente caduca. Al vencer, la integración se detiene en silencio; un recordatorio en el calendario sale más barato que investigar seis meses después por qué dejó de sincronizar.

El lado de LDAP / Active Directory

Cuando existe un Active Directory clásico en casa, la conexión va por LDAP. Aquí se necesitan otras cosas: la dirección del servidor, una cuenta con permisos de lectura (bind DN) y el punto donde arranca la búsqueda (base DN).

Dos detalles deciden la mayoría de los despliegues. El primero es la conexión cifrada: sin LDAPS ni StartTLS, credenciales corporativas viajan en claro por la red. El segundo es descartar las cuentas deshabilitadas: en Active Directory, los registros de quienes se van no suelen borrarse, sino deshabilitarse. Ese estado vive como un bit del atributo userAccountControl; si falta en el filtro, cada baja entra en la intranet como «empleado activo», reproduciendo justo el problema que se quería resolver, ahora de forma automática.

Previsualizar y luego aplicar

El escenario más temido en estas integraciones es que una mala configuración estropee la plantilla en bloque. La respuesta es una disciplina sencilla: primero se muestra la diferencia; aplicarla requiere una aprobación aparte.

En la práctica el flujo es: la prueba de conexión pasa, el sistema compara los registros del directorio con los perfiles de la intranet y produce una lista de diferencias — cuántos se han conciliado, a quién le ha cambiado el departamento, quién ya no está en el directorio. Una administradora lee esa lista y después la aplica.

También conviene conocer los límites de antemano. En Wepilot la conciliación no crea cuentas ni departamentos; actualiza perfiles existentes. La razón es la prudencia: cientos de cuentas creadas por un filtro equivocado se deshacen mucho peor que unos campos de perfil escritos por ese mismo error. El ciclo de vida de cuentas totalmente automatizado — altas, movimientos y bajas mediante SCIM — es otro asunto y queda fuera del alcance de esta integración.

¿Dónde viven los secretos?

Lo que transporta esta integración no es un ajuste corriente, sino acceso a su directorio. El secreto de cliente y la contraseña LDAP no deben llegar nunca al navegador.

El patrón correcto es guardar esos registros en una tabla sin ninguna política de lectura y devolver a la pantalla de administración únicamente si hay un secreto definido o no. Una administradora puede rellenar el campo, pero no puede releer lo que escribió antes. Esto es distinto de ocultar un campo en la interfaz: la restricción está en la base de datos y ninguna petición desde un navegador la sortea. Describimos otros lugares donde rige el mismo principio en el artículo sobre protección de datos.

¿Por dónde empezar?

Nuestro orden recomendado es claro: primero la conciliación con el directorio, después el SSO. La razón es práctica: un directorio correcto produce desde el primer día un beneficio que todo el mundo ve, mientras que el SSO exige coordinación con el equipo de identidad y una ventana de pruebas.

Medirlo también es fácil: el número de registros sin conciliar, el número de personas que están en el directorio pero no en la intranet y el tiempo transcurrido desde la última sincronización correcta. Si esos tres no tienden a cero, la integración está instalada pero no operada. Tratamos ese tipo de responsabilidad de proceso en el artículo sobre operación.