What Is firma LDAP deshabilitada?
Una firma LDAP deshabilitada significa que un controlador de dominio de Active Directory todavía acepta tráfico LDAP sin protección de integridad en la ruta de enlace que usa el cliente. La guía de Microsoft es clara: los enlaces SASL LDAP sin firma y los enlaces simples LDAP sobre una conexión sin SSL/TLS deben rechazarse porque exponen el servicio de directorio a ataques de repetición y manipulación man-in-the-middle. En el caso de un enlace simple en texto claro, también pueden exponer credenciales directamente en la red.
En la práctica, la debilidad aparece cuando el equipo deja la directiva del controlador de dominio en un estado permisivo porque una aplicación antigua, un script, un dispositivo o una integración de directorio todavía depende de un comportamiento LDAP débil. El directorio sigue disponible, pero la confianza que el controlador de dominio deposita en ese tráfico es demasiado amplia. LDAP no es un canal secundario en Active Directory. Es uno de los principales planos de control para consultar usuarios, grupos, equipos y objetos sensibles que determinan privilegios.
La firma LDAP deshabilitada suele aparecer durante una revisión más amplia como Cómo auditar la seguridad de Active Directory: guía práctica para equipos internos, pero merece su propia línea de remediación porque la corrección suele recaer tanto en propietarios de aplicaciones como en administradores de directorio.
How firma LDAP deshabilitada Works
Microsoft documenta dos patrones de riesgo que la firma LDAP debe bloquear en los controladores de dominio:
- enlaces SASL LDAP que no solicitan firma
- enlaces simples LDAP realizados en texto claro en lugar de usar SSL/TLS
Cuando se exige la firma, el cliente y el servidor firman criptográficamente la sesión LDAP para impedir que un intermediario modifique el flujo de solicitudes sin ser detectado. Cuando todavía se necesitan enlaces simples, la recomendación de Microsoft es protegerlos con SSL/TLS en lugar de permitirlos en texto claro.
También es importante no confundir la firma LDAP con el channel binding LDAP. La firma protege la integridad de la sesión LDAP. El channel binding es una medida distinta para sesiones LDAP protegidas por TLS y se controla con otro conjunto de eventos y políticas. En entornos reales, ambos temas suelen corregirse juntos, pero no son lo mismo.
| Patrón LDAP | Aceptado cuando la firma LDAP está deshabilitada | Riesgo principal |
|---|---|---|
| Enlace SASL sin firma | Sí, si el DC sigue siendo permisivo | Repetición y alteración del tráfico LDAP |
| Enlace simple sobre LDAP en texto claro | Sí, si el DC sigue siendo permisivo | Exposición de credenciales en la red |
| Enlace simple sobre LDAPS | A veces sigue siendo necesario para aplicaciones heredadas | Transporte cifrado, pero el diseño aún debe revisarse |
| Enlace SASL con firma | Estado seguro esperado | Tráfico LDAP protegido en integridad |
Microsoft también señala un cambio importante: Windows Server 2025 habilita la firma LDAP por defecto en nuevas implementaciones de Active Directory. Eso confirma que ya no es un ajuste opcional de hardening, sino una expectativa básica.
The Attack Chain
Paso 1 - Encontrar la ruta heredada que sigue usando LDAP débil
Los atacantes no necesitan empezar con una cuenta Domain Admin. Su primer objetivo suele ser el sistema, script, jump box o aplicación heredada que todavía realiza enlaces LDAP débiles contra un controlador de dominio. En auditorías internas, esta ruta suele identificarse con el mismo trabajo que Monitorización de seguridad de Active Directory: eventos que importan: descubrir qué clientes siguen haciendo enlaces SASL sin firma o enlaces simples en texto claro y quién es su propietario operativo.
# Ejemplo de enlace simple LDAP en texto claro
ldapsearch -x -H ldap://dc01.corp.local -D 'CORP\svc_legacyapp' -W -b 'DC=corp,DC=local' '(objectClass=user)'
Si una ruta de aplicación depende todavía de un enlace simple en texto claro, el verdadero problema no es solo el comando. Es que el controlador de dominio sigue siendo lo bastante permisivo como para aceptarlo.
Paso 2 - Interceptar o alterar tráfico LDAP débil
La documentación de Microsoft sobre firma LDAP menciona de forma explícita el riesgo de repetición y man-in-the-middle sobre tráfico no firmado. Si la ruta de enlace no está protegida en integridad, un atacante situado en la red puede alterar solicitudes LDAP o reutilizar material de autenticación de formas que el entorno ya no debería permitir.
Por eso la firma LDAP deshabilitada suele solaparse operacionalmente con Ataques NTLM Relay: secuestro de la autenticación en AD. No son el mismo problema, pero ambos reducen la confianza que puede tenerse en el tráfico de autenticación y directorio que cruza la red.
Paso 3 - Convertir acceso al directorio en más privilegios
Una vez que el atacante puede confiar en esa ruta LDAP débil, el siguiente paso no siempre es comprometer el dominio de inmediato. Con más frecuencia empieza una fase de reconocimiento de directorio y cartografía de privilegios:
- enumerar grupos privilegiados y delegaciones
- localizar cuentas de servicio sensibles y objetos de aplicación críticos
- identificar rutas que después faciliten abuso de ACL, GPO o cuentas demasiado expuestas
La misma lógica aparece en Rutas de ataque de Active Directory hacia Domain Admin: una debilidad en el plano de control del directorio se vuelve más grave cuando ayuda al atacante a mapear el camino más corto hacia objetos privilegiados.
Detection
La vía de detección más limpia se apoya en los eventos Directory Service documentados por Microsoft para la firma LDAP.
| Indicador | Event ID | Fuente | Qué confirma |
|---|---|---|---|
| El DC sigue siendo permisivo | 2886 | Registro Directory Service | Recordatorio de que el servidor debería rechazar enlaces débiles |
| Se observaron enlaces débiles en 24 horas | 2887 | Registro Directory Service | Resumen de enlaces SASL sin firma y enlaces simples en texto claro |
| Los enlaces débiles están siendo rechazados | 2888 | Registro Directory Service | Confirma que la aplicación de la política ya está activa |
| Detalle por cliente | 2889 | Registro Directory Service | Da la IP origen y la identidad utilizada |
| Auditoría de channel binding LDAP | 3039, 3040, 3041, 3074, 3075 | Registro Directory Service | Útil si también se endurece channel binding |
Para priorizar bien, empiece por el Event 2887 y compruebe si el problema sigue activo. Si lo está, aumente la verbosidad de LDAP Interface Events para que el Event 2889 le dé la IP concreta y la identidad usada. Eso permite asignar la corrección al verdadero propietario de la aplicación.
# Leer los eventos clave de firma LDAP en un DC
Get-WinEvent -LogName 'Directory Service' |
Where-Object { $_.Id -in 2886,2887,2888,2889,3039,3040,3041,3074,3075 } |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Durante la remediación conviene correlacionar estos eventos con una revisión más amplia como Conformidad AD y Azure: NIS2, ISO 27001 y CIS Controls. La firma LDAP es uno de esos controles que suelen existir en políticas escritas mucho antes de aplicarse de verdad en producción.
Remediation
💡 Quick Win: use primero los eventos 2887 y 2889. Identifique todos los clientes que todavía dependen de enlaces SASL sin firma o de enlaces simples LDAP en texto claro antes de obligar a los DC a rechazarlos.
Una secuencia de remediación útil suele seguir este orden:
- Inventariar clientes débiles. Revise el resumen del 2887 y habilite eventos más detallados para que 2889 identifique los sistemas origen.
- Corregir el comportamiento del cliente. Actualice la aplicación, el driver, el appliance o el script para que pida firma en SASL o use SSL/TLS para enlaces simples.
- Exigir firma en los controladores de dominio. En la política, cambie Domain controller: LDAP server signing requirements a Require signing.
- Revisar la política del cliente. Use Network security: LDAP client signing requirements para impedir que equipos Windows gestionados sigan iniciando sesiones LDAP débiles.
- Volver a probar las aplicaciones dependientes. Valide el comportamiento de enlace en rutas realmente usadas en producción.
- Vigilar intentos residuales. Tras la aplicación, supervise 2888 y 2889 para encontrar sistemas que aún requieran atención.
# Ejemplo de validación de política en un host Windows
secedit /export /cfg C:\Temp\secpol.cfg
Select-String -Path C:\Temp\secpol.cfg -Pattern 'LDAP'
La trampa operativa más común es forzar el ajuste sin coordinarlo con los propietarios de aplicaciones. La firma LDAP debe imponerse, pero la vía más segura consiste en inventariar dependencias, migrarlas y probarlas de nuevo. Esto es todavía más importante si el entorno ya arrastra Mala configuración de GPO: cuando Group Policy se convierte en vector de ataque u otros problemas de higiene.
Validate Before You Close the Finding
La validación final debe demostrar algo más que un cambio de GPO. Vuelva a ejecutar la misma prueba que identificó al cliente débil, confirme que ahora usa firma o LDAPS según corresponda y obtenga la validación del propietario de la aplicación sobre el flujo real. Los problemas de firma LDAP suelen sobrevivir mediante excepciones olvidadas, cuentas de servicio nunca revisadas o appliances que nadie volvió a probar después del cambio de política.
Si el entorno también muestra exposición a relay en servicios cercanos, documéntelo de forma explícita. En muchos entornos, el mismo sistema que todavía usa LDAP débil también mantiene condiciones asociadas a NTLM_RELAY_OPPORTUNITY. Capturar esa relación ayuda a cerrar la dependencia de manera duradera.
How EtcSec Detects This
EtcSec vincula esta debilidad directamente con LDAP_SIGNING_DISABLED, y suele ser útil revisarla junto con NTLM_RELAY_OPPORTUNITY cuando el tráfico de directorio débil y los caminos de red aptos para relay aparecen a la vez. Lo importante no es solo saber que la configuración es débil, sino confirmar si la política del DC sigue siendo permisiva, si los clientes débiles continúan activos y si la corrección recae en ingeniería AD o en un equipo de aplicación.
ℹ️ Note: EtcSec comprueba automáticamente debilidades de firma LDAP en cada auditoría de Active Directory para distinguir entre una política correcta sobre el papel y un control realmente aplicado en controladores de dominio activos.
Official References
- Microsoft Learn: LDAP signing for Active Directory Domain Services on Windows Server
- Microsoft Learn: Manage LDAP signing using Group Policy for Active Directory Domain Service
- Microsoft Learn: How to enable LDAP signing in Windows Server
- Microsoft Support KB4520412: LDAP channel binding and LDAP signing requirements for Windows
Related Reading
Si está corrigiendo la firma LDAP, revísela junto con Ataques NTLM Relay: secuestro de la autenticación en AD, Monitorización de seguridad de Active Directory: eventos que importan, Rutas de ataque de Active Directory hacia Domain Admin, Mala configuración de GPO: cuando Group Policy se convierte en vector de ataque y Seguridad de contraseñas en Active Directory: configuraciones erróneas que sí importan. El hardening LDAP es más fuerte cuando la confianza de red, la confianza en el directorio y las rutas de privilegio se revisan juntas.
