Windows Server 2016 fin de soporte: actualización controladores de dominio Active Directory antes del 12 de enero de 2027

Una actualización de controladores de dominio Active Directory por fin de soporte de Windows Server 2016 es un proyecto con fecha, con un plazo fijo — no un elemento de backlog que se pueda seguir posponiendo. El equipo de Windows Server de Microsoft afirma sin rodeos que «el soporte extendido de Windows Server 2016 terminará el 12 de enero de 2027», y la ficha de Microsoft Lifecycle para Windows Server 2016 confirma que el producto sigue la Fixed Lifecycle Policy con una fecha de fin de soporte extendido en enero de 2027. El soporte convencional (mainstream) ya terminó en enero de 2022.

La parte incómoda casi nunca son los controladores de dominio en sí. La mayoría de los equipos pueden programar una reconstrucción de DC. Lo que los bloquea es una lista corta de hosts y appliances críticos para el negocio que no se pueden actualizar — y esos hosts no cargan solo su propio riesgo. Como los valores por defecto de cifrado Kerberos, los niveles funcionales y los ajustes de hardening a nivel de dominio son propiedades del dominio, un puñado de máquinas que no se pueden parchear fija todo el directorio a su nivel de seguridad.

Windows Server 2016 fin de soporte: plazo de la actualización de controladores de dominio Active Directory

Windows Server 2016 sigue la Fixed Lifecycle Policy de Microsoft, que garantiza «un mínimo de cinco años de soporte convencional» más «un período adicional de soporte extendido para algunos productos». La cifra de diez años que suele citarse viene de una página diferente: Microsoft describe el Long Term Servicing Channel de Windows Server como con «un mínimo de 10 años de soporte: cinco años de soporte convencional y cinco años de soporte extendido, que incluye actualizaciones de seguridad periódicas». El soporte extendido es la fase que aún entrega actualizaciones de seguridad. Una vez que termina, eso se detiene.

El propio planteamiento de Microsoft sobre qué significa el fin de soporte para un sistema operativo de servidor es directo: una vez que un producto llega al fin de soporte, «eso también significa el fin de las actualizaciones de seguridad y los boletines», una situación que «puede causar problemas de seguridad o cumplimiento y poner en riesgo las aplicaciones de negocio».

El 25 de febrero de 2026, Microsoft anunció las Extended Security Updates para Windows Server 2016. Esas actualizaciones se entregan «a través del portal de Azure», y el ESU «habilitado por Azure Arc» se presenta como algo que aporta beneficios adicionales de Azure, incluida flexibilidad de licenciamiento y capacidades de gestión de Azure. La recomendación de Microsoft en esa misma publicación es actualizar a Windows Server 2025 o migrar a Azure — el ESU se plantea como un puente, no como un destino.

Para un controlador de dominio en concreto, el riesgo no es abstracto. El catálogo de puntos de control de Active Directory de la ANSSI contiene un hallazgo dedicado titulado «DC/RODC with an obsolete operating system», que describe a los controladores de dominio que ejecutan «sistemas operativos para los que Microsoft ya no publica actualizaciones de seguridad. Por lo tanto, cualquier vulnerabilidad nueva encontrada en esos sistemas operativos seguirá siendo explotable». Su remediación se resume en una línea: «Migrar estos sistemas operativos obsoletos lo antes posible, preferiblemente a la última versión de Windows».

Por qué un solo host legacy retiene todo el dominio

Esta es la parte contraintuitiva, y es donde la mayoría de los planes de migración para 2027 fallan en silencio.

Los niveles funcionales están limitados por su peor controlador de dominio

El nivel funcional de bosque y dominio determina qué capacidades de AD DS están disponibles — y la matriz de interoperabilidad de niveles funcionales de Microsoft deja explícita esa dependencia. Un DC con Windows Server 2012 R2 no puede ejecutarse en el nivel funcional de Windows Server 2016. Un DC con Windows Server 2016, 2019 o 2022 no puede ejecutarse en el nivel funcional de Windows Server 2025.

Un solo controlador de dominio 2012 R2 que sobreviva limita entonces todo el dominio al nivel 2012 R2, lo que le cuesta cada capacidad introducida desde entonces — incluidas las funciones a nivel de dominio de Windows Server 2016 (rotación automática de NTLM y otros secretos basados en contraseña en cuentas configuradas con Smart card required for interactive logon, soporte para permitir NTLM de red cuando un usuario está restringido a dispositivos unidos al dominio específicos, y el SID de identidad de clave pública reciente para clientes Kerberos que se autentican con la PKInit Freshness Extension) y la función opcional de páginas de base de datos de 32k del nivel Windows Server 2025.

La checklist de la ANSSI trata esto como un defecto calificado por derecho propio, bajo «Insufficient forest and domains functional levels»: la alerta se activa en su primer nivel de madurez cuando el nivel funcional del bosque está por debajo de Windows Server 2008 R2, en el nivel 3 por debajo de Windows Server 2012 R2, y en el nivel 4 por debajo del nivel Windows Server 2016. La justificación indicada es que «usar un nivel funcional débil priva al bosque de funciones de seguridad importantes».

Los clientes legacy retienen su cifrado Kerberos como rehén

El mismo mecanismo se aplica al cifrado. La guía de Microsoft sobre detección y remediación del uso de RC4 en Kerberos explica que RC4 «se usa típicamente en entornos Windows cuando cuentas o dispositivos no admiten tipos de cifrado más fuertes como AES-SHA1» — y que cuando una cuenta no tiene ningún valor msDS-SupportedEncryptionTypes, el KDC recurre al valor DefaultDomainSupportedEncTypes a nivel de dominio.

Ese mecanismo de reserva es la trampa. Relajar DefaultDomainSupportedEncTypes para mantener funcionando una appliance «cambia el comportamiento de todas las cuentas que no tienen un valor definido», en palabras de Microsoft. Un host, una regresión a nivel de dominio. Es el mismo mecanismo detrás del fallback de Kerberos RC4, y es lo que mantiene el Kerberoasting económicamente viable: los tickets de servicio cifrados con RC4 se crackean offline mucho más rápido que los de AES.

Windows Server 2025 cierra la puerta por completo, y la advertencia de Microsoft merece citarse íntegra:

Lea de nuevo esa última frase. Un solo dispositivo limitado a RC4 no solo debilita el dominio — puede forzarle a mantener controladores de dominio más antiguos, lo que a su vez limita su nivel funcional, lo que a su vez bloquea el hardening que intentaba desplegar. La dependencia corre hacia atrás, desde la appliance hasta el directorio.

El cambio del valor por defecto de RC4 ya se ha desplegado

Esto no es un problema futuro. KB5073381, que aborda la CVE-2026-20833, desplegó el cambio en fases:

La vía de escape del rollback ha desaparecido. Si una dependencia legacy solo funcionaba gracias al antiguo valor por defecto de RC4, ya está rota o ya está cubierta con una excepción explícita.

Detección

Empiece por tres inventarios. Ninguno requiere un agente, y los tres son lo bastante baratos como para ejecutarse cada semana.

1. Distribución de sistemas operativos entre los objetos equipo. El atributo operatingSystem lo rellena la propia máquina al unirse al dominio y se refresca al arrancar, así que es una primera aproximación razonable, aunque no una prueba definitiva:

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object { $_.Enabled -eq $true } |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Cruce con LastLogonDate: un SO obsoleto que no se ha autenticado en un año es una tarea de limpieza, no un bloqueo de migración. Trate como restricción real los que se conectaron esta semana. Esto complementa la revisión de identidad de máquina cubierta en superficie de ataque de los objetos de equipo en Active Directory — ese artículo cubre encontrar objetos de máquina obsoletos y peligrosos; este cubre qué hacer cuando no puede eliminarlos.

2. Versiones de SO de los controladores de dominio y niveles funcionales actuales.

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog, Site

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'msDS-Behavior-Version'

3. Uso real de RC4. Microsoft publica dos scripts de código abierto, List-AccountKeys.ps1 y Get-KerbEncryptionUsage.ps1, en el repositorio Kerberos-Crypto:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Para encontrar cuentas ancladas a RC4 por configuración en lugar de por capacidad, consulte el atributo directamente — el valor decimal 4 significa solo RC4:

Get-ADObject -Filter "msDS-SupportedEncryptionTypes -eq 4" -Properties msDS-SupportedEncryptionTypes |
    Select-Object DistinguishedName, ObjectClass

Remediación

Paso 1 — Delimitar la excepción por cuenta, nunca por dominio. Microsoft ofrece dos opciones cuando una cuenta recurre al valor por defecto del dominio, y solo una es segura a escala: «Definir el valor específico de msDS-SupportedEncryptionTypes en las propiedades de la cuenta para asegurarse de que no recurra al valor DefaultDomainSupportedEncTypes». Use esa opción. Reserve el valor a nivel de dominio para endurecer, no para relajar — la ruta de registro para forzar solo AES-SHA1 es HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, valor DefaultDomainSupportedEncTypes (REG_DWORD) fijado en 0x18.

Paso 2 — Poner en cuarentena lo que no puede actualizar. Para cada host que deba sobrevivir más allá del 12 de enero de 2027:

1. Denegar el inicio de sesión Tier 0. Ningún Domain Admin, ninguna cuenta de servicio con derechos a nivel de dominio, ninguna delegación, debería autenticarse jamás en un host que no se puede parchear.
2. Restringirlo a nivel de red a los puertos y pares que realmente necesita.
3. Delimitar los etypes de Kerberos con una GPO específica en lugar de una política de dominio. En Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad, defina Seguridad de red: configurar tipos de cifrado permitidos para Kerberos, limitada a la OU que contiene solo los hosts legacy.
4. Aplicar la firma en todos los demás sitios, para que el host débil no pueda usarse como pivote de relay — vea firma SMB y firma LDAP.

Paso 3 — Actualizar primero los controladores de dominio, y de forma limpia. Microsoft es explícito sobre el método: «La forma recomendada de actualizar un dominio es usar una instalación limpia del SO para promover nuevos servidores a DC que ejecuten una versión más reciente de Windows Server y degradar los DC antiguos según sea necesario. Este método es preferible a actualizar el sistema operativo de un DC existente». La secuencia documentada es: unir el nuevo servidor, instalar el rol AD DS (que ejecuta adprep automáticamente), promoverlo, mover los roles FSMO con Move-ADDirectoryServerOperationMasterRole, y luego degradar y retirar el DC antiguo.

# Localizar los titulares actuales de FSMO antes de mover nada
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

Si en su lugar opta por una actualización in situ, Microsoft requiere que «ejecute adprep /forestprep y adprep /domainprep manualmente» — forestprep una vez por bosque para cada versión más reciente de Windows Server, domainprep una vez en cada dominio que contenga DC que esté actualizando, de nuevo por versión.

Paso 4 — Elegir el destino correcto. Según las rutas de actualización in situ compatibles de Microsoft, Windows Server 2016 puede actualizarse in situ, mediante medios de instalación, a Windows Server 2019, 2022 o 2025. Windows Server 2012 R2 puede ir directamente a Windows Server 2025, porque «a partir de Windows Server 2025, los sistemas no en clúster pueden actualizar hasta cuatro versiones a la vez» — pero las actualizaciones continuas en clúster siguen avanzando solo una versión a la vez.

Paso 5 — Elevar los niveles funcionales al final. Solo después de que el último DC legacy haya sido degradado y retirado. Tenga en cuenta que esto es en gran medida de un solo sentido: el rollback del nivel funcional del bosque se limita a volver a Windows Server 2012 R2 o Windows Server 2008 R2 desde una actualización de esos niveles, y el rollback a nivel de dominio solo existe cuando eleva a Windows Server 2016 con un nivel de bosque de Windows Server 2012 o inferior.

🚨 Peligro: no eleve el nivel funcional mientras un DC no compatible siga unido. La guía de Microsoft es que si el bosque contiene DC en un nivel funcional más antiguo del que admite un nuevo SO, «la instalación se bloquea» y esos DC «deben retirarse y el nivel funcional del bosque debe elevarse a una versión compatible antes de añadir nuevos DC con Windows Server a su bosque».

La secuencia importa más que la velocidad aquí. Poner en cuarentena, luego actualizar los DC, luego elevar los niveles, luego endurecer el cifrado a nivel de dominio. Hacerlo en cualquier otro orden rompe la producción o le deja con un dominio endurecido solo sobre el papel que sigue recurriendo a su miembro más débil — uno de los patrones recurrentes de las configuraciones incorrectas de seguridad de Active Directory más comunes.

Cómo EtcSec detecta esto

EtcSec expone esta cadena de dependencia exacta a partir de una única auditoría de solo lectura, sin agentes en los hosts legacy. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 y COMPUTER_OS_OBSOLETE_VISTA inventarían los objetos de máquina cuyos sistemas operativos ya no reciben actualizaciones de seguridad, clasificados según si todavía se autentican. PR001_5_1_DC_OS_OBSOLETE aísla el caso mucho más grave — un controlador de dominio que en sí mismo ejecuta un SO obsoleto — porque ese es el control que determina si su Tier 0 se puede parchear o no. ANSSI_R15_LOW_FUNCTIONAL_LEVEL reporta los niveles funcionales actuales de bosque y dominio frente a la línea base recomendada, para que pueda ver de inmediato qué DC legacy está limitando el directorio.

Juntos, esos controles responden a la única pregunta que importa antes del 12 de enero de 2027: qué hosts concretos están reteniendo el dominio, y qué pasaría realmente si los retirara. Volver a ejecutar la auditoría después de cada paso de remediación demuestra que el nivel se movió — el enfoque descrito en auditar la seguridad de Active Directory y demostrar la remediación.