La mayoría de las organizaciones gestionan la identidad de los usuarios en un directorio LDAP o AD. Cuando se pone en marcha una nueva aplicación, vuelve a surgir la misma pregunta: ¿cómo se conectará esta aplicación al directorio, cómo autenticará al usuario, qué información de grupos leerá y dónde tomará la decisión de acceso? Si esta conexión se hace por separado en cada aplicación, la arquitectura de identidad se dispersa rápidamente.
La integración LDAP por aplicación produce deuda operativa. Cada aplicación arrastra su propia cuenta de servicio, dirección de conexión, filtro de búsqueda, valor de timeout y ajuste de validación de certificado. Cuando cambia el esquema del directorio, cuando se reestructura la jerarquía de OU, cuando se rota la contraseña de la cuenta de servicio o cuando se hace una migración de dominio, ese cambio se propaga a numerosas aplicaciones.
En el lado de la seguridad, el riesgo también crece. El uso de LDAP sin cifrar puede llevar a que las contraseñas viajen desprotegidas por la red. Las contraseñas de las cuentas de servicio se almacenan en las configuraciones de las aplicaciones. La autorización basada en grupos, por su parte, se dispersa en el propio código de las aplicaciones; la autenticación y la política de acceso se aplican en sistemas distintos con reglas distintas.
La auditoría y la visibilidad también se fragmentan. La información de qué aplicación se conectó al directorio con qué cuenta de servicio, qué usuario se autenticó, qué grupo se consultó y qué acceso se denegó suele quedar enterrada en los logs de la aplicación. Los equipos de SOC y de auditoría se ven obligados a combinar logs dispersos en lugar de un flujo de identidad centralizado.
TR7 LDAP / AD Bind resuelve este problema en la plataforma de acceso: los métodos direct-bind y search-bind, el transporte seguro LDAPS, la consulta de pertenencia a grupos, el filtro de restricción de bind, el failover multiservidor y la política de acceso condicional de AAM se unifican en una sola arquitectura.
TR7 AAM trata la conexión LDAP/AD no solo como validación de contraseña; sino como un flujo de búsqueda de usuarios, consulta de grupos, transporte seguro y generación de política de acceso.
Direct-bind convierte el nombre de usuario en el valor de bind principal mediante UPN, NetBIOS, UID, CN o un patrón personalizado. Search-bind, por su parte, busca la información de DN del usuario con una cuenta de servicio y, a continuación, realiza la validación de bind con la contraseña propia del usuario.
En modo search-bind se puede habilitar la búsqueda de grupos y las pertenencias a grupos del usuario se añaden a la sesión de AAM. Esta información de grupos puede usarse en decisiones de acceso a aplicaciones, obligatoriedad de MFA o autorización por backend.
TR7 puede establecer una conexión protegida con TLS mediante LDAPS. Configurando la validación de certificados y la política de certificados autofirmados se determina el nivel de seguridad de la conexión al directorio según el estándar de la organización.
Se pueden definir varios servidores LDAP/AD en una sola configuración. Las conexiones se distribuyen mediante los métodos roundrobin, weighted o failover; cuando el servidor de directorio principal es inaccesible, puede activarse un servidor alternativo.
LDAP / AD Bind conecta la validación de directorio corporativo al flujo de AAM con plantillas de bind, filtros de búsqueda, pertenencia a grupos, transporte seguro y gestión multiservidor.
En modo direct-bind, el nombre de usuario se convierte en el valor de bind principal mediante una de las plantillas UPN, NetBIOS, UID, CN o custom. En entornos AD, los formatos UPN y NetBIOS son comunes; en directorios OpenLDAP o POSIX, los patrones UID y CN pueden ser más adecuados. Con el patrón custom se puede construir una estructura específica de la organización como uid={{username}},ou=people,dc=company,dc=com. Esta flexibilidad facilita conectar distintos esquemas de directorio a un único flujo de validación de AAM.
En modo search-bind, TR7 primero se conecta al directorio con una cuenta de servicio y busca la información de DN del usuario. Cuando se encuentra al usuario, en el segundo paso se realiza la operación de bind con el DN y la contraseña propios del usuario. Este modelo es útil en entornos donde los usuarios se encuentran en distintas OU, donde el DN no puede generarse directamente a partir del nombre de usuario o donde se requiere un filtro de búsqueda más controlado. La cuenta de servicio y la información de base DN de búsqueda se gestionan de forma centralizada.
El filtro de search-bind en modo automático puede evaluar conjuntamente los campos userPrincipalName, sAMAccountName y cn. En modo custom, el operador define su propio filtro LDAP; por ejemplo, puede hacerse una búsqueda más restringida como (sAMAccountName={{username}}). Este enfoque se adapta a distintos esquemas de directorio y formatos de nombre de usuario. Para reducir las coincidencias de usuario erróneas, el filtro debe definirse lo más preciso posible.
Aunque la contraseña del usuario sea correcta, puede no ser deseable que cada usuario del directorio acceda a cada aplicación. Con el filtro de restricción de bind se logra que solo los usuarios que cumplen una condición de OU, grupo o atributo concreta pasen el flujo de validación. Por ejemplo, solo los usuarios del grupo VPN Users pueden ser admitidos en un backend concreto. Este filtro evalúa la autenticación junto con el alcance del acceso.
Cuando ldapEnableGroupSearch está activo, TR7 puede consultar las pertenencias a grupos usando el valor de DN del usuario. Con ldapGroupSearchBase y ldapGroupFilter se determina en qué región del directorio y con qué filtro se buscarán los grupos. La lista de grupos devuelta se añade a la sesión de AAM. Los flujos de acceso condicional pueden tomar decisiones distintas de aplicación, MFA, permiso o denegación según esta información de grupos.
Cuando se usa LDAPS, la conexión LDAP se protege con TLS y normalmente opera por el puerto 636. El comportamiento de validación del certificado del servidor puede configurarse con ajustes como sslValidateCertificate y sslAllowSelfSigned. En entornos de producción no debe preferirse LDAP sin cifrar. La seguridad de la conexión al directorio es un requisito fundamental para proteger datos sensibles como la contraseña del usuario y la cuenta de servicio.
Los valores de timeout de conexión y operación LDAP son configurables. Si no se puede establecer la conexión o el servidor de directorio responde lentamente, el flujo de AAM no espera de forma indefinida. El comportamiento de un domain controller lento en horas punta o la latencia de un segmento de red pueden controlarse con estos valores. Los ajustes de timeout deben planificarse junto con la experiencia de usuario y el comportamiento de failover.
TR7 puede extraer usuarios bajo una base de búsqueda concreta y transferir valores de atributos como correo y teléfono al perfil de usuario local de AAM. Campos como queryMailField y queryPhoneField pueden ajustarse según el esquema de la organización. Esta función ayuda en la gestión de la lista de usuarios y de la información de contacto. En entornos de cluster, la extracción de la lista de usuarios se restringe para ejecutarse solo en el nodo primario.
En el array hosts se pueden definir varios servidores LDAP/AD. lbMethod puede seleccionarse como roundrobin, weighted o failover. En modo failover, cuando el servidor principal es inaccesible se conmuta al servidor alternativo. El enfoque de pool de conexiones y circuit breaker reduce que los servidores que fallan continuamente rompan el flujo.
Se puede configurar a través de qué namespace de red se llega al servidor LDAP. Esto es importante para domain controllers en un segmento separado o estructuras de directorio específicas de tenant. El tráfico de gestión de acceso se transporta por la tabla de rutas correcta y el aislamiento de red. En arquitecturas multitenant o de centros de datos segregados proporciona un control de red más claro.
LDAP / AD Bind se opera junto con el ciclo de vida de conexión, la seguridad de filtros, la limpieza de conexión, el comportamiento de search-bind, la restricción de cluster y la selección de atributos.
Cuando se actualizan los ajustes LDAP, la información de conexión se reprepara y el flujo de validación opera con los nuevos ajustes. La información de conexión se genera a partir de los parámetros protocol, host, port, TLS y timeout. Aplicar los cambios de ajustes dentro de un ciclo de vida centralizado proporciona consistencia de configuración.
Antes de insertar las entradas del usuario en el filtro LDAP se escapan los caracteres especiales. Valores como la barra invertida, el asterisco, los paréntesis y el carácter null se escapan para reducir el riesgo de inyección LDAP. Este comportamiento es especialmente crítico en estructuras que usan un filtro custom.
Tras usar la conexión LDAP, el cliente se limpia y se eliminan los listeners. Este enfoque reduce las conexiones zombi y el uso innecesario de memoria. El comportamiento de keep-alive de larga duración debe usarse solo en modos especiales como la extracción de la lista de usuarios.
El filtro de search-bind automático puede evaluar conjuntamente los campos userPrincipalName, sAMAccountName y cn. En modo de filtro custom, el operador define su propio filtro LDAP. El filtro custom es potente; pero, dado que los filtros demasiado amplios y erróneos pueden llevar a coincidencias de usuario inesperadas, debe diseñarse con cuidado.
La estructura de pool de backend LDAP de nueva generación puede gestionar las conexiones de cliente LDAP con lógica de pool. Cuando se selecciona LDAPS, las opciones TLS se añaden al establecimiento de la conexión. El tiempo de búsqueda DNS personalizado y los valores de timeout de conexión cobran importancia en redes lentas o segmentadas.
La extracción de la lista de usuarios se restringe para ejecutarse solo en el nodo primario en entornos de cluster. Este comportamiento evita que la misma lista de usuarios sea extraída de forma simultánea por varios nodos y genere carga innecesaria. El flujo de bind de autenticación, por su parte, sigue operando según el modelo de conexión definido.
Con el array ldapAttributes se determina qué campos se devolverán del directorio. Los campos por defecto pueden cubrir valores como dn, cn, userPrincipalName, displayName, mail y teléfono. Campos adicionales como department, employeeID o atributos personalizados pueden añadirse a la lista según la necesidad de la organización.
En una organización grande, los empleados acceden a las aplicaciones a través de AAM con su nombre de usuario y contraseña AD existentes. Las pertenencias a grupos se transfieren a la política de AAM; los grupos de finanzas, RR. HH. y TI pueden enrutarse a distintas aplicaciones o flujos de MFA. Cuando cambia la política de contraseñas de AD, las aplicaciones no se actualizan una por una.
En una estructura con dos domain controllers en dos centros de datos, TR7 puede establecer la conexión mediante el método failover. Cuando el servidor de directorio principal es inaccesible, se conmuta al servidor alternativo. El flujo de validación de usuarios no depende del fallo de un único DC.
Un backend concreto puede abrirse solo a los usuarios del grupo VPN Users. Aunque el bind sea exitoso, el usuario que no pasa la condición de bindRestrictionFilter es rechazado. Así, la validación de contraseña y la autorización de acceso a la aplicación no se consideran lo mismo.
Las organizaciones que usan OpenLDAP en lugar de AD pueden validar usuarios con las plantillas de bind UID o CN. En directorios basados en posixAccount, el mapeo de correo, teléfono y atributos personalizados puede transferirse al perfil de AAM. Estableciendo una conexión segura con LDAPS, los directorios LDAP clásicos se incorporan al flujo de acceso moderno.
Conexión LDAP/AD, política basada en grupos, transporte seguro LDAPS y auditoría centralizada en una sola plataforma. Le guiaremos por una instalación en vivo en su propio entorno.