Aviso ético y legal: todos los comandos, claves de registro y objetos de directiva de grupo (GPO) de este módulo se explican con fines educativos y deben aplicarse exclusivamente en entornos de laboratorio propios o en infraestructuras de producción sobre las que tengas autorización explícita por escrito para operar. Desactivar protocolos de autenticación o compartición de archivos en un dominio de Active Directory (AD) real sin una fase previa de auditoría puede provocar caídas de servicio, aplicaciones de línea de negocio inoperativas o bloqueos de acceso masivos. Actúa siempre bajo un cambio autorizado (RFC/CAB), con ventana de mantenimiento y plan de rollback documentado.
Qué aprenderás
- Por qué las organizaciones acumulan deuda técnica en sus controladores de dominio (DC) y qué riesgo real representa cada nivel funcional obsoleto.
- Cómo inventariar de forma sistemática el uso de SMBv1, NTLMv1/LM, cifrado Kerberos débil (RC4/DES) y LDAP sin firmar en un bosque de AD.
- Los comandos PowerShell modernos y sus equivalentes legacy (
dsquery,nltest,net use) para auditar y para desactivar cada protocolo por fases. - Las claves de registro exactas y las rutas de GPO implicadas en cada endurecimiento (hardening).
- Una estrategia segura y reversible para elevar niveles funcionales de dominio y bosque.
- Cómo tratar sistemas que no se pueden actualizar mediante aislamiento y segmentación, sin dejarlos como puerta abierta al resto del dominio.
- La ruta de migración realista 2003 → 2008 R2 → 2012 R2 → 2016 → 2019/2022 → 2025 y los saltos de migración que sí están soportados.
1. El problema real: por qué sigue habiendo Windows Server 2003 en producción en 2026
En cualquier auditoría de Active Directory con más de diez años de antigüedad os vais a encontrar patrones repetidos: un controlador de dominio con NTDS.DIT heredado de un dcpromo de 2006, un nivel funcional de dominio (DFL) y de bosque (FFL) congelado en Windows2003Domain porque «hay una aplicación de facturación que no se puede tocar», y una superficie de ataque NTLM/SMBv1 que ningún responsable de sistemas quiere auditar por miedo a romper algo. Esto no es un caso aislado: es el escenario más habitual en pymes, administraciones públicas y entornos industriales (OT) con controladores lógicos programables (PLC) que hablan SMBv1 de forma nativa.
El riesgo no es teórico. Los ransomware operators actuales (familias derivadas de Conti, LockBit, y sus sucesores) siguen incluyendo en su playbook de movimiento lateral la explotación de:
- SMBv1 vulnerable a EternalBlue (MS17-010) y a ataques de downgrade forzado.
- NTLMv1/LM susceptibles de relay (NTLM Relay) y de cracking offline casi instantáneo con tablas rainbow por el uso de DES de 56 bits partido en dos mitades de 7 bytes.
- Kerberos con RC4-HMAC (etype 0x17), vector de Kerberoasting masivo porque el hash RC4 se puede fuerza-bruta a velocidades de GPU muy superiores a AES256.
- LDAP sin firmar y sin channel binding, vector de NTLM relay to LDAP que llevó a Microsoft a publicar en 2019 el aviso ADV190023 y, posteriormente, a reforzar el comportamiento por defecto de LDAP channel binding/signing en las actualizaciones de marzo-abril de 2023 en Windows Server.
La dificultad no es identificar que esto es un problema. La dificultad es desactivarlo sin tirar la producción. Este módulo trata sobre cómo hacerlo en fases: inventariar → auditar en modo «solo registro» → comunicar a los propietarios de aplicaciones → desactivar en anillos progresivos → verificar → confirmar.
2. Inventariar lo legacy: el primer paso obligatorio
Antes de tocar nada hay que saber qué hay. Un error muy común es lanzar Set-SmbServerConfiguration -EnableSMB1Protocol $false en todos los DC un viernes por la tarde sin haber comprobado antes qué lo usa.
2.1 Inventario de sistemas operativos de DC y miembros
# Listar todos los controladores de dominio y su SO (PowerShell moderno, RSAT-AD-PowerShell)
Get-ADDomainController -Filter * -Server (Get-ADDomain).PDCEmulator |
Select-Object Name, OperatingSystem, OperatingSystemVersion, Site, IsGlobalCatalog |
Sort-Object OperatingSystemVersion
# Inventario de TODOS los equipos del dominio (miembros incluidos), agrupado por SO
Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonTimestamp |
Group-Object OperatingSystem |
Select-Object Name, Count |
Sort-Object Count -Descending
# Equivalente legacy con dsquery/dsget (funciona incluso desde un DC 2008 R2 sin módulo AD)
dsquery computer -limit 0 | dsget computer -samid -desc
El objetivo de esta consulta es doble: identificar DC candidatos a jubilación (2003, 2008 sin R2, 2008 R2 fuera de soporte extendido) y detectar estaciones/servidores miembro tan antiguos que solo pueden hablar SMBv1 y NTLMv1 (Windows XP, Server 2003, algunos NAS embebidos con Samba antiguo, controladoras SCADA).
2.2 Niveles funcionales actuales
# Nivel funcional de dominio y de bosque
Get-ADDomain | Select-Object Name, DomainMode
Get-ADForest | Select-Object Name, ForestMode
# Equivalente legacy
dsquery * "cn=partitions,cn=configuration,dc=tudominio,dc=local" -scope base -attr msDS-Behavior-Version
| Valor DomainMode / ForestMode | Nivel funcional | DC mínimo soportado |
|---|---|---|
| 0 | Windows2000Domain | Windows 2000 Server (fuera de soporte hace más de 15 años) |
| 1 | Windows2003InterimDomain | Transición NT4 → 2003, prácticamente inexistente hoy |
| 2 | Windows2003Domain | Windows Server 2003 |
| 3 | Windows2008Domain | Windows Server 2008 |
| 4 | Windows2008R2Domain | Windows Server 2008 R2 |
| 5 | Windows2012Domain | Windows Server 2012 |
| 6 | Windows2012R2Domain | Windows Server 2012 R2 |
| 7 | Windows2016Domain | Windows Server 2016 |
| 10 | Windows2025Domain | Windows Server 2025 (no existe nivel «2019»/»2022″ propio; ambos operan bajo el nivel 2016 como techo hasta 2025) |
Nota importante de examen: no existe un DomainMode específico «2019» ni «2022». Windows Server 2019 y 2022 pueden actuar como DC en un dominio cuyo nivel funcional máximo sea Windows2016Domain (valor 7) hasta la llegada de Windows Server 2025, que introduce el nivel funcional propio 10. Esto es una fuente de confusión habitual en certificaciones y en entrevistas técnicas.
2.3 Inventario de uso de NTLM mediante auditoría nativa
Windows incorpora desde Windows 7 / Server 2008 R2 un mecanismo de auditoría de NTLM que no bloquea nada, solo registra. Es la herramienta clave de la fase de inventario y se activa por GPO:
Ruta GPO: Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad
| Directiva | Valor recomendado en fase de auditoría |
|---|---|
| Network security: Restrict NTLM: Audit Incoming NTLM Traffic | Enable auditing for all accounts |
| Network security: Restrict NTLM: Audit NTLM authentication in this domain | Enable all |
| Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers | Audit all |
Rutas de registro equivalentes (aplicables directamente si no se quiere pasar por GPO, por ejemplo en un laboratorio):
# En cada DC: auditar tráfico NTLM entrante
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
-Name "AuditReceivingNTLMTraffic" -PropertyType DWord -Value 2 -Force
# Auditar NTLM saliente hacia servidores remotos (en estaciones/miembros)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
-Name "RestrictSendingNTLMTraffic" -PropertyType DWord -Value 1 -Force
# Auditar autenticación NTLM en el propio dominio (en cada DC)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonParameters" `
-Name "AuditNTLMInDomain" -PropertyType DWord -Value 7 -Force
Con esto activo, el visor de eventos de cada DC empieza a generar los IDs clave del canal Aplicaciones y servicios → Microsoft → Windows → NTLM → Operational:
| Event ID | Significado |
|---|---|
| 8001 | El DC bloqueó la autenticación NTLM entrante (solo se ve cuando ya se ha pasado a modo «deny») |
| 8002 | El DC permitió NTLM entrante que habría sido bloqueado si la directiva estuviera en modo restrictivo (auditoría) |
| 8003 | La estación bloqueó NTLM saliente hacia un servidor remoto |
| 8004 | NTLM saliente que habría sido bloqueado, en modo auditoría — el más útil para inventariar quién sigue pidiendo NTLM |
Consulta práctica para extraer, de un DC, todos los orígenes (IP/nombre de equipo) que están autenticando con NTLM en lugar de Kerberos, filtrando por el evento 8004 en un servidor miembro o el 4624 (LogonType con paquete NTLM) en el propio DC:
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
Where-Object { $_.Id -in 8001,8002,8003,8004 } |
Select-Object TimeCreated, Id, Message |
Export-Csv -Path C:auditoriantlm-inventario.csv -NoTypeInformation -Encoding UTF8
# Complementario: eventos de inicio de sesión 4624 con PackageName NTLM (no Kerberos) en el DC
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5000 |
Where-Object { $_.Message -match "NTLM" } |
Select-Object TimeCreated, @{n='Origen';e={($_.Properties[18]).Value}}
Este inventario debe mantenerse activo varias semanas (mínimo un ciclo de facturación/cierre mensual, idealmente un trimestre) antes de plantear ningún bloqueo, porque hay procesos batch nocturnos o mensuales que solo aparecen esporádicamente.
3. SMBv1: el protocolo que hay que erradicar primero
SMBv1 (Server Message Block versión 1, también llamado CIFS en su forma más antigua) es el protocolo de compartición de archivos e impresoras de Windows NT 4 / 2000 / XP / Server 2003. No tiene firmado por defecto, es vulnerable a EternalBlue/EternalRomance (explotados por WannaCry y NotPetya) y a ataques de downgrade incluso cuando SMBv2/v3 está disponible, porque el cliente negocia la versión más baja que el servidor le ofrezca si no se fuerza lo contrario.
3.1 Auditar SMBv1 antes de tocar nada
# Ver si el cliente y el servidor SMB1 están instalados/habilitados (Windows 8.1/Server 2012 R2 en adelante)
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
# Activar auditoría de SMB1 SIN desactivar el protocolo (evento 3000 en el canal SMBServer/Audit)
Set-SmbServerConfiguration -AuditSmb1Access $true -Confirm:$false
Con la auditoría activa, cada vez que un cliente intente negociar SMBv1 contra ese servidor se generará el evento 3000 en Aplicaciones y servicios → Microsoft → Windows → SMBServer → Audit, indicando el nombre de cliente y el usuario. Recolectarlo centralizadamente:
Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" |
Where-Object { $_.Id -eq 3000 } |
Select-Object TimeCreated, @{n='Cliente';e={$_.Properties[1].Value}}, @{n='Usuario';e={$_.Properties[2].Value}} |
Sort-Object Cliente -Unique |
Export-Csv C:auditoriasmb1-clientes.csv -NoTypeInformation -Encoding UTF8
Esta consulta te da, en un CSV limpio, exactamente qué máquinas y qué usuarios siguen dependiendo de SMBv1. Es el insumo para negociar con los propietarios de aplicaciones antes de bloquear nada.
3.2 Desactivación por fases
- Fase 0 — auditoría (sección 3.1), mínimo 30 días.
- Fase 1 — anillo piloto: desactivar SMBv1 en un grupo reducido de servidores no críticos y en estaciones de IT, comprobando que nada se rompe.
- Fase 2 — desactivar el cliente SMB1 de forma general (menor impacto que desactivar el servidor, porque casi nadie necesita conectarse a otro equipo por SMB1, solo ser servidor SMB1 para NAS/impresoras antiguas).
- Fase 3 — desactivar el servidor SMB1 en todos los DC y servidores de ficheros, salvo excepciones documentadas y aisladas (sección 6).
- Fase 4 — desinstalar la característica opcional completa (no solo desactivarla vía registro) para eliminar el binario del sistema.
# Fase 2: desactivar SOLO el cliente SMB1 (Windows 10/11 y Server 2016+)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client -NoRestart
# Fase 3: desactivar el servidor SMB1 vía PowerShell moderno
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Confirm:$false
# Fase 4: desinstalación completa de la característica (recomendado, no reversible sin reinstalar el paquete)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
# Equivalente legacy vía registro directo (Server 2008 R2 / Windows 7, sin cmdlets SMB modernos)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters" `
-Name "SMB1" -Value 0 -PropertyType DWord -Force
# Requiere reinicio del servicio LanmanServer o del equipo
# Verificación por GPO centralizada (aplicar a nivel de dominio una vez validado el piloto)
# GPO: Computer Configuration > Preferences > Windows Settings > Registry
# Hive: HKEY_LOCAL_MACHINE
# Path: SYSTEMCurrentControlSetServicesLanmanServerParameters
# Value name: SMB1, Type: REG_DWORD, Value: 0
Nota de compatibilidad crítica: Windows Server 2003 solo habla SMBv1. Si aún tenéis un DC 2003 vivo (algo que no debería ocurrir en 2026 pero sigue apareciendo en auditorías de sector industrial y sanitario), desactivar SMBv1 en el resto del dominio lo dejará incomunicado para tareas de replicación de ficheros vía SYSVOL/DFS-R heredado. La única solución correcta no es «mantener SMBv1 abierto», es retirar ese DC (sección 7).
4. NTLMv1 y LM: forzar Kerberos y subir el nivel de compatibilidad
El parámetro que gobierna qué protocolos de reto-respuesta acepta y envía un equipo es LmCompatibilityLevel, controlado por la directiva «Network security: LAN Manager authentication level».
Ruta GPO: Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad → Network security: LAN Manager authentication level
Ruta de registro: HKLMSYSTEMCurrentControlSetControlLsaLmCompatibilityLevel (DWORD)
| Nivel | Descripción | Uso recomendado |
|---|---|---|
| 0 | Enviar respuestas LM y NTLM; nunca NTLMv2 | Nunca. Solo aparece en sistemas anteriores a NT4 SP4 |
| 1 | Enviar LM y NTLM; usar NTLMv2 si el servidor lo soporta | Nunca en 2026 |
| 2 | Enviar solo respuesta NTLM (v1) | Nunca en 2026 |
| 3 | Enviar solo respuesta NTLMv2 | Mínimo aceptable en la fase de transición de clientes |
| 4 | Enviar solo NTLMv2; el DC rechaza LM | Objetivo intermedio |
| 5 | Enviar solo NTLMv2; el DC rechaza LM y NTLMv1 | Objetivo final recomendado antes de restringir NTLM por completo |
# Comprobar el valor actual en un equipo
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" -Name "LmCompatibilityLevel" -ErrorAction SilentlyContinue
# Si la clave no existe, el valor efectivo por defecto varía según versión de SO (Server 2008 R2+ ya usa 3 por defecto)
# Establecer nivel 5 (objetivo final) — SOLO tras confirmar que no quedan clientes NTLMv1/LM en el inventario del apartado 2.3
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
-Name "LmCompatibilityLevel" -Value 5 -PropertyType DWord -Force
# Equivalente legacy: net.exe no expone este parámetro; se gestiona por secedit/GPO en dominios 2003/2008
secedit /export /cfg C:auditoriasecpol-actual.inf
# revisar manualmente la línea LSAAnonymousNameLookup / LmCompatibilityLevel en el .inf antes de reimportar
Además de LmCompatibilityLevel, hay que revisar dos parámetros hermanos que también contribuyen a la superficie NTLM débil:
# Impedir el almacenamiento del hash LM en el SAM/NTDS (independiente del nivel de compatibilidad)
# Ruta GPO: Network security: Do not store LAN Manager hash value on next password change
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
-Name "NoLmHash" -Value 1 -PropertyType DWord -Force
# Restringir NTLM de forma granular una vez completada la auditoría del apartado 2.3
# Ruta GPO: Network security: Restrict NTLM: NTLM authentication in this domain
# Valores: 0=Disable, 1=Deny for domain accounts to domain servers, ... 6=Deny all
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonParameters" `
-Name "RestrictNTLMInDomain" -Value 6 -PropertyType DWord -Force
El paso de nivel 3/4 a nivel 6 (Deny all) en RestrictNTLMInDomain es el que efectivamente «apaga» NTLM en el dominio. No debe hacerse nunca sin haber pasado antes por la fase de auditoría con eventos 8001-8004 descrita en el apartado 2.3, porque hay servicios muy comunes que todavía dependen de NTLM explícitamente: agentes de backup antiguos, algunos RDP gateway mal configurados, aplicaciones .NET que llaman a NetworkCredential sin negociar Kerberos, y cualquier acceso por dirección IP en lugar de nombre DNS (Kerberos necesita SPN resoluble, así que \10.0.0.5recurso siempre cae a NTLM aunque todo lo demás esté bien configurado).
5. RC4/DES en Kerberos: migrar a AES
Kerberos soporta varios tipos de cifrado (encryption typesetypes) para las claves de sesión y los tickets. Los históricos DES-CBC-CRC (etype 1) y DES-CBC-MD5 (etype 3) llevan deprecados desde Windows Server 2008 y deshabilitados por defecto desde Windows Server 2008 R2. El riesgo actual y vigente es RC4-HMAC (etype 0x17 / 23), que sigue activo por defecto en muchísimos dominios porque es el fallback automático cuando una cuenta de servicio no tiene marcado explícitamente el soporte de AES.
El atributo que controla esto por cuenta (usuario, equipo o cuenta de servicio gestionada) es msDS-SupportedEncryptionTypes.
# Ver qué etypes soporta una cuenta de servicio concreta
Get-ADUser -Identity svc_backup -Properties msDS-SupportedEncryptionTypes |
Select-Object Name, msDS-SupportedEncryptionTypes
# Tabla de bits del atributo (es una máscara, se pueden combinar con OR):
# 0x1 = DES-CBC-CRC
# 0x2 = DES-CBC-MD5
# 0x4 = RC4-HMAC
# 0x8 = AES128-CTS-HMAC-SHA1-96
# 0x10 = AES256-CTS-HMAC-SHA1-96
# 0x800000 = "usar los etypes por defecto del futuro" (bit de compatibilidad)
# Forzar SOLO AES256+AES128 en una cuenta de servicio (valor 24 = 0x8 + 0x10)
Set-ADUser -Identity svc_backup -Replace @{'msDS-SupportedEncryptionTypes' = 24}
# Buscar en todo el dominio las cuentas que todavía NO tienen ningún bit AES marcado
# (es decir, dependen de RC4 o DES por defecto)
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
Where-Object {
$_.ServicePrincipalName -and
( -not $_.'msDS-SupportedEncryptionTypes' -or ($_.'msDS-SupportedEncryptionTypes' -band 0x18) -eq 0 )
} |
Select-Object Name, DistinguishedName |
Export-Csv C:auditoriacuentas-sin-aes.csv -NoTypeInformation -Encoding UTF8
Esta última consulta es, en la práctica, tu lista de cuentas Kerberoasteables de forma trivial: si tienen SPN y no fuerzan AES, un atacante con cualquier cuenta autenticada del dominio puede solicitar un ticket de servicio para ellas y crackear el hash RC4 offline sin generar ningún evento adicional más allá del propio 4769 de solicitud de ticket (que es tráfico legítimo y pasa desapercibido en la mayoría de los SIEM mal ajustados).
Deshabilitar RC4 a nivel de DC (no solo por cuenta) se controla con la directiva «Network security: Configure encryption types allowed for Kerberos»:
Ruta GPO: Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad
Ruta de registro: HKLMSYSTEMCurrentControlSetControlLsaKerberosParametersSupportedEncryptionTypes
# Forzar SOLO AES128+AES256 a nivel de sistema (equivale a marcar solo esas dos casillas en la GPO)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaKerberosParameters" `
-Name "SupportedEncryptionTypes" -Value 24 -PropertyType DWord -Force
Advertencia de secuenciación: aplicar esta directiva a nivel de DC antes de haber saneado el atributo msDS-SupportedEncryptionTypes de todas las cuentas de servicio provoca fallos de autenticación Kerberos en cadena (KRB_AP_ERR_MODIFIED, errores de confianza entre bosques que aún dependan de RC4 en trusts antiguos). El orden correcto es: 1) auditar cuentas sin AES, 2) migrar cuentas una a una o por lotes verificando cada aplicación, 3) solo entonces restringir a nivel de DC/GPO.
6. LDAP sin firma y sin channel binding
El tráfico LDAP sin firmar permite ataques de NTLM relay to LDAP: un atacante en posición de machine-in-the-middle intercepta una autenticación NTLM y la retransmite contra el LDAP del DC para crear objetos, modificar ACL o incluso obtener privilegios de Domain Admin mediante técnicas de relay a resource-based constrained delegation. Microsoft respondió a esto de forma masiva a partir de las actualizaciones de marzo de 2020 (auditoría) y marzo-abril de 2023 (LDAP channel binding reforzado por defecto en instalaciones nuevas).
6.1 Auditar antes de forzar la firma
Activar el nivel de diagnostics logging del servicio de directorio para registrar conexiones LDAP no firmadas:
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNTDSDiagnostics" `
-Name "16 LDAP Interface Events" -Value 2 -PropertyType DWord -Force
Esto genera en el Directory Service log del DC los eventos clave para el inventario:
| Event ID | Significado |
|---|---|
| 2886 | El DC tiene LDAP signing en modo permisivo (aviso de configuración, no de tráfico) |
| 2887 | Resumen periódico (cada 24h) del número de binds LDAP simples/no firmados aceptados desde el último reinicio — el más útil para saber «cuánto tráfico débil hay» |
| 2888 | El DC empezaría a rechazar binds no firmados si se activa el modo estricto (aparece solo tras activar auditoría reforzada) |
| 2889 | Un cliente concreto realizó un bind LDAP simple o sin firmar — incluye IP de origen y cuenta, es el evento para identificar qué hay que arreglar |
Get-WinEvent -LogName "Directory Service" |
Where-Object { $_.Id -eq 2889 } |
Select-Object TimeCreated, @{n='IPOrigen';e={$_.Properties[0].Value}}, @{n='Cuenta';e={$_.Properties[1].Value}} |
Sort-Object IPOrigen -Unique |
Export-Csv C:auditorialdap-sin-firmar.csv -NoTypeInformation -Encoding UTF8
6.2 Forzar LDAP signing y channel binding
Ruta GPO firma: Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad → Domain controller: LDAP server signing requirements → valor Require signing
# Registro equivalente para forzar firma LDAP en el DC
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNTDSParameters" `
-Name "LDAPServerIntegrity" -Value 2 -PropertyType DWord -Force
# Channel binding para LDAP sobre SSL/TLS (mitigación específica de ADV190023 / CVE-2017-8563 y derivados)
# 0 = No, 1 = Cuando sea posible (recomendado en fase de transición), 2 = Siempre (objetivo final)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNTDSParameters" `
-Name "LdapEnforceChannelBinding" -Value 1 -PropertyType DWord -Force
Igual que en los apartados anteriores, el salto directo a LDAPServerIntegrity = 2 sin haber revisado los eventos 2887/2889 rompe con frecuencia: switches y controladoras de red que consultan LDAP simple para autenticación 802.1X, appliances de terceros (balanceadores, VPN, NAS) configurados con bind anónimo o simple contra el DC, y herramientas de auditoría/backup de AD antiguas que no soportan LDAPS ni SASL.
7. Tabla resumen: protocolo obsoleto, riesgo, auditoría y desactivación por fases
| Protocolo | Riesgo principal | Cómo auditarlo | Cómo desactivarlo por fases |
|---|---|---|---|
| SMBv1 | EternalBlue/EternalRomance (MS17-010), ransomware con propagación tipo gusano, sin firmado por defecto | Set-SmbServerConfiguration -AuditSmb1Access $true; evento 3000 en SMBServer/Audit |
Auditar (30 días) → desactivar cliente SMB1 → desactivar servidor SMB1 en anillo piloto → generalizar → desinstalar la característica |
| NTLMv1 / LM | Cracking offline casi inmediato del hash LM (DES 56 bits partido); NTLM relay | Auditoría NTLM nativa (eventos 8001-8004 en NTLM/Operational); LmCompatibilityLevel actual |
Subir LmCompatibilityLevel de 3→4→5 por anillos; NoLmHash=1; solo al final RestrictNTLMInDomain=6 |
| RC4/DES en Kerberos | Kerberoasting con crackeo GPU rápido de tickets de servicio RC4; DES ya deshabilitado por defecto desde 2008 R2 | Revisar msDS-SupportedEncryptionTypes por cuenta con SPN; eventos 4769 con etype 0x17 |
Marcar AES en cuentas de servicio una a una → validar aplicación → forzar SupportedEncryptionTypes=24 (AES only) a nivel de DC |
| LDAP sin firma / sin channel binding | NTLM relay to LDAP → escalado a Domain Admin vía RBCD; ADV190023 | 16 LDAP Interface Events=2; eventos 2887 (resumen) y 2889 (origen concreto) en Directory Service |
Auditar → LdapEnforceChannelBinding=1 (cuando sea posible) → LDAPServerIntegrity=2 + LdapEnforceChannelBinding=2 (obligatorio) |
8. Estrategia de elevación de niveles funcionales de forma segura y reversible
Subir el nivel funcional de dominio o de bosque es una operación de un solo sentido en la mayoría de los saltos (no se puede bajar de Windows2012R2Domain a Windows2008R2Domain sin restaurar desde backup), así que hay que tratarlo con la misma disciplina que una migración de esquema.
- Confirmar que no queda ningún DC con el SO del nivel que vas a abandonar. El nivel funcional de dominio no puede elevarse por encima de lo que soporte el DC con la versión de SO más antigua todavía promocionada como controlador de dominio. Vuelve a ejecutar el inventario del apartado 2.1.
- Backup del estado del sistema de todos los DC (
wbadmin start systemstatebackupo tu solución de backup habitual) y, si es factible, snapshot a nivel de hipervisor de los DC virtualizados, inmediatamente antes del cambio (nunca como sustituto del backup de estado del sistema, sí como complemento para rollback rápido). - Verificar la salud de la replicación antes de tocar nada:
repadmin /replsummary repadmin /showrepl * /csv > C:auditoriareplicacion-pre-cambio.csv dcdiag /v /c /e > C:auditoriadcdiag-pre-cambio.txt - Elevar primero el nivel de dominio, después el de bosque (nunca al revés; el nivel de bosque no puede superar al de dominio):
Set-ADDomainMode -Identity tudominio.local -DomainMode Windows2016Domain Set-ADForestMode -Identity tudominio.local -ForestMode Windows2016Forest # Equivalente gráfico: Dominios y confianzas de Active Directory > clic derecho en el dominio > # "Elevar nivel funcional del dominio..." - Verificar replicación de nuevo inmediatamente después, y dejar pasar al menos un ciclo completo de replicación entre todos los sitios antes de dar el cambio por bueno.
- Documentar el punto de no retorno. Si algo va mal después de la elevación, la única vía de «rollback» real es restaurar el estado del sistema desde el backup del paso 2 en un DC autoritativo (restauración autoritativa), lo cual implica parar la replicación normal y es una operación mayor. Por eso el paso 3 (verificar salud antes) es el que evita llegar a necesitar el paso de rollback.
Regla de oro para exámenes y para producción: elevar el nivel funcional no actualiza ni modifica ningún DC existente; solo habilita funcionalidades del directorio (por ejemplo, la papelera de reciclaje de AD requiere mínimo Windows2008R2Forest; los grupos de servicio administrados aislados —gMSA restringidos— y las mejoras de replicación de atributos vinculados requieren niveles superiores). El riesgo no está en la elevación en sí, está en que un DC obsoleto que no cumple el nuevo mínimo deje de poder replicar o, peor, en que quede fuera del dominio de facto.
9. Riesgos de coexistencia: aplicaciones que dependen de NTLM/SMBv1
La resistencia organizativa a este tipo de proyectos casi nunca es técnica, es de gestión del riesgo de negocio. Los patrones más comunes que os vais a encontrar:
- ERP/ CRM heredados con cadenas de conexión que usan Integrated Security contra SQL Server pero desde un servicio ejecutado con una cuenta local (no de dominio), lo que fuerza NTLM porque no hay Kerberos posible sin cuenta de dominio con SPN.
- Impresoras multifunción y escáneres de red que solo saben hablar SMBv1 para «escanear a carpeta compartida» y no reciben firmware nuevo porque el fabricante descontinuó el modelo.
- Software de planta industrial (OT) —líneas de producción, SCADA, PLC con interfaz Windows CE o Windows Embedded— con certificaciones de fabricante que impiden cualquier cambio de SO o de configuración de red bajo pena de anular la garantía o la certificación regulatoria.
- Aplicaciones que acceden por IP en vez de por nombre DNS, forzando NTLM aunque el resto de la infraestructura esté correctamente configurada para Kerberos (Kerberos requiere SPN resoluble por nombre).
- Confianzas de bosque antiguas (external trusts o forest trusts heredados de fusiones/adquisiciones) que negocian el mínimo común denominador de cifrado si el bosque remoto no se ha actualizado en paralelo.
La respuesta correcta nunca es «dejar el protocolo abierto indefinidamente para no arriesgar». La respuesta correcta es aislar el sistema legacy (siguiente apartado) mientras se negocia su sustitución o actualización, y mantener el resto del dominio endurecido.
10. Sistemas que no se pueden actualizar: aislamiento y segmentación
Cuando de verdad no es viable actualizar o retirar un sistema a corto plazo, el objetivo pasa de «erradicar el protocolo» a «contener el radio de explosión». Medidas concretas, de más a menos prioritarias:
- Segmentación de red dedicada (VLAN aislada). El sistema legacy vive en una VLAN propia sin enrutamiento directo al resto del dominio, con acceso mediado por un jump host o proxy de aplicación.
- Firewall con reglas de mínimo privilegio restringiendo el tráfico SMB (TCP 445, TCP/UDP 137-139) y LDAP (TCP/UDP 389, TCP 636 LDAPS) exclusivamente entre el sistema legacy y los hosts que estrictamente lo necesitan, nunca «cualquier origen del dominio».
- Cuentas dedicadas y no reutilizadas. El servicio legacy debe autenticarse con una cuenta de dominio exclusiva para él (nunca una cuenta de administrador de dominio ni una cuenta compartida con otros sistemas), con contraseña larga, gestionada, y sin privilegios fuera de lo estrictamente necesario (delegación de permisos NTFS/compartición explícita, no membresía en grupos amplios).
- Excepción explícita y documentada, no silenciosa. Si un DC o servidor concreto necesita mantener SMBv1 o NTLM habilitado para dar servicio a ese sistema, esa excepción debe registrarse en el inventario de riesgo, con fecha de revisión y responsable, no dejarse como «está así porque siempre estuvo así».
- Deshabilitar SMBv1/NTLM en todo lo demás excepto en ese servidor concreto, usando GPO con filtrado por grupo de seguridad o WMI para que la excepción sea quirúrgica y no un permiso general.
- Monitorización reforzada específicamente sobre esa VLAN/host: cualquier intento de movimiento lateral desde o hacia el sistema aislado debe generar alerta prioritaria, porque es, por definición, el eslabón más débil.
- Plan de sustitución con fecha, no indefinido. El aislamiento es una medida puente, no una solución permanente; debe ir acompañado de un proyecto (aunque sea a 2-3 años vista) para sustituir o modernizar el sistema.
11. La ruta de migración: 2003 → 2008 R2 → 2012 R2 → 2016 → 2019/2022 → 2025
Un error técnico frecuente es intentar saltar directamente de un DC 2003 a un DC 2019/2022/2025 promocionándolo en el mismo bosque. No es soportado: Windows Server no permite in-place upgrade ni promoción directa de DC saltándose más de dos versiones de diferencia respecto al esquema/nivel funcional existente en determinados tramos, y en la práctica Microsoft solo da soporte oficial a los saltos de adprep /forestprep y /domainprep definidos versión a versión.
| Salto | Método soportado | Notas |
|---|---|---|
| 2003 → 2008 R2 | Introducir nuevo DC 2008 R2, transferir roles FSMO, dcpromo de retirada del 2003, adprep previo |
Punto de partida obligatorio si aún tenéis 2003; no existe salto directo a versiones más modernas |
| 2008 R2 → 2012 R2 | Introducir DC 2012 R2 con adprep /forestprep /domainprep, migrar FSMO, retirar 2008 R2 |
Habilita RC4 opcional pero AES ya soportado; buen punto para empezar a exigir AES |
| 2012 R2 → 2016 | Igual patrón: nuevo DC, adprep, migración FSMO | Introduce Credential Guard, niveles funcionales con Privileged Access Management (PAM); LDAP signing empieza a auditarse más agresivamente |
| 2016 → 2019/2022 | Nuevo DC, incorporación directa al mismo nivel funcional (ambos operan bajo Windows2016Domain como techo) |
2022 introduce mejoras TLS 1.3 parciales y refuerzos de firma SMB por defecto |
| 2019/2022 → 2025 | Nuevo DC 2025, adprep para nivel funcional propio Windows2025Domain (valor 10) |
Primer salto de nivel funcional real desde 2016; revisar compatibilidad de terceros antes de elevar |
Patrón operativo recomendado en cada salto de la tabla (válido para todos los tramos):
# 1. Verificar preparación del esquema/dominio actual
dcdiag /v
repadmin /replsummary
# 2. Ejecutar adprep en el DC que ostenta el rol de maestro de esquema (con cuenta de Enterprise Admin + Schema Admin)
adprep /forestprep
adprep /domainprep /gpprep
# 3. Promocionar el nuevo DC (versión superior) uniéndolo al dominio existente
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName tudominio.local -Credential (Get-Credential) -InstallDns
# 4. Transferir roles FSMO al nuevo DC
Move-ADDirectoryServerOperationMasterRole -Identity "NUEVO-DC" `
-OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster
# 5. Confirmar que el nuevo DC es Global Catalog y que la replicación es sana antes de retirar el antiguo
repadmin /showrepl * /csv
# 6. Retirar el DC antiguo de forma limpia (nunca apagarlo sin más)
Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartitions
Cada salto de esta ruta es, en sí mismo, una oportunidad para reforzar uno de los cuatro protocolos tratados en este módulo: al introducir el DC 2012 R2 exigid ya AES en las cuentas de servicio nuevas; al introducir el 2016, activad auditoría LDAP; al llegar a 2019/2022, el firmado SMB ya viene reforzado por defecto en instalaciones nuevas, así que aprovechad para desactivar SMBv1 en el resto del parque.
12. Laboratorio: auditar SMBv1 y NTLM en un entorno de laboratorio antes de bloquear
Objetivo: reproducir el ciclo completo de auditoría → decisión → bloqueo en un laboratorio aislado (VM o Hyper-V/VMware anidado), sin tocar producción, antes de replicar el procedimiento en el dominio real.
Material necesario
- 1 DC de laboratorio (por ejemplo Windows Server 2019 o 2022, con rol AD DS y DNS).
- 2-3 máquinas miembro: al menos una moderna (Windows 11/Server 2022) y, si es posible, una VM con Windows 7 o Server 2008 R2 para generar tráfico NTLMv1/SMBv1 real (aislada de Internet, solo con fines de laboratorio).
- Acceso de administrador de dominio en el laboratorio.
Pasos
- En el DC, activar auditoría SMB1 y auditoría NTLM tal como se describe en los apartados 2.3 y 3.1 (
Set-SmbServerConfiguration -AuditSmb1Access $true+ claves de registroMSV1_0/NetlogonParameters). - Desde la máquina antigua (Windows 7 / 2008 R2), forzar una conexión SMB1 explícita a un recurso compartido del DC:
net use Z: \NOMBRE-DCrecurso /user:laboratoriousuario1 - En el DC, revisar el canal
Microsoft-Windows-SMBServer/Audity confirmar la aparición del evento 3000 con el nombre de la máquina antigua como origen. - Desde esa misma máquina antigua, forzar autenticación NTLM explícita contra un recurso (por ejemplo accediendo por IP en lugar de por nombre DNS, lo que impide Kerberos):
net use Y: \10.0.0.10recurso /user:laboratoriousuario1 - Revisar en el DC el canal
Microsoft-Windows-NTLM/Operationaly confirmar la aparición de eventos 8002/8004 señalando el origen. - Con los datos anteriores, simular la decisión de bloqueo: en el DC, establecer
Set-SmbServerConfiguration -EnableSMB1Protocol $falseyLmCompatibilityLevel = 5. - Repetir los pasos 2 y 4 desde la máquina antigua y confirmar que ahora fallan (error del tipo «no se puede acceder al recurso compartido» o de credenciales), demostrando el efecto real del bloqueo sobre un cliente legacy.
- Documentar en una tabla simple: sistema, protocolo bloqueado, comportamiento tras el bloqueo (falla / sigue funcionando por fallback a Kerberos+SMB2), y decisión (actualizar cliente, aislar, o mantener excepción documentada).
Este laboratorio es deliberadamente pequeño porque el aprendizaje clave no es la escala, es el orden de operaciones: auditar primero, decidir con datos reales, bloquear después, y validar el impacto de forma controlada antes de tocar producción.
13. Errores comunes
- Bloquear NTLM (o SMBv1) sin haber auditado antes. Es, con diferencia, el error más caro: tumba aplicaciones de producción en horario laboral, genera incidentes de máxima prioridad y erosiona la confianza del negocio en el equipo de seguridad para el siguiente proyecto de endurecimiento.
- Confundir «auditar» con «bloquear». Activar
RestrictNTLMInDomaindirectamente en modoDeny allpensando que es «modo auditoría» — no lo es; los modos de auditoría son valores específicos (Enable auditing for all accounts,Enable all) distintos de los modos de bloqueo. - Elevar el nivel funcional sin backup del estado del sistema inmediatamente antes. Un snapshot de hace tres días no sirve si la elevación falla a mitad de camino con cambios de esquema ya aplicados parcialmente.
- No revisar accesos por IP. Forzar NTLM=deny y no darse cuenta de que media aplicación interna accede a recursos por dirección IP en vez de nombre DNS, lo cual imposibilita Kerberos estructuralmente y no es «arreglable» solo con configuración del DC.
- Dejar cuentas de servicio con
msDS-SupportedEncryptionTypesvacío y asumir que «ya usan AES porque el DC es moderno». El atributo por cuenta manda; un DC 2022 sigue ofreciendo RC4 como fallback si la cuenta no marca explícitamente soporte AES. - Tratar el aislamiento de sistemas legacy como solución permanente sin fecha de revisión ni plan de sustitución, convirtiendo una medida puente en deuda técnica perpetua.
- Saltarse pasos de
adprepal introducir un nuevo DC de versión superior, asumiendo que la promoción automática lo hace todo; en dominios con esquemas muy antiguos (extensiones de Exchange, System Center, productos de terceros) eladpreppuede fallar y requiere revisión manual de errores en el log antes de continuar.
14. Ejercicio
Sobre un laboratorio de Active Directory con al menos un DC y dos máquinas miembro (una de ellas idealmente con un SO antiguo, real o simulado):
- Ejecuta el inventario completo del apartado 2 (sistemas operativos, niveles funcionales) y guarda los resultados en un CSV.
- Activa la auditoría de SMBv1, NTLM y LDAP sin firma simultáneamente durante al menos 24 horas, generando tráfico real desde la máquina antigua (accesos por
net use, por IP, con distintas cuentas). - Extrae y documenta los eventos 3000 (SMB1), 8001-8004 (NTLM) y 2887/2889 (LDAP) en una tabla única con columnas: fecha, protocolo, origen, cuenta, decisión propuesta.
- Revisa el atributo
msDS-SupportedEncryptionTypesde al menos tres cuentas de servicio del laboratorio (o créalas si no existen) y corrige las que no tengan AES marcado. - Diseña, por escrito, un plan de fases (con fechas ficticias) para pasar de auditoría a bloqueo total de SMBv1 y NTLMv1/LM en ese laboratorio, incluyendo el punto de decisión de qué hacer con la máquina antigua si no puede actualizarse (retirarla vs. aislarla).
- Ejecuta el bloqueo real siguiendo tu propio plan y verifica, con capturas del visor de eventos y de los intentos de conexión fallidos, que el resultado coincide con lo esperado.
Preguntas frecuentes
¿Puedo desactivar SMBv1 y NTLM al mismo tiempo, o debo hacerlo de forma secuencial?
Es preferible hacerlo de forma secuencial y con auditorías independientes, aunque ambos procesos puedan solaparse en el tiempo. Cada protocolo tiene su propio conjunto de dependencias (SMBv1 suele afectar a NAS/impresoras, NTLM suele afectar a aplicaciones y accesos por IP), y si bloqueas los dos a la vez y algo falla, resulta mucho más difícil diagnosticar cuál de los dos cambios fue la causa. Recomendación práctica: completa el ciclo de SMBv1 primero (suele tener menos dependencias de aplicación), y usa ese proyecto como plantilla organizativa para el de NTLM, que normalmente es más largo por el volumen de aplicaciones implicadas.
¿Qué diferencia real hay entre el nivel funcional de dominio y el de bosque, y por qué importa el orden al elevarlos?
El nivel funcional de dominio determina qué capacidades están disponibles dentro de un dominio concreto (por ejemplo, el uso de fine-grained password policies requiere mínimo Windows2008Domain). El nivel funcional de bosque determina capacidades que afectan a todo el bosque, incluidas relaciones de confianza entre dominios y ciertas mejoras de replicación. El nivel de bosque nunca puede ser superior al nivel del dominio con el valor más bajo dentro de ese bosque, así que el orden correcto es siempre: primero asegurarse de que todos los dominios del bosque alcanzan el nivel deseado, después elevar el bosque.
¿Es seguro mantener un solo DC con Windows Server 2012 R2 si el resto ya está en 2019/2022, solo por una aplicación antigua?
Es una situación habitual, pero convierte a ese DC en el «eslabón más débil» del bosque: el nivel funcional de dominio quedará limitado por su presencia, y el mismo DC será probablemente el que siga aceptando SMBv1/NTLMv1 porque la aplicación lo necesita. La recomendación no es «mantenerlo indefinidamente sin más», sino aplicar el patrón de aislamiento del apartado 10: segmentarlo, restringir el tráfico legacy exclusivamente entre esa aplicación y ese DC, y no exponer ese mismo DC como punto de autenticación general del resto del dominio (por ejemplo, quitarlo de la lista de DC recomendados vía site coverage si es posible).
¿Cómo sé si una cuenta de servicio dejará de funcionar al forzar solo AES en Kerberos?
La forma más fiable es la auditoría por fases descrita en el apartado 5: revisar msDS-SupportedEncryptionTypes de cada cuenta con SPN, corregirla para que incluya AES, y verificar en un ciclo de uso real (por ejemplo, un día completo de operación de esa aplicación) que sigue autenticando correctamente antes de restringir a nivel de DC con SupportedEncryptionTypes. Si la cuenta o el software cliente no soportan AES en absoluto (algo raro pero posible en según qué integraciones muy antiguas de terceros), lo verás inmediatamente como fallos de autenticación Kerberos tras el cambio, y el rollback es tan simple como volver a incluir RC4 en la máscara de esa cuenta concreta mientras se investiga o sustituye el software.
¿Vale la pena migrar directamente a Windows Server 2025 si todavía estoy en 2012 R2, o es mejor pasar por 2016/2019 primero?
Técnicamente es posible introducir un DC 2025 directamente en un bosque cuyo DC más antiguo sea 2012 R2, siempre que ese DC 2012 R2 cumpla los requisitos mínimos de esquema tras ejecutar adprep. Sin embargo, en la práctica es preferible no saltarse el paso intermedio 2016/2019 salvo que sea una migración completa desde cero (nuevo bosque), porque cada versión intermedia trae mejoras de seguridad por defecto (firmado SMB reforzado, LDAP channel binding, restricciones NTLM más agresivas) que conviene validar una a una en lugar de recibir todas de golpe en un único salto, lo que dificulta identificar qué cambio concreto rompió qué aplicación si algo falla.
«Stop using SMB1 […] There’s no good reason to keep it around, and there hasn’t been for a very long time. […] If you turn on SMB1 auditing, then you can watch the logs for a while and see who’s still trying to connect with SMB1, then go turn it off there too.»
— Ned Pyle, Principal Program Manager, Microsoft, blog oficial «Storage at Microsoft» («Stop using SMB1»)