MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. WEF no envía eventos: WinRM/Kerberos 0x80090322 (SPN) – solución y guía completa

WEF no envía eventos: WinRM/Kerberos 0x80090322 (SPN) – solución y guía completa

Windows Server

Si tu suscripción de Windows Event Forwarding (WEF) aparece “conectada” pero no llegan eventos y en el origen ves 0x80090322 con Kerberos, aquí tienes la solución que funciona y una guía completa para diagnosticar y corregir SPN/WinRM de forma segura en entornos Windows Server.

Índice

Resumen del escenario

Entorno con Windows Event Forwarding (WEF) 2019 y suscripción activa. En la máquina origen (equipo que reenvía) todo parece correcto, pero los eventos no se remiten al colector (Windows Event Collector, WEC). En el registro Microsoft-Windows-Forwarding/Operational del origen aparece el Evento 105 con ErrorCode 2150858909 y un WSManFault que incluye:

“WinRM cannot process the request… errorcode 0x80090322 while using Kerberos authentication”

La pregunta habitual es cómo cambiar o ajustar el método de autenticación y, sobre todo, cómo resolver el bloqueo.

Diagnóstico rápido en una frase

El error 0x80090322 (SECEWRONG_PRINCIPAL: “el nombre principal de destino es incorrecto”) indica un problema con el SPN (Service Principal Name) que WinRM intenta usar para autenticarse con Kerberos frente al WEC. Si el SPN esperado no existe o no coincide, Kerberos falla y el equipo origen no envía eventos.

Por qué sucede: cómo construye WinRM el SPN

Cuando el cliente WinRM del origen contacta al WEC por Kerberos, compone un SPN a partir del nombre de destino. Para WSMAN suele emplear la clase WSMAN/<host o FQDN> (y, en algunos escenarios, con puerto). Si ese SPN no está en la cuenta de equipo del servidor WEC o no corresponde al FQDN usado en la suscripción, el KDC no puede emitir el ticket adecuado y devuelve el error. Alternativamente, WinRM puede usar la clase HOST/<host o FQDN>, que normalmente ya existe de forma predeterminada en las cuentas de equipo del dominio.

Solución directa que resolvió el caso

Si buscas una acción correctiva inmediata que ha demostrado funcionar en escenarios idénticos, realiza estos pasos en la máquina origen (la que reenvía eventos):

  1. Forzar el prefijo de SPN a HOST en el cliente WinRM (equipo origen):
    reg add HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client ^ /v spnprefix /t REGSZ /d "HOST" /f Con esto, el cliente solicitará un ticket Kerberos para HOST/<FQDN>, SPN que suele existir por defecto en la cuenta de equipo del WEC.
  2. Reiniciar WinRM (o el equipo) para aplicar el cambio:
    net stop winrm net start winrm
  3. Verificar conectividad WSMan desde el origen:
    Test-WsMan <NombreOFQDNdel_WEC> Si devuelve información del servicio, la ruta de autenticación y transporte está operativa.

Alternativas y pruebas de diagnóstico si persiste el fallo

Comprobar y (si falta) crear el SPN en la cuenta del WEC

En el Controlador de Dominio o en una sesión con RSAT, revisa los SPN de la cuenta de equipo del colector:

setspn -L &lt;NombreServidorWEC&gt;

Si no ves un SPN coherente con cómo llegan los clientes (FQDN/puerto), añade el SPN del servicio WSMAN (ajusta el puerto si aplica):

setspn -S WSMAN/&lt;FQDNoHost&gt;:5985 &lt;NombreServidorWEC&gt;

Consejo: usa exactamente el FQDN que figura en la GPO de SubscriptionManager para evitar desajustes. Si usas HTTPS, el puerto habitual es 5986.

Probar autenticaciones alternativas (solo para aislar)

  • Basic (desactivado por defecto). Habilítalo temporalmente en el cliente y usa preferentemente HTTPS: winrm set winrm/config/client/auth @{Basic="true"}
  • TrustedHosts para descartar problemas de confianza de nombres (reduce garantías, úsalo solo en pruebas controladas): winrm set winrm/config/client @{TrustedHosts="<FQDNdelWEC>"}

Revisar lo obvio

  • Ambos equipos en el mismo dominio o con confianza entre bosques vigente (si aplica).
  • DNS y FQDN coherentes: el nombre usado en la suscripción debe resolver al WEC correcto.
  • Hora sincronizada (NTP/Kerberos es sensible a desfases).
  • Comprobación del listener WinRM en el WEC: winrm e winrm/config/listener
  • Revisa trazas en origen y destino:
    • Microsoft-Windows-Forwarding/Operational en el origen.
    • Microsoft-Windows-EventCollector/Operational y Microsoft-Windows-WinRM/Operational en el WEC.
    • Seguridad (Security) en DC/WEC: eventos Kerberos de solicitud de tickets y errores.

Tabla de síntomas, causa y corrección

SíntomaCausa probableAcción recomendada
Evento 105 en el origen con 0x80090322SPN no resuelto o incorrecto para el WECForzar spn_prefix=HOST en el cliente o registrar SPN WSMAN en la cuenta del WEC
Test-WsMan falla con KerberosFQDN no coincide con SPN; problema DNS; hora desfasadaUsar FQDN correcto; corregir DNS; sincronizar hora; comprobar SPN
Funciona con Basic/TrustedHosts pero no con KerberosSolo el camino Kerberos está rotoReparar SPN y prefijo; evitar dejar Basic/TrustedHosts en producción
Eventos llegan por equipos pero no por otrosGPO o resolución de nombre diferente por OU/VLANVerificar GPO SubscriptionManager y FQDN usado; uniformar configuración

Procedimiento recomendado paso a paso

  1. Identifica el nombre objetivo que usan los clientes: FQDN y puerto del WEC tal como están en la GPO de WEF (SubscriptionManager).
  2. Comprueba SPN en el WEC: setspn -L <NombreServidorWEC> Si falta WSMAN/<FQDN>[:<puerto>], añádelo: setspn -S WSMAN/<FQDN>:5985 <NombreServidorWEC>
  3. En el origen, fuerza el prefijo HOST si necesitas una solución inmediata: reg add HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client ^ /v spnprefix /t REGSZ /d "HOST" /f net stop winrm & net start winrm
  4. Valida conectividad: Test-WsMan <FQDN_WEC> wevtutil qe Microsoft-Windows-Forwarding/Operational /c:5 /rd:true /f:text
  5. Confirma recepción en el WEC: wevtutil qe Microsoft-Windows-EventCollector/Operational /c:20 /rd:true /f:text Deberías ver suscripciones activas y sesiones de origen abiertas.

Mejoras de seguridad y buenas prácticas

  • Prefiere HTTPS (5986) para WinRM en producción. Configura un certificado válido (CN/SAN = FQDN del WEC) y crea el listener: winrm create winrm/config/Listener?Address=*+Transport=HTTPS ^ @{Hostname="<FQDN_WEC>"; CertificateThumbprint="<THUMBPRINT>"}
  • Unifica el FQDN en la GPO de SubscriptionManager para que todos los orígenes pidan el mismo SPN.
  • SPN coherentes: usa WSMAN/<FQDN> (y puerto si procede) o HOST/<FQDN> según tu estándar; evita mezclas inconsistentes.
  • TrustedHosts solo para pruebas controladas. No lo dejes habilitado por defecto.
  • Audita Kerberos en DC/WEC para detectar duplicidad o ausencia de SPN.

Cómo ajustar la GPO de WEF correctamente

En la GPO que aplica a los equipos origen, revisa Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding (o usa Policy CSP equivalente) y valida que SubscriptionManager referencia el FQDN exacto del WEC, por ejemplo:

Server=http://wec01.contoso.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

Si cambiaste a HTTPS, ajusta la URL y el puerto.

Automatizar la corrección en escala

Para múltiples orígenes, aplica el valor spn_prefix mediante GPO Preferences (Registro) en la ruta:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client
Nombre: spn_prefix
Tipo: REG_SZ
Datos: HOST

Tras desplegarlo, fuerza la actualización y reinicia WinRM en una ventana de mantenimiento:

gpupdate /force
net stop winrm &amp; net start winrm

Señales inequívocas de éxito

  • Test-WsMan <WEC> devuelve metadatos de WSMan sin errores.
  • Desaparecen los Eventos 105 en los orígenes.
  • Los eventos comienzan a acumularse en el Forwarded Events del WEC conforme a la suscripción.

Preguntas frecuentes

¿Es “seguro” usar HOST/<FQDN> en lugar de WSMAN/<FQDN>?
Sí, HOST es un SPN genérico presente por defecto en las cuentas de equipo y es un patrón válido para muchos servicios. No obstante, si tu estándar corporativo exige SPN específicos por servicio, crea WSMAN/<FQDN> en la cuenta del WEC y mantén spn_prefix en su valor por defecto.

¿Necesito incluir el puerto en el SPN?
Depende de tu diseño. Si te conectas por el puerto por defecto y todos los clientes resuelven el mismo FQDN, normalmente no es necesario. En entornos con puertos no estándar o proxies/Balanceadores, incluir el puerto puede evitar ambigüedades. Mantén consistencia entre SPN y URL de la suscripción.

¿Por qué funciona con Basic o TrustedHosts y no con Kerberos?
Porque esas opciones evitan la ruta de autenticación Kerberos (o relajan la verificación). Son útiles para aislar causas, pero no deben quedarse habilitadas en producción.

¿Qué eventos de seguridad me ayudan a confirmar el SPN correcto?
Busca en los DC eventos de solicitud de tickets de servicio (p. ej. 4769) donde el SPN solicitado corresponda al WEC. Si ves errores de SPN inexistente o duplicado, corrige en AD.

Errores comunes y cómo evitarlos

  • Usar el nombre corto en la suscripción cuando el SPN registrado es con FQDN. Estandariza a FQDN en GPO y en SPN.
  • Registrar el SPN en la cuenta de usuario equivocada en vez de en la cuenta de equipo del WEC.
  • Falta de sincronización horaria: Kerberos es sensible a desfases (<= 5 min por defecto).
  • Certificado HTTPS sin FQDN en SAN: aunque Kerberos sea correcto, el canal TLS podría romperse por name mismatch.

Checklist rápida de resolución

  • Confirmar FQDN/puerto del WEC exactamente como está en la GPO.
  • Revisar SPN en la cuenta del WEC; crear WSMAN/<FQDN> si falta.
  • En el origen, establecer spn_prefix=HOST si necesitas desbloquear de inmediato.
  • Reiniciar WinRM y validar con Test-WsMan.
  • Comprobar que cesan los eventos 105 y que el colector recibe eventos.

Anexo: comandos útiles

:: Ver listeners en el WEC
winrm e winrm/config/listener

\:: Forzar SPN a HOST en el cliente (origen)
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client /v spn\prefix /t REG\SZ /d "HOST" /f

\:: Reiniciar WinRM
net stop winrm & net start winrm

\:: Validar WSMan
Test-WsMan \

\:: SPN en la cuenta del WEC
setspn -L \
setspn -S WSMAN/\:5985 \

\:: Habilitar Basic (solo pruebas) en el cliente
winrm set winrm/config/client/auth @{Basic="true"}

\:: Añadir temporalmente TrustedHosts (solo pruebas)
winrm set winrm/config/client @{TrustedHosts="\"}

\:: Ver últimos eventos de Forwarding en el origen
wevtutil qe Microsoft-Windows-Forwarding/Operational /c:20 /rd\:true /f\:text

\:: Ver actividad del colector
wevtutil qe Microsoft-Windows-EventCollector/Operational /c:20 /rd\:true /f\:text

Criterio de éxito

  • Test-WsMan <WEC> devuelve información del servicio sin errores.
  • Desaparecen los Eventos 105 en el registro del origen.
  • Los eventos empiezan a llegar de forma sostenida al colector WEC.

Conclusión

Este problema de WEF “conectado pero sin eventos” casi siempre se reduce a un mismatch de SPN durante la negociación Kerberos. La vía más rápida para restablecer el flujo es forzar spn_prefix=HOST en el cliente y/o registrar el SPN WSMAN correcto en la cuenta de equipo del WEC. A partir de ahí, estandariza FQDN, consolida listeners (idealmente HTTPS) y automatiza la configuración vía GPO. Con estas acciones, tu canal de reenvío volverá a ser confiable, seguro y fácil de operar.

Windows Server
Índice