Errore 0x80090322 WinRM e WEF: come risolvere i conflitti SPN Kerberos su Windows Server

Una sottoscrizione WEF su Windows Server 2019 non inoltra eventi e nel log compare “WinRM cannot process the request” con codice 0x80090322. Nella maggior parte dei casi è un problema di Kerberos dovuto a SPN errato o duplicato. In questa guida trovi diagnosi, cause e soluzioni collaudate.

Indice

Sintomi e messaggi nel registro

Quando una sottoscrizione Windows Event Forwarding smette di consegnare eventi, sul forwarder (sorgente) compaiono errori nel canale Microsoft‑Windows‑Forwarding/Operational con Event ID 105:

WinRM cannot process the request.
Errorcode 0x80090322 occurred while using Kerberos authentication:
An unknown security error occurred.

Il codice 0x80090322 corrisponde a SECEWRONG_PRINCIPAL: il client Kerberos non trova un Service Principal Name coerente per il servizio a cui sta tentando di connettersi. In altre parole, l’SPN atteso non coincide con quello registrato in Active Directory.

Cosa significa l’errore Kerberos

Kerberos identifica i servizi tramite un Service Principal Name nel formato PREFIX/host[:porta]. Per WinRM su HTTP il prefisso predefinito è HTTP e l’SPN atteso è in genere HTTP/<FQDN> o HTTP/<hostname>. Se quell’SPN è registrato su un account diverso da quello che esegue il servizio (tipicamente l’account computer del collector), l’autenticazione fallisce con SECEWRONG_PRINCIPAL. I conflitti più comuni si verificano quando IIS, SSRS o altri servizi web hanno registrato HTTP/<FQDN> sul proprio account di servizio.

Perché accade spesso con WEF e WinRM

Trasporto HTTP – WinRM usa HTTP sulla porta 5985; molti servizi si appoggiano allo stesso prefisso SPN.
FQDN nel criterio – Le GPO di WEF spesso indicano il collector con FQDN; ciò forza il client a cercare HTTP/<FQDN>.
Ambienti misti – In laboratorio, senza IIS o servizi collaterali, non ci sono conflitti; in produzione lo stesso SPN è già “posseduto” da un altro account.

Soluzione rapida

La via più veloce per rimettere in moto il forwarding è:

Verificare se HTTP/<FQDN> è registrato su un account “sbagliato”.
Registrare un SPN dedicato per WinRM (con porta) sull’account computer del collector oppure modificare il prefisso SPN usato dal client WinRM, ad esempio in HOST o WSMAN, così da evitare collisioni.
Riavviare WinRM e il servizio di inoltro eventi.
Pulire la cache Kerberos e verificare lo stato della sottoscrizione.

Procedura dettagliata passo per passo

Verifica di SPN in conflitto

Esegui la ricerca dell’SPN su un Domain Controller o su una macchina con RSAT:

setspn -Q HTTP/<FQDN>
setspn -Q HTTP/<hostname>
setspn -X -F

-Q cerca un SPN specifico, -X -F individua duplicati in tutta la foresta. Se HTTP/<FQDN> risulta associato a un account di servizio (es. svc_iis) anziché all’account computer del collector, Kerberos non può mappare correttamente la destinazione del ticket.

Registrazione di un SPN dedicato per WinRM

Se non puoi rimuovere o spostare l’SPN in conflitto, registra un SPN con porta sull’account computer del collector. L’uso della porta rende l’SPN univoco e non interferisce con IIS o altri servizi.

# Esempio: collector EVT-COL01.contoso.local
Registrazione su account computer (il suffisso $ è facoltativo)
setspn -S HTTP/EVT-COL01.contoso.local:5985 EVT-COL01$
setspn -S HTTP/EVT-COL01:5985 EVT-COL01$  # opzionale, per short name

Verifica

setspn -L EVT-COL01$

Nota: se registri l’SPN con porta, il client deve includere la porta nell’SPN durante la negoziazione (vedi sezione su session option e prefisso SPN).

Modifica del prefisso SPN usato dal client WinRM

Per evitare completamente le collisioni su HTTP, puoi istruire WinRM a usare un prefisso differente. Sono comuni due alternative:

WSMAN – prefisso “neutro” pensato per WinRM/WSMan.
HOST – prefisso generico che si risolve automaticamente sull’account computer.

La modifica si applica sul forwarder (le macchine sorgenti che inviano gli eventi). Crea o modifica il valore stringa nella chiave di registro seguente. In alcune edizioni il nome del valore è spn_prefix, in altre documentazioni può essere riportato come spnprefix; verifica la presenza di entrambi.

REM Imposta il prefisso SPN su HOST
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" /v spnprefix /t REGSZ /d "HOST" /f

REM In alternativa, imposta il prefisso su WSMAN
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" /v spnprefix /t REGSZ /d "WSMAN" /f

REM Facoltativo: se la tua build usa il nome senza underscore
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" /v spnprefix /t REG_SZ /d "HOST" /f

Dopo la modifica, WinRM proverà SPN quali HOST/<FQDN> o WSMAN/<FQDN> anziché HTTP/<FQDN>, aggirando il conflitto.

Inclusione della porta nell’SPN dalla sessione PowerShell

Per test mirati o in ambienti dove hai creato un SPN con porta, puoi forzare il client a includere la porta nell’SPN:

Enter-PSSession -ComputerName EVT-COL01.contoso.local `
  -SessionOption (New-PSSessionOption -IncludePortInSPN)
oppure Test-WSMan con Kerberos
Test-WSMan EVT-COL01.contoso.local -Authentication Kerberos

Questa opzione è utilissima per verifiche interattive e per convalidare che l’SPN HTTP/<FQDN>:5985 sia effettivamente utilizzabile prima di distribuire la modifica in produzione.

Riavvio dei servizi e pulizia della cache

# Sul forwarder
klist purge
Restart-Service winrm
Restart-Service wecsvc

Sul collector

Restart-Service winrm
Restart-Service Wecsvc

La purga della cache Kerberos elimina ticket obsoleti che potrebbero mantenere il comportamento precedente nonostante la correzione degli SPN.

Verifiche finali dopo la correzione

WinRM – winrm quickconfig senza errori; winrm get winrm/config per controllare listener e autenticazione.
Stato sottoscrizione – su collector apri Event Viewer → Subscriptions e conferma lo stato Running.
Eventi di conferma – sul collector cerca Event ID 100/101 e sui forwarder Event ID 102/103 nei rispettivi canali operativi.

Accorgimenti e buone pratiche

SPN univoci – Evita duplicati; usa setspn -X -F nei cicli di audit.
HTTPS – Valuta listener HTTPS su 5986. Con TLS puoi anche usare autenticazioni alternative, ma cura il ciclo di vita dei certificati.
TrustedHosts – Solo per lab, consente di bypassare il controllo SPN. Configurazione rapida: Set-Item WSMan:\localhost\Client\TrustedHosts "<collector FQDN>".
Orario allineato – Kerberos è sensibile allo skew. Verifica con w32tm /query /status.
GPO con FQDN – Nella policy Configure target Subscription Manager usa FQDN coerente con l’SPN previsto.

Diagnostica avanzata

Oltre al canale di Forwarding, altri log aiutano a confermare l’ipotesi SPN:

Microsoft‑Windows‑WinRM/Operational – fornisce dettagli sulla negoziazione di sicurezza.
System → Security‑Kerberos – eventi che indicano biglietti rifiutati o target principal name is incorrect.
Directory Service su DC – avvisi per SPN duplicati o non validi.

Comandi utili:

# Verifica listener e autenticazioni
winrm enumerate winrm/config/listener
winrm get winrm/config/service
winrm get winrm/config/client

Controllo SPN su AD con PowerShell

Import-Module ActiveDirectory
Get-ADObject -LDAPFilter "(servicePrincipalName=HTTP/EVT-COL01.contoso.local)" `
-Properties servicePrincipalName |
Select-Object Name, ObjectClass, servicePrincipalName

Stato WEF

wecutil qc
wecutil es
wecutil gs ""

Perché in laboratorio andava e in produzione no

Nel laboratorio, nessun servizio aveva rivendicato HTTP/<FQDN>; l’account computer del collector era l’unico candidato e Kerberos risolveva senza ambiguità. In produzione, invece, lo stesso SPN era già assegnato a un altro servizio (IIS, SSRS, proxy, reverse proxy o appliance). Cambiando il prefisso SPN sul client o registrando un SPN dedicato con porta, si elimina la collisione: Kerberos può mappare correttamente il servizio di destinazione e WinRM torna a funzionare.

Esempi pronti all’uso

Scenario con SPN dedicato e porta

# Registrazione SPN dedicato
setspn -S HTTP/wec01.contoso.local:5985 wec01$

Distribuzione GPO per forwarder

Configura Subscription Manager con FQDN coerente

Esempio stringa server:

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

Test esplicito della porta nello SPN

Enter-PSSession -ComputerName wec01.contoso.local -SessionOption (New-PSSessionOption -IncludePortInSPN)
Test-WSMan wec01.contoso.local -Authentication Kerberos

Scenario con prefisso SPN alternativo

REM Imposta prefisso su HOST per evitare conflitti con HTTP
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" /v spnprefix /t REGSZ /d "HOST" /f

REM Riavvio servizi e pulizia
powershell -NoProfile -Command "klist purge; Restart-Service winrm; Restart-Service wecsvc"

Domande frequenti

Posso “risolvere” passando a NTLM?
È sconsigliato. NTLM aggira il problema SPN ma indebolisce la sicurezza e introduce altri vincoli. Meglio correggere gli SPN o usare HTTPS.

Devo davvero includere la porta nello SPN?
Solo se registri l’SPN con porta. È una strategia per rendere l’SPN univoco senza toccare gli SPN già in uso da altri servizi.

Meglio HOST o WSMAN come prefisso?
Entrambi funzionano. HOST è spesso più “auto‑risolvente” perché punta all’account computer; WSMAN mantiene l’identità del protocollo e può essere preferito in ambienti standardizzati.

Serve il nome completo o basta il nome breve?
Uniforma i nomi: usa sempre l’FQDN nelle GPO e assicurati che l’SPN registrato corrisponda esattamente a quello risolto dal DNS.

Questa guida vale anche per versioni diverse da Windows Server 2019?
Sì, il meccanismo Kerberos e WinRM è lo stesso sulle versioni recenti di Windows Server; le schermate e alcuni nomi dei registri possono variare.

Playbook operativo

Passo	Azione	Dettagli
1	Verificare SPN in conflitto	`setspn -Q HTTP/<FQDN>` e `setspn -X -F`. Se `HTTP/<FQDN>` è su un altro account di servizio, Kerberos fallisce.
2	Registrare SPN dedicato	`setspn -S HTTP/<server>:5985 <server>$`. Per test: `Enter-PSSession` con `-IncludePortInSPN`.
3	Cambiare prefisso SPN usato da WinRM	Sul forwarder: `reg add ... /v spn_prefix /d "HOST"` (in alternativa “WSMAN”). La modifica evita collisioni con `HTTP/<FQDN>`.
4	Riavviare servizi	`Restart-Service winrm` e `Restart-Service wecsvc`; consigliata `klist purge`.
5	Verifica finale	`winrm quickconfig` senza errori; sottoscrizione in stato Running; eventi di conferma su forwarder e collector.

Checklist di chiusura

DNS risolve correttamente FQDN del collector.
SPN HTTP/<FQDN> non è duplicato o è stato sostituito da un SPN dedicato con porta.
Prefisso SPN del client impostato se necessario su HOST o WSMAN.
Servizi WinRM e Wecsvc riavviati, cache Kerberos pulita.
Eventi conferma ricevuti e sottoscrizione attiva.

Considerazioni di sicurezza

Preferisci Kerberos a NTLM; evita TrustedHosts in produzione.
Se passi a HTTPS, proteggi le chiavi, automatizza il rinnovo e limita i protocolli deboli.
Documenta gli SPN applicativi: un inventario riduce le collisioni future.

Conclusione e punti chiave

L’errore 0x80090322 in scenari WEF/WinRM è quasi sempre un sintomo di SPN errato o duplicato. La correzione passa da una diagnosi semplice (setspn) e da una delle due mosse: rimuovere o spostare l’SPN in conflitto, oppure indirizzare WinRM verso un prefisso diverso (HOST o WSMAN) e, se serve, usare un SPN con porta. Una volta allineata la configurazione, il forwarding riprende senza dover toccare password, domini o account di servizio.

Riferimenti

Documentazione Microsoft su errori di Kerberos con WinRM e indicazioni sul prefisso SPN alternativo.

Appendice: comandi più usati, pronti da incollare

# Ricerca e auditing SPN
setspn -Q HTTP/<FQDN>
setspn -Q HTTP/<hostname>
setspn -X -F

Registrazione SPN dedicato con porta

setspn -S HTTP/:5985 $

Eliminazione SPN conflittuale (se autorizzato)

setspn -D HTTP/ 

Prefisso SPN alternativo sul client

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" /v spnprefix /t REGSZ /d "HOST" /f

Verifiche

klist purge
winrm quickconfig
winrm get winrm/config
wecutil es
wecutil gs ""

Nota operativa: distribuisci la chiave di registro spn_prefix con una GPO Preferences → Windows Settings → Registry per assicurare coerenza su tutti i forwarder.

Caso reale semplificato

In produzione, il collector “COL‑PRD‑WEC01” non riceveva eventi. L’analisi ha mostrato HTTP/COL-PRD-WEC01.contoso.com registrato su un account di servizio IIS. È stata aggiunta sul computer del collector la voce HTTP/COL-PRD-WEC01.contoso.com:5985 e, sui forwarder, impostato spn_prefix=HOST. Dopo riavvio servizi e klist purge, i log hanno registrato gli eventi di conferma e la sottoscrizione è tornata operativa.

Avvertenze

La modifica degli SPN richiede privilegi adeguati; esegui gli interventi in finestra di manutenzione.
Assicurati che le policy di federazione o i proxy non alterino i nomi host visti dai client.
Evita modifiche massive e non coordinate agli SPN; usa sempre -S per prevenire duplicati involontari.

Riassunto esecutivo

Errore 0x80090322 = SPN non coerente.
Diagnosi con setspn e log Kerberos.
Fix con SPN dedicato o con prefisso alternativo (HOST/WSMAN), più riavvio servizi e pulizia cache.
Verifica con winrm quickconfig, eventi di conferma e stato sottoscrizione.