Problema

En varios entornos corporativos los clientes Windows 10/11 pueden ejecutar gpupdate sin problemas, pero gpupdate /force devuelve “The processing of Group Policy failed. Windows could not resolve the computer (or user) name.” solo cuando la máquina está conectada a la red inalámbrica. La falla ocurre en cualquier dispositivo, sin importar fabricante, arquitectura ni imagen de sistema. Cuando el mismo equipo se conecta por cable a cualquier VLAN, el comando se completa exitosamente.

El patrón típico incluye:

  • Respuesta exitosa del endpoint mapper (EPM) para la interfaz DRSUAPI (UUID e3514235‑4b06‑11d1‑ab04‑00c04fc2dcd2) pero ausencia total de tráfico Kerberos, LDAP, SMB o puertos RPC dinámicos.
  • Logs de gpsvc que indican MyGetUserName failed with 5 (acceso denegado) y bConnectivityFailure = 1.
  • Capturas de red que muestran solo una única SYN a TCP 135 y nada más.
  • El resto de la comunicación AD (SYSVOL, DFS, NetLogon) funciona correctamente tanto por Wi‑Fi como por Ethernet.

Este comportamiento bloquea la aplicación forzada de políticas de equipo y usuario, impide la sincronización de contraseñas, scripts de inicio y cualquier configuración que dependa de una actualización completa.

Causa

Los síntomas apuntan a un problema de resolución de credenciales y negociación de Kerberos sobre la interfaz inalámbrica. Las causas más habituales son:

  1. Política de firewall o ACL en el punto de acceso / controlador inalámbrico
    Los AP modernos pueden aplicar reglas implícitas que bloquean tráfico de puertos dinámicos RPC (1024‑65535) o paquetes UDP 53 que transportan consultas Kerberos (KDC). Cuando el cliente solo recibe la dirección del endpoint a través de EPM y luego intenta establecer una conexión a un puerto aleatorio, el firewall lo descarta sin generar logs visibles en el servidor.

  2. Segmentación de subredes con rutas asimétricas
    En entornos donde la WLAN está bridged a una VLAN distinta de la de los DC, una ruta unidireccional puede existir solo para tráfico estático (135, 53) pero no para los puertos dinámicos que asigna el DC. El cliente interpreta la falta de respuesta como “acceso denegado” (código 5) y aborta la operación.

  3. Problemas de “Network Isolation” o “Client Isolation” mal configurados
    Algunas configuraciones de aislamiento de cliente deshabilitan la capacidad de los dispositivos Wi‑Fi de iniciar conexiones salientes a puertos no declarados explícitamente, aunque el tráfico interno parezca permitido.

  4. Política de seguridad de Kerberos basada en la dirección IP
    Si el KDC está configurado para aceptar tickets solo de rangos IP específicos y la WLAN usa un rango distinto al de la LAN cableada, el cliente nunca envía paquetes Kerberos, lo que se traduce en la ausencia de tráfico en los captures.

  5. Problemas de MTU o fragmentación en la ruta inalámbrica
    Aunque el ping con -f -l 1472 sea exitoso, la fragmentación de paquetes RPC puede fallar silenciosamente cuando el cliente intenta establecer una sesión de alto nivel, provocando errores rápidos (15‑30 ms) antes de que el servidor responda.

En la práctica, la combinación de una regla de firewall implícita en el controlador Wi‑Fi y una ruta asimétrica es la causa más frecuente.

Solución

1. Verificar y abrir puertos RPC dinámicos en el controlador inalámbrico

Los controladores de AP deben permitir tráfico saliente desde la WLAN a los DC en el rango 1024‑65535 (TCP/UDP). La forma más segura es crear una regla que permita “RPC Dynamic Ports” únicamente hacia los servidores de dominio.

# En un controlador Cisco/Meraki, ejemplo de ACL
ip access-list extended WLAN_TO_DC
 permit tcp any host 10.0.140.3 range 1024 65535
 permit udp any host 10.0.140.3 range 1024 65535

En entornos Juniper Mist o FortiGate, habilite la política “Allow RPC dynamic ports” o desactive la inspección de “Application Control” para esa VLAN.

2. Añadir rutas estáticas para los puertos RPC en el firewall de capa 3

Si la WLAN está bridged a una VLAN distinta, configure rutas estáticas que garanticen que el tráfico de los puertos 1024‑65535 use la misma salida que el tráfico de 135, 53, 88 y 389.

# En FortiGate, ejemplo de ruta estática
config router static
 edit 0
  set dst 10.0.140.0/24
  set gateway 10.0.80.1
  set device "internal-wifi"
 next
end

3. Desactivar cualquier forma de “Client Isolation” o “AP Isolation”

En la consola del controlador Mist, verifique que la opción Isolation está desactivada y que no existen listas de control de acceso basadas en MAC que limiten puertos dinámicos.

4. Confirmar que el KDC acepta tickets desde la subred Wi‑Fi

Ejecute desde un cliente Wi‑Fi:

klist get <DC_FQDN>

Si el comando falla, añada la subred Wi‑Fi al parámetro AllowedIPAddresses del KDC (en krb5.conf o mediante GPO “Network security: Allow Kerberos authentication over untrusted networks”).

5. Probar la actualización forzada después de los cambios

gpupdate /force

Si el comando finaliza sin errores, el problema estaba en la capa de red y no en AD ni en la configuración de políticas.

Cuándo aplicar esta solución

  • Síntomas: gpupdate /force falla solo en Wi‑Fi, logs muestran MyGetUserName failed with 5, captura de red sin Kerberos ni puertos RPC dinámicos.
  • Entorno: LAN cableada funciona, WLAN está en VLAN separada o bridged, controladores AP con políticas de seguridad avanzadas.
  • No aplica: Cuando el fallo ocurre también en cable, o cuando los logs indican problemas de DNS, SYSVOL o permisos de GPO.

Código

# 1. Resetear la caché de Netlogon (útil después de cambiar rutas/ACL)
net stop netlogon
net start netlogon

# 2. Forzar re‑registro de la máquina en AD
nltest /sc_verify:domain.local
nltest /sc_reset:domain.local

# 3. Ejecutar gpupdate forzado y capturar salida
gpupdate /force /wait:30

Verificación

  1. Captura de tráfico: Inicie netsh trace start capture=yes antes de gpupdate /force. Verifique que aparecen paquetes TCP 135 → puerto dinámico (ej. 49670) y Kerberos UDP 88.
  2. Registro de eventos: En el Visor de eventos, bajo System → GroupPolicy, confirme que no aparecen entradas con bConnectivityFailure = 1.
  3. Estado de la política: Use gpresult /h result.html y abra el archivo. Todas las GPO deben mostrarse como Applied.

Notas adicionales

  • En algunos controladores Mist, la opción “Custom Forwarding” crea un túnel GRE que oculta puertos dinámicos. Cambiar a bridged elimina esa capa.
  • Si la WLAN usa WPA‑Enterprise con 802.1X, el proceso de autenticación de máquina puede interferir con Kerberos; en esos casos habilite “Machine Authentication” en el RADIUS.
  • Cuando se trabaja con dispositivos ARM (ej. Surface Go), asegúrese de que la política de “Network security: LAN Manager authentication level” sea Send NTLMv2 response only; de lo contrario, el cliente puede abortar antes de iniciar Kerberos.