Problema

En entornos con Active Directory (AD) es habitual observar que un equipo cliente realiza la autenticación Kerberos contra el controlador de dominio (DC) que responde al registro SRV _kerberos._tcp. Lo que sorprende a muchos es que, después de obtener el ticket, el mismo cliente abre una conexión LDAP hacia una dirección IP que no corresponde a ningún DC. El patrón típico es:

Workstation ── Kerberos ──► DC A
Workstation ── LDAP ─────► Host B (no es DC)

Este comportamiento genera alertas en sensores de detección (por ejemplo, CrowdStrike Identity Protection) y plantea preguntas de seguridad: ¿es legítimo que el cliente consulte LDAP en un servidor que no es controlador? ¿Podría tratarse de un túnel malicioso o de una mala configuración? El objetivo de este artículo es ofrecer una guía genérica para diagnosticar, entender y corregir este tipo de situaciones sin depender del caso concreto que originó la duda.

Causa

1. LDAP referrals y Global Catalog (GC)

Cuando un cliente consulta un objeto que no está en el dominio local, el DC puede devolver una referral a otro servidor que sí posee la información. En entornos con varios dominios, la referral suele apuntar a un GC o a un DC de otro dominio. Si el GC está configurado como un servidor dedicado (no un DC tradicional), el cliente abrirá una sesión LDAP directamente contra él.

2. Servidores de proxy LDAP (Microsoft Identity Management, Azure AD Connect)

Muchas organizaciones despliegan un proxy LDAP para:

  • Centralizar la autenticación de aplicaciones legadas.
  • Filtrar o auditar consultas.
  • Exponer un punto de entrada único a la nube (por ejemplo, Azure AD DS).

El proxy actúa como un intermediario y, aunque el ticket Kerberos se obtuvo del DC, la sesión LDAP se dirige al proxy. El proxy no es un DC, pero sí está autorizado mediante SPNs (ldap/hostname) y certificados.

3. Read‑Only Domain Controllers (RODC) y servidores de réplica parcial

Un RODC puede ofrecer servicios LDAP sin ser capaz de emitir tickets Kerberos. En algunos despliegues, los clientes usan Kerberos contra un DC primario y LDAP contra el RODC para reducir latencia. El RODC aparece como “no DC” en herramientas que solo listan DCs de escritura.

4. Configuración de clientes o aplicaciones que especifican explícitamente un host LDAP

Algunas aplicaciones (por ejemplo, software de gestión de identidades, soluciones de backup, o scripts PowerShell) incluyen parámetros como -Server "ldapproxy.company.local" y sobrescriben la detección automática. El cliente sigue usando Kerberos para autenticarse, pero la conexión LDAP se dirige al host indicado.

5. DNS SRV mal configurado o registros CNAME que apuntan a servidores no‑DC

Si los registros _ldap._tcp o _kerberos._tcp están desincronizados, el cliente puede resolver el nombre de servicio LDAP a un host que no es controlador. Esto ocurre tras migraciones incompletas o cuando se delegan zonas DNS a terceros.

6. Ataques de man‑in‑the‑middle (MITM) que manipulan respuestas DNS

En entornos con seguridad insuficiente, un atacante puede responder a consultas DNS SRV con una IP controlada, forzando al cliente a abrir LDAP contra un servidor malicioso. Este caso es raro pero crítico; la detección depende de correlacionar logs de DNS, Kerberos y LDAP.

Solución

Paso 1 – Correlacionar los registros de Kerberos y LDAP

Extrae los eventos de seguridad 4768 (Kerberos Ticket‑Granting Ticket) y 2889 (LDAP Bind) del equipo cliente. Busca coincidencias de Account Name y TimeStamp. Si el ticket proviene de DC_A y la bind LDAP apunta a Host_B, ya tienes la pista de que el cliente está usando dos endpoints.

Paso 2 – Identificar el tipo de servidor LDAP

Ejecuta una consulta LDAP anónima contra el host sospechoso para obtener su rootDSE:

ldapsearch -x -s base -b "" "(objectClass=*)" namingContexts

Los atributos isGlobalCatalogReady, dsServiceName y ldapServiceName revelan si el servidor es GC, RODC o proxy. Un isGlobalCatalogReady: TRUE indica un GC; la ausencia de dc en dsServiceName sugiere que no es un DC de escritura.

Paso 3 – Revisar la configuración de AD Sites & Services

En la consola Active Directory Sites and Services, verifica los NTDS Settings de cada servidor. Los servidores marcados como Global Catalog o Read‑Only aparecen con sus respectivos roles. Si el host B figura allí, su uso es legítimo.

Paso 4 – Auditar los SPNs registrados

Los Service Principal Names (ldap/hostname) determinan a qué máquinas se permite la autenticación Kerberos para LDAP. Usa:

setspn -L hostname

Si el SPN ldap/hostB está asignado a una cuenta de servicio distinta a un DC, el cliente está autorizado a usar ese host para LDAP.

Paso 5 – Analizar configuraciones de aplicaciones

Revisa los archivos de configuración de las aplicaciones que se ejecutan en el workstation (por ejemplo, app.config, scripts de backup, agentes de monitorización). Busca parámetros ldap:// o -Server. En PowerShell, el cmdlet Get-ItemProperty sobre la clave de registro HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History puede revelar políticas que fuerzan un servidor LDAP.

Paso 6 – Validar la integridad del DNS

Ejecuta:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain>
nslookup -type=SRV _kerberos._tcp.dc._msdcs.<domain>

Compara los resultados. Si los registros LDAP apuntan a Host_B y Kerberos a DC_A, el problema es de configuración DNS. Corrige los registros en el DNS interno o elimina los CNAME que redirijan a servidores no‑DC.

Paso 7 – Mitigar posibles MITM

Habilita DNSSEC y Secure LDAP (LDAPS). Verifica que los certificados del host LDAP sean emitidos por la CA interna y que la cadena de confianza sea válida. En caso de sospecha, captura tráfico con Wireshark y busca respuestas DNS no firmadas que apunten a IP externas.

Paso 8 – Documentar y automatizar la detección

Crea una regla de correlación en tu SIEM que combine eventos 4768 y 2889 y genere una alerta cuando los Target Server difieran. Esto permite detectar rápidamente desviaciones inesperadas en el futuro.

Cuándo aplicar esta solución

  • Síntomas: alertas de LDAP hacia IP que no aparecen en la lista de DCs, logs de CrowdStrike que indican “LDAP endpoint attribution” distinto al KDC, o auditorías de cumplimiento que requieren trazabilidad de consultas AD.
  • Entornos: cualquier dominio Windows con más de un sitio, presencia de GC, RODC o proxies LDAP.
  • No aplica: en redes totalmente aisladas donde solo exista un único DC y no se use LDAP proxy; en ese caso la discrepancia suele deberse a un error de captura o a un falso positivo del sensor.

Código

# Obtener SPNs de un host sospechoso
setspn -L hostB.example.com

# Consulta anónima al rootDSE para identificar el tipo de servidor
ldapsearch -x -s base -b "" "(objectClass=*)" namingContexts isGlobalCatalogReady dsServiceName

# Verificar registros SRV de Kerberos y LDAP
nslookup -type=SRV _kerberos._tcp.dc._msdcs.example.com
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com

Verificación

  1. Ejecuta los comandos anteriores y confirma que el host B devuelve isGlobalCatalogReady: TRUE o que su ldapServiceName coincide con el SPN registrado.
  2. En el SIEM, busca una correlación exitosa entre eventos 4768 y 2889 donde los servidores difieran; la alerta debería desaparecer después de corregir DNS o la configuración de la aplicación.
  3. Realiza una prueba de autenticación con kinit y luego una consulta LDAP con ldapsearch apuntando al host B; si la operación se completa sin errores, la ruta es funcional y legítima.

Notas adicionales

  • Los proxies LDAP suelen exponer puertos 389 (clear) y 636 (LDAPS). Si solo ves tráfico en 389, verifica que la política de cifrado de la organización permita LDAP sin TLS; de lo contrario, fuerza LDAPS para evitar intercepción.
  • En entornos híbridos con Azure AD Connect, el servidor ADFS o Azure AD DS puede actuar como endpoint LDAP. Añade sus nombres a la lista de servidores “legítimos” en tu regla de correlación.
  • Cuando uses PowerShell para depurar, el cmdlet Test-ComputerSecureChannel -Verbose ayuda a confirmar que el workstation mantiene una relación de confianza válida con el DC, lo que descarta problemas de replicación que podrían forzar consultas a servidores auxiliares.