Cómo evitar desconexiones masivas en RD Gateway de Windows Server 2019 tras los parches KB5040430/1578/3050

¿Tus usuarios se caen varias veces al día de la pasarela de Escritorio remoto? Desde la instalación de los parches acumulativos de mayo y junio de 2025, miles de administradores han sufrido reinicios inesperados del rol Remote Desktop Gateway en Windows Server 2019. A continuación encontrarás un análisis exhaustivo del problema, su causa y ocho medidas prácticas —incluyendo scripts listos para copiar— que mantendrán tu servicio operativo hasta que Microsoft libere la corrección definitiva.

Índice

Desconexiones en Windows Server 2019 RD Gateway

Resumen del problema

Tras instalar los cumulativos KB5040430, KB5041578 y la actualidad KB5043050, el servicio Tsgateway.exe se reinicia una o dos veces por jornada laboral:

  • Evento 700: la instancia del servicio genera la excepción 0xC0000005 (violación de acceso) y Windows lo recupera automáticamente.
  • Evento 103: 2148073494 avisa de que la cuenta de servicio no puede leer el certificado SSL configurado en el rol.
  • Cada reinicio de TS Gateway provoca la ruptura inmediata de todos los túneles RDP abiertos; los usuarios deben reconectarse manualmente.

Causa técnica de la inestabilidad

Los parches citados introducen cambios en la forma en que Tsgateway.exe consulta el almacén “MY” y accede a la clave privada del certificado asignado al canal HTTPS (TCP 443). Si la lista ACL de la clave no incluye acceso de lectura para NETWORK SERVICE (o la cuenta personalizada que ejecute el rol), la llamada devuelve STATUSACCESSDENIED, al que el proceso responde con un intento fallido de reintento y acaba lanzando la violación de acceso que genera el evento 700.

Guía de mitigación paso a paso

PasoAcciónObjetivo
Reasociar el certificado SSLEn RD Gateway Manager → Propiedades → SSL Certificates, seleccione nuevamente un certificado válido y aplique.Elimina referencias a certificados con ACL incorrectas o en estado corrupto.
Conceder permisos de lecturaAbra certmgr.msc ► certificado ► All Tasks → Manage Private Keys y agregue NETWORK SERVICE con permiso Read.Evita el error 103 por falta de acceso a la clave privada.
Usar un certificado alternativoImporte un certificado nuevo o uno verificado en otro servidor y vuelva a vincularlo.Aísla la incidencia si el certificado actual está dañado.
Reinicio programado del servicioAutomatice Restart-Service TSGateway -Force cada madrugada mediante el Programador de tareas.Reduce el impacto en horario productivo; se reinicia en una ventana controlada.
Monitorizar eventosRevise a diario Microsoft‑Windows‑TerminalServices‑Gateway\* buscando repeticiones o nuevas anomalías.Permite ajustar umbrales y recoger datos para un futuro caso de soporte.
Verificar red y firewallConfirme que no hay reglas, appliances o pérdidas de conectividad que agraven las reconexiones.Descarta desencadenantes externos al servidor.
Rollback controladoSi la inestabilidad es crítica, desinstale el último CU y aísle el servidor tras un WAF; documente la excepción de seguridad.Garantiza continuidad de negocio mientras se espera el hotfix.
Vigilar nuevos parchesSuscríbase a Windows Release Health y Security Update Guide para alertas sobre la futura actualización correctiva.Aplicar la solución oficial con la menor latencia posible.

Detalle ampliado de cada medida

Reasociar el certificado SSL

Aunque el certificado se muestre como “Vigente”, la referencia interna puede estar corrupta. Al volver a seleccionarlo, el wizard recrea los enlaces en HTTP.sys y actualiza la metabase de RD Gateway sin necesidad de reiniciar el host.

Ajustar permisos de la clave privada

Use el siguiente comando para verificar el SID que está ejecutando el rol:

sc.exe qc TSGateway | findstr /C:"SERVICESTARTNAME"

Luego otórguele lectura a la clave privada:

# Ejemplo con PowerShell
$thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -match "remote.contoso.com" }).Thumbprint
$path  = (Get-ChildItem "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" | Where-Object { $_.Name -like "$thumb" }).FullName
icacls $path /grant "NT AUTHORITY\NETWORK SERVICE:R"

Implementar reinicio programado

Register-ScheduledTask `
  -TaskName "Restart RDGateway nightly" `
  -Trigger  (New-ScheduledTaskTrigger -Daily -At 03:00) `
  -Action   (New-ScheduledTaskAction  -Execute "powershell.exe" -Argument "-NoLogo -NoProfile -Command `"Restart-Service TSGateway -Force`"") `
  -RunLevel Highest `
  -Description "Mitigación temporal CU KB5040430/1578/3050"

Script de autocorrección diaria

A continuación un ejemplo completo que automatiza la verificación del thumbprint, corrige la ACL y reinicia el rol solo si detecta cambios:

# Fix‑RDGatewayCertAcl.ps1
param(
    [string]$DnsName = "remote.contoso.com"
)

\$cert = Get-ChildItem Cert:\LocalMachine\My |
Where-Object { \$.Subject -match \$DnsName -and \$.HasPrivateKey } |
Sort-Object NotAfter -Descending |
Select-Object -First 1

if (-not \$cert) { Write-Error "Certificado no encontrado"; exit 1 }

\$privKeyPath = (Get-ChildItem "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" |
Where-Object { \$*.LastWriteTime -gt (Get-Date).AddMinutes(-5) } |
Where-Object { (Get-FileHash \$*.FullName).Hash.StartsWith(\$cert.Thumbprint.Substring(0,20)) }).FullName

Comprueba si NETWORK SERVICE tiene lectura

\$acl = Get-Acl \$privKeyPath
if (\$acl.Access | Where-Object { \$.IdentityReference -match "NETWORK SERVICE" -and \$.FileSystemRights -match "Read" }) {
Write-Output "Permisos correctos; no se modifica ACL"
} else {
icacls \$privKeyPath /grant "NT AUTHORITY\NETWORK SERVICE\:R" | Out-Null
Restart-Service TSGateway -Force
Write-Output "ACL reparada y servicio reiniciado"
}

Supervisión y registro de evidencias

Incorpore Get‑WinEvent‑FilterHashtable en un job de PowerShell 7 para exportar diariamente a CSV los eventos 700 y 103. Así podrá medir la eficacia de las mitigaciones y adjuntar la trazabilidad si eleva un caso a Microsoft Premier/Unified.

Escalada al soporte de Microsoft

 1. Genere procdump.exe ‑ma ‑e ‑w Tsgateway.exe para capturar el volc volcado completo.
 2. Incluya los hashes de los certificados afectados y el CSV de eventos.
 3. Solicite un code‑fix privado si la organización tiene derechos bajo Software Assurance.
 4. Pida un BYPASS temporal de validación de certificado (bandera interna) sólo si el entorno está segregado, pues deshabilita comprobaciones de seguridad.

Buenas prácticas pos‑incidente

  • Migra los certificados SHA‑1 o RSA 1024 a al menos RSA 2048 / SHA‑256.
  • Replica la pasarela en un clúster NLB para evitar punto único de fallo.
  • Prueba todos los cumulativos en un entorno staging con tráfico real mediante grabaciones de producción (replay) antes de aprobar el despliegue.
  • Documenta en el CMDB la versión exacta del CU, SHA‑1 del binario Tsgateway.exe y las fechas de reinstalación de certificados.

Conclusión

El binomio “parche acumulativo + ACL incorrecta” es la raíz del 90 % de las desconexiones masivas reportadas para Windows Server 2019 RD Gateway en los últimos meses. Aplicando los pasos 1 y 2 eliminas la causa más frecuente en cuestión de minutos; el resto de medidas te permiten capear la tormenta hasta que Microsoft distribuya la actualización definitiva. Mantén la disciplina de pruebas, monitorización y respaldo de certificados para evitar que esta incidencia se repita en futuros cumulativos.

Índice