Auditoría TLS Débil LDAPS, Spooler Impresión, Sincronización Horaria del Controlador de Dominio: Checklist de Higiene de Red

Esta es una auditoría de TLS débil en LDAPS, Spooler de Impresión y sincronización horaria del controlador de dominio: una checklist práctica para tres ajustes de red que las revisiones de Active Directory centradas en ACL y anidamiento de grupos suelen pasar por alto. Cada uno se verifica rápido, y cada uno rompe silenciosamente una garantía de seguridad distinta en cuanto un controlador de dominio se desvía de su configuración base.

Auditoría de TLS Débil en LDAPS, Spooler de Impresión y Sincronización Horaria del Controlador de Dominio

La mayoría de las revisiones de hardening de Active Directory persiguen ACL, anidamiento de grupos y rutas de delegación — y se saltan la superficie de red propia del controlador de dominio. Si trabaja desde una lista de prioridades más amplia, Hardening de Active Directory: qué bloquear primero explica dónde encaja este tipo de hardening de protocolo respecto al acceso privilegiado y los secretos reutilizables. Los tres hallazgos siguientes rara vez aparecen en un informe de permisos, pero todos son baratos de verificar y corregir una vez que se sabe dónde mirar:

Ninguno de estos tres hallazgos es nuevo. Lo que justifica agruparlos en una sola pasada de revisión es que fallan en silencio — un DC con un listener LDAPS degradado, un spooler activo o unos minutos de desviación de reloj parece completamente sano en una comprobación de estado estándar, hasta que algo fuerza la situación.

TLS Débil en LDAPS

Instalar un certificado válido en el almacén Personal del equipo local del DC habilita automáticamente LDAPS en el puerto 636 (y 3269 para el Catálogo Global) — la guía de Microsoft sobre configuración de certificados LDAP sobre SSL confirma que no se requiere configuración de servicio adicional una vez que el certificado es de confianza tanto para el DC como para sus clientes. El problema es que «LDAPS está activo» no dice nada sobre qué versiones de TLS y suites de cifrado seguirá aceptando. Un DC al que nunca se le ha endurecido Schannel negociará TLS 1.0 o 1.1, y suites de cifrado CBC/SHA1 débiles, con cualquier cliente dispuesto a ofrecerlas — como detalla la guía de DSInternals sobre forzar TLS 1.2+ para LDAPS en controladores de dominio. Esto importa porque los binds simples de LDAP llevan credenciales por la red; un cifrado degradado en el canal cifrado que debía protegerlas anula el propósito mismo de ejecutar LDAPS.

Detección

Active el registro de diagnóstico de Schannel antes de tocar nada — necesita evidencia de qué se está conectando realmente antes de deshabilitar una versión de protocolo:

# Registro detallado de eventos Schannel (detalle de protocolo/cifrado por conexión vía Event ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Enumerar las suites de cifrado actualmente habilitadas para TLS en este DC
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite devuelve la lista ordenada de suites de cifrado que Windows negociará — Microsoft documenta la referencia completa del cmdlet en Get-TlsCipherSuite (TLS). Con EventLogging activado, cada negociación Schannel hacia y desde el DC queda registrada en el registro del Sistema bajo el Event ID 36880 con la versión de protocolo y la suite de cifrado negociadas explícitas — esa es su evidencia de qué clientes o herramientas siguen forzando una degradación antes de deshabilitar nada.

Remediación

1. Confirme que ningún cliente legítimo sigue necesitando TLS 1.0/1.1 usando la evidencia del Event ID 36880 anterior.
2. Deshabilite TLS 1.0 y TLS 1.1 en el lado servidor mediante las claves de registro Protocols de Schannel, o use Disable-TlsCipherSuite para retirar las suites CBC/SHA1 débiles dejando habilitadas las suites de la clase TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
3. Reinicie el DC — los cambios de protocolo de Schannel solo surten efecto tras el reinicio.
4. Vuelva a ejecutar Get-TlsCipherSuite y revise de nuevo el Event ID 36880 para confirmar que solo negocian suites fuertes.

Spooler de Impresión en Ejecución en un Controlador de Dominio

Los controladores de dominio no imprimen nada por sí mismos, así que el servicio Spooler de Impresión no tiene ninguna razón operativa para estar en ejecución en uno — y aun así viene habilitado por defecto. El aviso PrintNightmare de CISA (CVE-2021-34527, CVSS 8.8) convirtió ese ajuste por defecto en una vía de ejecución remota de código autenticada y de bajo privilegio — la puntuación del NVD (PR:L) confirma que no hace falta más que una cuenta de dominio estándar, no privilegios de administrador — y la Directiva de Emergencia 21-04 de CISA ordenó a las agencias federales deshabilitar el spooler en todos los DC — no solo parchearlo.

Parchear tampoco resuelve el problema de diseño subyacente. Desde 2018, el «Printer Bug» (un abuso de la llamada RpcRemoteFindFirstPrinterChangeNotification en MS-RPRN) permite que cualquier usuario autenticado coaccione a un DC con el spooler activo para que se autentique contra un host controlado por el atacante — documentado en el artículo de Sean Metcalf Domain Controller Print Server + Unconstrained Kerberos Delegation. Encadenado con una cuenta que tenga delegación no restringida, esa coerción entrega el propio material de credenciales del DC; encadenado con un relay, alimenta directamente un ataque NTLM relay — la misma familia de exposición cubierta en Firma SMB deshabilitada: por qué sigue permitiendo el NTLM relay. Microsoft Defender for Identity ya ofrece esto como una evaluación de seguridad permanente que recomienda deshabilitar el Spooler de Impresión en los DC.

Detección

Compruebe todos los DC del dominio en una sola pasada — no confíe solo en el DC que recuerda haber configurado:

$dcs = Get-ADDomainController -Filter * | Sort-Object HostName
foreach ($dc in $dcs) {
    Get-Service -Name Spooler -ComputerName $dc.HostName |
        Select-Object @{N='DC';E={$dc.HostName}}, Status, StartType
}

Confirme también que no hay colas de impresión publicadas que dependan de un DC antes de tocarlo:

Get-ADObject -Filter "ObjectCategory -eq 'printQueue'"

Remediación

1. Para cada DC donde Status sea Running o StartType no sea Disabled, detenga y deshabilite el servicio:

Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName

2. Impóngalo en todo el dominio con una GPO aplicada a la OU Domain Controllers (Computer Configuration > Preferences > Control Panel Settings > Services, Spooler en Stopped/Disabled) para que un reinicio o un arranque manual no lo reactive en silencio.
3. Vuelva a ejecutar el bucle de detección tras el siguiente ciclo de actualización de la GPO para confirmar que el ajuste se mantuvo en todos los DC, incluidos los recién promovidos — un DC recién promovido arranca con el servicio Spooler de vuelta a su estado por defecto (en ejecución).

Desviación de Reloj que Nadie Vigila

Kerberos sella sus tickets con marca de tiempo para bloquear ataques de repetición, lo que significa que la autenticación depende de que el reloj de cada DC se mantenga cerca de la fuente horaria del dominio. La tolerancia la gobierna la directiva Kerberos Maximum tolerance for computer clock synchronization — 5 minutos por defecto, definida en Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, según la referencia de directivas de seguridad de Microsoft. Al superar esa tolerancia, la autenticación Kerberos falla directamente con una respuesta KRB_AP_ERR_SKEW — que se interpreta erróneamente como un problema de aplicación o de red con mucha más frecuencia de la que se diagnostica correctamente como desviación de reloj.

La jerarquía horaria del dominio solo tiene una raíz autoritativa: el emulador PDC. Cada otro DC se sincroniza desde un par de la jerarquía del dominio, y las estaciones de trabajo se sincronizan desde el DC que las autentica. Si el propio emulador PDC no apunta a una fuente externa fiable, todo el dominio puede desviarse junto sin nada con lo que discrepar — el modo de fallo que la guía de Microsoft sobre configurar el PDC raíz con una fuente de tiempo autoritativa está escrita para prevenir. Un DC que silenciosamente apunta a su propia fuente NTP independiente en lugar de a la jerarquía del dominio es igual de problemático: se convierte en una segunda autoridad horaria en competencia, que los demás DC no tienen razón para confiar más que en el emulador PDC, y depurar los fallos Kerberos intermitentes resultantes sin ese contexto puede consumir horas antes de que a alguien se le ocurra revisar w32tm.

Detección

# Estado y fuente de sincronización actuales en este DC
w32tm /query /status

# Comparar los desfases de todos los DC del dominio en una sola pasada
w32tm /monitor

Vigile el registro del Sistema en busca del Event ID 4713 (directiva Kerberos modificada — solo DC, merece una alerta si es inesperado) junto con fallos de autenticación que referencien KRB_AP_ERR_SKEW; correlacionados, apuntan directamente a la sincronización horaria en lugar de a una relación de confianza rota o credenciales caducadas.

Remediación

1. Identifique qué DC posee el rol de emulador PDC y confirme que está configurado — y no un DC par — contra una fuente NTP externa fiable en lugar del reloj de hardware interno.
2. Si el emulador PDC está desviado o mal configurado, la guía de remediación de grandes desfases horarios de Microsoft cubre cómo corregir grandes desfases con seguridad — un salto de tiempo brusco en un DC puede romper por sí mismo tickets Kerberos en curso.
3. Confirme que todos los demás DC heredan la hora desde la jerarquía del dominio (NT5DS) en lugar de una fuente independiente propia.
4. Vuelva a ejecutar w32tm /monitor tras la convergencia y confirme que todos los desfases están cómodamente por debajo de la tolerancia Kerberos de 5 minutos, no justo por debajo.

Convertir Esto en un Control Repetible, No en una Corrección Puntual

Los tres hallazgos anteriores tienen la costumbre de regresar en silencio: un DC recién promovido restaura el servicio Spooler a su estado por defecto (en ejecución), un certificado sustituido puede reintroducir en silencio un fallback a un cifrado débil, y una appliance NTP dada de baja puede dejar al emulador PDC sin aviso. Nada de esto se detecta a menos que las categorías de auditoría que lo registrarían estén realmente habilitadas — vea Brechas de Configuración de la Política de Auditoría de Active Directory si los eventos de directiva de Schannel o Kerberos no aparecen donde se esperan.

Trate esta checklist igual que trataría cualquier otro control propenso a desviarse: vuelva a ejecutarla en un calendario, no solo tras la primera corrección. Una pasada trimestral por los tres controles — suites de cifrado, estado del spooler y desfases horarios — atrapa la regresión antes de que se convierta en un incidente, y supone una fracción del esfuerzo de la remediación original. Los tres fragmentos de PowerShell anteriores son lo bastante cortos como para envolverlos en una tarea programada o un job de CI en lugar de ejecutarlos a mano cada vez.

Cómo lo Detecta EtcSec

La categoría Red de EtcSec comprueba estos tres hallazgos en cada auditoría de AD: DC_LDAPS_WEAK_TLS marca los controladores de dominio cuyo listener LDAPS sigue negociando una versión TLS débil, DC_SPOOLER_ACCESSIBLE marca cualquier controlador de dominio con el servicio Spooler de Impresión accesible, y DC_TIME_SYNC_ISSUE (junto con NTP_NOT_CONFIGURED) marca los DC que se desvían de la fuente horaria autoritativa del dominio o a los que les falta un par NTP configurado.