Lorsque vos collecteurs Windows Event Forwarding (WEF) restent obstinément silencieux malgré une subscription « Connected », l’Event ID 105 (0x80090322) pointe très souvent vers un problème Kerberos : un SPN WinRM manquant ou inadapté. Voici un guide exhaustif pour diagnostiquer et corriger définitivement cette panne.
Problème posé
- Infrastructure WEF basée sur Windows Server 2019.
- La machine source apparaît Connected dans la console de la subscription, mais aucun événement n’est remonté.
- Le journal
Microsoft‑Windows‑Forwarding/Operationalgénère l’Event ID 105 : « WinRM cannot process the request … Kerberos authentication: An unknown security error occurred » (code 0x80090322).
Analyse des causes probables
| Piste | Détails utiles |
|---|---|
| SPN absent ou incorrect | Sans l’SPN WSMAN/nommachine:5985 enregistré dans Active Directory, Kerberos ne trouve pas de cible de service valide. |
| Configuration WinRM incomplète | Lorsque l’SPN « WSMAN » échoue, WinRM tente un SPN générique ; la session HTTP/5985 tombe alors en échec d’authentification. |
| Méthode d’authentification inadéquate | Kerberos est la valeur par défaut ; ni TrustedHosts ni HTTPS ne sont configurés, et Basic n’est pas activé (ou interdit par stratégie). |
| Problème de confiance inter‑domaines | Hors périmètre ici (mêmes domaines), mais à vérifier si plusieurs forêts ou domaines externes entrent en jeu. |
Décryptage du code d’erreur 0x80090322
Le code 0x80090322 correspond à l’erreur SEC_E_INTERNAL_ERROR. En clair, Kerberos n’est pas parvenu à construire ou valider le ticket de service. Les raisons possibles :
- L’SPN attendu n’existe pas ou correspond à plusieurs objets.
- Le compte de l’ordinateur cible présente une incohérence (mot de passe d’ordinateur verrouillé, servicePrincipalName tronqué, etc.).
- L’horloge système dérive de plus de 5 minutes entre client et KDC (tolérance Kerberos par défaut).
Comprendre le rôle des SPN dans WinRM et WEF
Un Service Principal Name est la balise qu’utilise Kerberos pour associer :
- Un service réseau (par ex.
WSMAN). - Le nom (DNS/NetBIOS/FQDN) de la machine.
- Le port ou le protocole (facultatif).
Lorsque vous lancez Test‑WSMan Collector01, le client tente de s’authentifier sur l’SPN WSMAN/Collector01:5985. Si celui‑ci n’est pas publié sur l’objet ordinateur Collector01$ dans AD, Kerberos échoue et WinRM se rabat sur NTLM (souvent désactivé) ou coupe la session, générant notre fameux Event ID 105.
Procédure de diagnostic pas à pas
1. Vérifier l’état du service WinRM
sc query winrm
netstat -ano | find ":5985"
2. Contrôler la connectivité réseau
Test-WSMan -ComputerName Collector01
ping Collector01
3. Inspecter les SPN existants
setspn -l Collector01
setspn -q WSMAN/Collector01*
Absence ou doublon ? Corrigez immédiatement :
setspn -s WSMAN/Collector01:5985 Collector01
4. Consulter les journaux d’audit Kerberos
Activez l’audit Kerberos Service Ticket Operations, puis recherchez des Event ID 4768/4769 présentant un code d’erreur.
5. Vérifier la dérive horaire
w32tm /query /status
Une dérive >300 s suffit à invalider le cache TGT.
Solutions proposées
Plusieurs approches sont possibles ; le tableau suivant synthétise leurs avantages et limites.
| Correctif | Points forts | Points de vigilance |
|---|---|---|
Créer l’SPN WSMAN/<machine>:5985 | Solution « officielle », compatible Kerberos et GPO par défaut. | Demande des droits d’écriture sur l’objet AD ; risque de doublon si plusieurs alias DNS. |
Forcer un préfixe SPN générique HOST | Simple clé Registre côté client ; évite la gestion manuelle des SPN. | Ne couvre pas les scénarios où un alias DNS différent est requis. |
| Basculer en HTTPS (port 5986) | Chiffrement natif TLS, possibilité de certificate mapping. | Nécessite un certificat serveur + GPO, complexifie l’automatisation initiale. |
Correctif validé : forcer le préfixe SPN « HOST »
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client `
/v spn_prefix /t REG_SZ /d "HOST" /f
Restart-Service WinRM
Le client WinRM construit alors l’SPN HOST/Collector01, constamment présent dans AD dès qu’un ordinateur rejoint le domaine. Résultat : Kerberos s’authentifie sans SPN WSMAN dédié, l’Event ID 105 disparaît et les événements ré-affluent vers le collecteur.
Validation post‑correctif
Test‑WSMan Collector01répond sans délai.- La colonne Source Computers dans la subscription affiche un débit d’événements croissant.
- Le journal
Microsoft‑Windows‑Forwarding/Operationalreste vierge d’Event ID 105 pendant au moins 24 h. - Les compteurs de performance WinRM: Total requests et Microsoft‑Windows‑Eventlog: Events forwarded confirment la reprise de la collecte.
Renforcer la sécurité et la résilience de WEF
1. Implémenter WinRM HTTPS
Créez un listener HTTPS via :
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="collector.contoso.com";CertificateThumbprint="AB12..."}
Appliquez ensuite une GPO pour forcer la connexion TLS et désactiver HTTP/5985.
2. Superviser les SPN
setspn -q WSMAN/* > C:\Temp\spn_wef.txt
Planifiez la commande via schtasks et comparez le résultat précédent afin de détecter un éventuel doublon ou suppression intempestive.
3. Automatiser via PowerShell DSC
Utilisez le module PSDesiredStateConfiguration pour décrire :
- Le listener HTTPS WinRM.
- La clé
spn_prefix. - Les règles de pare‑feu (5985 / 5986).
Ainsi, les écarts seront corrigés automatiquement à chaque cycle DSC.
FAQ
Pourquoi ne pas se contenter de TrustedHosts ?
TrustedHosts contourne la vérification DNS/Kerberos et ouvre la porte à des attaques de relais si un attaquant peut intercepter le trafic ; il est tolérable en labo mais jamais en production.
La clé spn_prefix est‑elle supportée par Microsoft ?
Oui : documentée dans la base de connaissances technet « Registry keys for WinRM ». Elle est fréquemment recommandée par le support lorsque des SPN dynamiques posent problème.
Que faire si plusieurs alias DNS pointent vers le même collecteur ?
Dans ce cas, créez explicitement un SPN WSMAN pour chaque alias ; le préfixe générique « HOST » ne couvrira pas ces noms additionnels.
Scripts PowerShell prêts à l’emploi
#region Diagnostics
$Server = "Collector01"
Write-Host "=== Test de connectivité WinRM ==="
Test-WSMan $Server
Write-Host "=== Liste des SPN existants ==="
setspn -L $Server
#endregion
\#region Correctif
\$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client"
If (-not (Test-Path \$RegPath)) { New-Item -Path \$RegPath -Force }
Set-ItemProperty -Path \$RegPath -Name "spn\_prefix" -Value "HOST"
Restart-Service WinRM -Force
\#endregion
\#region Validation
Start-Sleep -Seconds 15
Test-WSMan \$Server
Get-WinEvent -LogName "Microsoft-Windows-Forwarding/Operational" -MaxEvents 10 |
Where-Object { $\_.Id -eq 105 }
\#endregion Checklist finale avant mise en production
- Horloge synchronisée (NTP ou PDC Emulator).
- Pare‑feu ouvert en entrée 5986 (ou 5985) TCP.
- SPN WSMAN unique ou clé
spn_prefixdéployée. - Certificat serveur valide si HTTPS.
- Stratégie GPO verrouillant les méthodes d’authentification (NTLM désactivé, Kerberos prioritaire).
- Surveillance continue : journaux WEF + alertes SIEM.
Conclusion
L’Event ID 105 associé au code 0x80090322 sur une infrastructure WEF 2019 n’est pas une fatalité. En ciblant immédiatement la publication des SPN WinRM – ou en adoptant la clé Registre spn_prefix="HOST" – vous restaurez l’authentification Kerberos, sécurisez vos flux d’événements et consolidez la collecte centralisée indispensable à toute stratégie de monitoring moderne.