Desde finales de 2022 Microsoft ha endurecido Netlogon para bloquear la autenticación NTLM que solo usa firma RPC. Sin un plan bien organizado, aplicar los parches de KB5021130 y posteriores puede dejar fuera de servicio inicios de sesión, montajes SMB o aplicaciones legadas. Este artículo explica, en profundidad y paso a paso, cómo desplegar las actualizaciones sin interrumpir la operación y, al mismo tiempo, mejorar la postura de seguridad de su dominio.

Resumen del problema

• KB5021130 y versiones sucesivas cambian el valor predeterminado de RequireSeal en Netlogon, exigiendo “RPC Sealing” además de firma.
• Controladores de dominio parcheados rechazan cualquier cliente que todavía se limite a firmar (RPC Signing) o que utilice RC4.
• Si el requisito de sellado se aplica sin inventario previo, estaciones de trabajo antiguas, servidores con aplicaciones embebidas o dispositivos Samba pueden perder la capacidad de autenticarse.

Solución recomendada

Fases de despliegue de Microsoft

Comprender el ciclo de Microsoft es clave para prever cuándo dejarán de funcionar los “bypass”:

Fase	Fecha	Comportamiento predeterminado	Alternativa transitoria	Comentario
Despliegue inicial	noviembre 2022	RequireSeal = 1 (compatibilidad)	Puede bajarse a 0 solo para pruebas
Aplicación inicial	abril 2023	Se elimina el valor 0	—
Aplicación predeterminada	junio 2023	RequireSeal = 2 salvo que el administrador mantenga 1	—
Aplicación total	julio 2023 en adelante	Solo se admite RequireSeal = 2	Ningún bypass permanente	La mitigación definitiva es actualizar los clientes

Inventariar y evaluar el impacto

1. Habilite un controlador piloto. Instale el parche y mantenga RequireSeal = 1 para registrar advertencias sin bloquear.
2. Revise los eventos 5838‑5841 en System ➜ NETLOGON. Identificará equipos que:
   • Solicitan solo firma (Signing) sin sellado (Sealing).
   • Aún usan algoritmos RC4 (RejectMd5Clients).
3. Clasifique cada hallazgo:
   • Actualizar: sistemas Windows obsoletos, Samba < 4.18, appliances que ya disponen de firmware reciente.
   • Reconfigurar: habilitar “Digitally encrypt or sign secure channel data (always)” en la directiva de la máquina, o activar RPC Sealing si la aplicación lo permite.
   • Retirar/Reemplazar: productos sin soporte ni hoja de ruta.

Laboratorio y pruebas de regresión

1. Clone un controlador de dominio. En un entorno aislado, establezca RequireSeal = 2 y reinstale los roles necesarios.
2. Ejecute un paquete de pruebas reproducible que incluya:
   • Inicio de sesión interactivo y por RDP.
   • Montajes SMB de recursos compartidos que dependan de NTLM.
   • Aplicaciones heredadas (IIS Clásico, ASP .NET 4, servidores SQL que aceptan NTLM).
   • Flujos LDAP sobre NTLM si aún existen.
3. Documente el resultado y fijar criterios de aceptación claros antes de pasar a producción.

Aplicar los parches en producción

1. Despliegue escalonado. Una vez que los clientes hayan sido actualizados o verificados, instale el parche en grupos de DC y no cree la clave RequireSeal; el valor implícito ya es 2.
2. Escenario con máquinas pendientes. Si aún necesita tiempo:
   • Deje los DC de producción con RequireSeal = 1 (solo viable en versiones de Windows anteriores a junio 2023).
   • Trace un calendario de retiro de excepciones: a partir de julio 2023 cualquier DC parcheado ignorará 1 y exigirá sellado.
   • No prolongue un DC sin parche como “puente”; la superficie de ataque es significativa.

Medidas de seguridad complementarias

• Evento RejectMd5Clients. Active la clave homónima únicamente cuando todos los equipos soporten AES o SHA‑2; de lo contrario bloqueará clientes que todavía dependen de RC4.
• Supervisión proactiva. Configure alertas en su SIEM para cualquier nuevo 5838: indica un intento de conexión sin sellado y facilita la detección de dispositivos olvidados.
• Segregación de red. Coloque los sistemas que no se puedan actualizar detrás de un proxy o VLAN aislada con controles de acceso estrictos.
• Modernizar aplicaciones. Siempre que sea factible, migre autenticación a Kerberos o a un proveedor de identidad moderno (OAuth 2.0/ OpenID Connect). En su defecto, utilice un proxy que sí hable RPC Sealing (Samba 4.18+, vCenter 8, etc.).

Seguimiento y soporte

• Revise mensualmente las notas de versión de Windows Server y el artículo KB5021130. Microsoft ha avisado de futuras prohibiciones de algoritmos inseguros.
• Audite los eventos 5838‑5841 tras cada «Patch Tuesday»; los cambios acumulativos pueden reactivar clientes supuestamente retirados.
• Si un proveedor certifica que su producto no puede adoptar RPC Sealing de inmediato, Microsoft documenta excepciones temporales que se solicitan vía soporte Premier/Unified.

Resumen ejecutivo

No existen desviaciones permanentes posteriores a julio 2023: cualquier dispositivo que quiera seguir utilizando NTLM deberá implementar RPC Sealing. La única estrategia segura consiste en un ciclo continuo de inventario, prueba, corrección y despliegue controlado.

---

Anexo A – Claves de registro implicadas

Para referencia rápida, las claves de grupo local (LGPO) o política de dominio (GPO) que intervienen en el proceso son:

Ruta GPO / Registro	Propósito	Valores admitidos	Recomendación
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\RequireSeal	Habilita o deshabilita la exigencia de RPC Sealing	0 = Deshabilitado 1 = Compatibilidad 2 = Obligatorio	Usar 2 salvo pruebas muy acotadas
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\RejectMd5Clients	Bloquea clientes que negocien RC4	0 = Permitir 1 = Advertir 2 = Rechazar	Subir a 2 cuando todo el parque esté actualizado
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft network client: Digitally sign communications (always)	Fuerza firma y, en versiones actuales, también sellado	Activado / Desactivado	Activado

Anexo B – Mapa de ruta para equipos Samba

Los entornos mixtos con servidores o dispositivos basados en Samba requieren un camino de actualización específico:

• Samba 4.18 o superior ya incluye soporte completo de RPC Seal; solo es necesario recompilar con las opciones por defecto.
• Samba 4.17 y anteriores pueden aplicar el parche de backport disponible en el repositorio oficial. Sin embargo, la comunidad solo mantiene las dos últimas versiones estables, por lo que la actualización es el método recomendado.
• Dispositivos integrados (NAS, impresoras multifunción, appliances): consulte al fabricante. QNAP, Synology y Dell EMC han publicado firmware compatibles. Para hardware sin roadmap conocido, plantéese aislar o reemplazar.

Anexo C – Plan de comunicación

Las incidencias durante la fase de aplicación suelen deberse a falta de información interna. Un plan de comunicación sugerido sería:

1. Notificación previa. Envíe un aviso de cambio con al menos dos ciclos de mantenimiento de antelación. Destaque la fecha en que RequireSeal pasará a 2 y las consecuencias para equipos no compatibles.
2. Guía de autoevaluación. Facilite a las unidades de negocio un procedimiento paso a paso para comprobar sus sistemas, incluyendo comandos como nltest /sc_query:<DC> y verificación de logs.
3. Ventana de pruebas dirigidas. Abra un entorno de preproducción donde los usuarios puedan validar sus flujos antes de la congelación.
4. Canal de escalado rápido. Asigne un grupo de soporte de guardia durante las primeras 48 h tras el cambio, con directriz clara: no revertir el parche, sino ayudar a actualizar o reconfigurar el cliente.

Anexo D – Preguntas frecuentes

¿Puedo mantener un único DC sin parche para clientes antiguos?
Técnicamente sí, pero crea un punto único de fallo con una superficie de ataque conocida. Además, futuras actualizaciones de schema o de nivel funcional pueden impedir que un DC obsoleto siga participando en el dominio.

¿Por qué Netlogon exige ahora “sellado” si ya usaba “firma”?
La firma garantiza integridad, pero el contenido viaja en texto claro. El sellado añade confidencialidad; Microsoft cierra así vectores de relay y downgrade descubiertos en CVE‑2022‑38023 y vulnerabilidades relacionadas (CVE‑2022‑37967, CVE‑2022‑21913).

¿Afecta a Kerberos o solo a NTLM?
El cambio es específico de canales seguros gestionados por Netlogon, por lo que impacta a NTLM y a ciertos flujos Kerberos contrafirmados. Aplicaciones que usen Kerberos puro no se ven afectadas.

¿Cómo identifico equipos que usan RC4?
Active temporalmente RejectMd5Clients = 1; los eventos 5840 mostrarán el nombre del host. Alternativamente, inspeccione el tráfico con Wireshark filtrando por auth\_type == rc4.

---

La seguridad no es un estado, sino un proceso: revise, actualice y supervise de forma continua.