Exigir firma LDAP y enlace de canal en los DC

Reenviar una autenticación NTLM hacia LDAP en un controlador de dominio es la ruta más directa entre «puedo hacer que una máquina se autentique ante mí» y el compromiso del dominio. Un atacante que reenvía una cuenta de equipo hacia LDAP puede configurar la delegación restringida basada en recursos en ese equipo. Un usuario privilegiado reenviado puede añadir cuentas a grupos o conceder derechos de DCSync. Herramientas como ntlmrelayx y KrbRelayUp automatizan exactamente esto, y por eso la protección de LDAP suele ser lo primero que pide un informe de pentest.

El pilar de NTLM y protocolos heredados enumera los dos valores del registro que lo corrigen. Esta guía cubre el despliegue: cómo recopilar las evidencias de cada controlador de dominio, cómo interpretar los eventos 2886 a 2889 y 3039 a 3041, qué cambiar en cada tipo de cliente y cómo pasar de la auditoría a la aplicación sin provocar una caída un lunes por la mañana.

En qué se diferencian los dos controles

Ambas configuraciones se encuentran en:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options

El enlace de canal solo existe para sesiones protegidas por TLS, por lo que presupone que sus controladores de dominio tienen un certificado LDAPS válido, normalmente emitido a partir de la plantilla Domain Controller Authentication o Kerberos Authentication. Si LDAPS nunca ha funcionado en su dominio, corríjalo primero; la guía de hardening de AD CS cubre las plantillas.

Los valores predeterminados dependen de la versión. Los controladores de dominio antiguos vienen con la firma no exigida y el enlace de canal en «nunca». Windows Server 2025 introdujo valores predeterminados más estrictos para las implementaciones nuevas y una configuración de aplicación adicional en Security Options, pero los entornos actualizados o actualizados en contexto conservan lo que estuviera configurado antes. Lea siempre los valores efectivos del registro en lugar de darlos por supuestos.

Medir: activar la telemetría

Todos los controladores de dominio registran eventos de resumen en el registro Directory Service sin ningún cambio:

Los eventos por cliente 2889 y 3039 son los que necesita, y requieren el registro de diagnóstico de la interfaz LDAP en el nivel 2. Actívelo en todos los controladores de dominio. En la mayoría de los dominios el volumen es pequeño, pero aumente el tamaño del registro Directory Service para que quepa una semana de datos.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
        -Name '16 LDAP Interface Events' -Value 2 -Type DWord
    Limit-EventLog -LogName 'Directory Service' -MaximumSize 512MB
}

Auditar: elaborar la lista de corrección

Recopile los eventos 2889 y 3039 de todos los controladores de dominio durante al menos dos semanas, incluido un cierre de mes si los sistemas financieros se enlazan a AD. El evento 2889 almacena la dirección del cliente, la identidad y el tipo de enlace en posiciones fijas: el tipo de enlace 0 es un enlace SASL sin firmar y el 1 es un enlace simple sin TLS.

$results = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 2889 } -ErrorAction SilentlyContinue |
        ForEach-Object {
            [PSCustomObject]@{
                DC       = $dc
                Client   = ($_.Properties[0].Value -split ':')[0]
                Identity = $_.Properties[1].Value
                BindType = @{ '0' = 'Unsigned SASL'; '1' = 'Simple (cleartext)' }[[string]$_.Properties[2].Value]
            }
        }
}
$results | Group-Object Client, Identity, BindType | Sort-Object Count -Descending |
    Select-Object Count, Name | Export-Csv .\ldap-unsigned-clients.csv -NoTypeInformation

# Enlace de canal: listar los mensajes 3039 sin procesar por DC
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName = 'Directory Service'; Id = 3039 } -MaxEvents 200 -ErrorAction SilentlyContinue |
        Select-Object @{n='DC';e={$dc}}, TimeCreated, Message
}

Si reenvía los eventos de forma centralizada (consulte Windows Event Forwarding), añada ambos ID a la suscripción de los controladores de dominio y consulte el recopilador.

Asigne cada IP de cliente a un responsable. Por experiencia, la lista casi siempre contiene las mismas categorías:

• Impresoras y equipos multifunción que consultan la libreta de direcciones con un enlace simple en el 389.
• Integraciones Linux y de dispositivos (concentradores VPN, firewalls, herramientas de wiki y de tickets, NAS) configuradas con un DN de enlace y una contraseña sobre LDAP sin cifrar.
• Aplicaciones Java que usan JNDI con autenticación simple.
• Scripts que usan System.DirectoryServices con AuthenticationTypes.None o autenticación básica explícita.
• Los clientes Windows rara vez son un problema: negocian la firma de forma predeterminada ("Network security: LDAP client signing requirements" = Negotiate signing) y admiten el enlace de canal desde hace años.

Corregir los clientes

Para cada origen, elija una de estas opciones, por orden de preferencia:

1. Usar SASL Kerberos o Negotiate si la biblioteca lo admite. El protocolo se encarga entonces de la firma.
2. Usar LDAPS (636) o StartTLS con la cadena de la CA empresarial como de confianza en el cliente. Esto satisface el requisito de firma. Para el enlace de canal, la biblioteca cliente también debe enviar un token de enlace; las versiones recientes de Java lo admiten mediante una propiedad de JNDI, y los clientes actuales basados en OpenLDAP varían según la versión, así que pruebe cada uno.
3. Retirar o sustituir el dispositivo si no puede hacer ninguna de las dos cosas. Un equipo multifunción que solo puede enlazarse en texto claro también expone la contraseña de su cuenta de enlace a cualquiera que esté en la red.

Cambie la contraseña de todas las cuentas que hayan aparecido en un enlace simple en texto claro: se ha enviado por la red sin protección durante todo el tiempo que haya existido la integración. Siempre que sea posible, mueva estas integraciones a cuentas dedicadas con pocos privilegios, no a cuentas de servicio reutilizadas.

Configure también la directiva del lado cliente en los equipos Windows para exigir la firma una vez que sus controladores de dominio la apliquen, de modo que un servidor LDAP fraudulento no pueda degradarlos:

Network security: LDAP client signing requirements = Require signing
HKLM\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity (DWORD) = 2

Aplicar por etapas

1. Enlace de canal a 1 (cuando se admita) en todos los controladores de dominio. Esto protege a todos los clientes que ya envían tokens, lo que incluye Windows moderno, prácticamente sin riesgo.
2. Firma exigida (LDAPServerIntegrity = 2) cuando el 2889 esté en silencio o solo muestre orígenes aceptados y con retirada programada. Empiece por un solo DC si puede dirigir hacia él los clientes restantes, y después el resto.
3. Enlace de canal a 2 (siempre) cuando el 3039 esté en silencio.

Despliegue la configuración mediante una GPO vinculada a la OU Domain Controllers para que los controladores de dominio recién promovidos la hereden. Ambas surten efecto sin reiniciar en las versiones actuales de Windows Server, pero planifique un reinicio escalonado del servicio NTDS o de los controladores de dominio en una ventana de mantenimiento si quiere tener la certeza.

Verificar

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $p = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    [PSCustomObject]@{
        DC                  = $env:COMPUTERNAME
        LDAPServerIntegrity = $p.LDAPServerIntegrity
        ChannelBinding      = $p.LdapEnforceChannelBinding
    }
} | Format-Table DC, LDAPServerIntegrity, ChannelBinding

Cada controlador de dominio debe devolver 2 y 2. Los eventos 2886 y 3041 deben dejar de aparecer tras el siguiente ciclo de 24 horas, y el 2888 debe aparecer con el número de enlaces rechazados, idealmente cero. Un recuento distinto de cero en el 2888 tras la aplicación significa que está fallando un cliente que se le pasó: los eventos de diagnóstico lo identificarán. Cuando la aplicación sea estable, devuelva el nivel de diagnóstico a 0, o manténgalo en 2 si quiere una alerta permanente ante regresiones.

Por último, vuelva a ejecutar sus herramientas de pentest o pida a su red team que repita la prueba de relay hacia LDAP. El relay debería fallar en el enlace.

Qué se rompe

• Los enlaces simples en el 389 sin TLS se rechazan en cuanto se exige la firma: libretas de direcciones de equipos multifunción, dispositivos VPN antiguos, algunos conectores de SIEM e IAM, y scripts internos. Deben migrar a LDAPS o StartTLS.
• Los clientes LDAPS sin soporte de enlace de canal fallan cuando el valor es 2: entornos de ejecución Java antiguos, algunas pilas LDAP embebidas y ciertos puentes de identidad de terceros. El valor 1 los deja funcionando, y por eso es un paso intermedio.
• La inspección TLS o los balanceadores de carga delante de los controladores de dominio que terminan TLS rompen el enlace de canal por diseño, porque el canal del cliente no es el canal del DC. No coloque los controladores de dominio detrás de dispositivos que terminen TLS.
• Los problemas de certificados se convierten en caídas: una vez que las integraciones dependen de LDAPS, un certificado de DC caducado las detiene. Supervise la caducidad de los certificados de los controladores de dominio y la inscripción automática.

Lecturas relacionadas: el tema NTLM y protocolos heredados, la entrada del glosario enlace de canal LDAP, bloquear la coerción de autenticación para eliminar los desencadenantes que los atacantes reenvían, y delegación restringida y RBCD para la escritura de delegación que suele perseguir el relay hacia LDAP.