ID d'événement Windows 3603 – WinRM : Erreur d'authentification du service de gestion à distance

Commencez par vérifier l'état du service WinRM et la configuration de base sur les systèmes client et cible.

Étape 1 : Ouvrez PowerShell en tant qu'administrateur et vérifiez l'état du service WinRM :

Get-Service WinRM
Get-WSManInstance -ResourceURI winrm/config

Étape 2 : Vérifiez que WinRM est correctement configuré pour la télécommande :

winrm quickconfig
winrm get winrm/config

Étape 3 : Vérifiez le Visualiseur d'événements pour des informations d'erreur détaillées :

Accédez à Visualiseur d'événements → Journaux des applications et des services → Microsoft → Windows → WinRM → Opérationnel

Étape 4 : Testez la connectivité de base au système cible :

Test-WSMan -ComputerName TargetServer
Test-NetConnection -ComputerName TargetServer -Port 5985

Examinez la méthode d'authentification spécifique qui échoue et vérifiez la validité des identifiants.

Étape 1 : Vérifiez quelles méthodes d'authentification sont activées :

Get-WSManInstance -ResourceURI winrm/config/service/auth
Get-WSManInstance -ResourceURI winrm/config/client/auth

Étape 2 : Testez explicitement différentes méthodes d'authentification :

# Test avec des identifiants explicites
$cred = Get-Credential
Enter-PSSession -ComputerName TargetServer -Credential $cred -Authentication Kerberos

# Test de l'authentification NTLM
Enter-PSSession -ComputerName TargetServer -Credential $cred -Authentication NTLM

Étape 3 : Vérifiez la confiance de domaine et la synchronisation temporelle :

nltest /query /domain:YourDomain
w32tm /query /status
w32tm /resync

Étape 4 : Vérifiez les problèmes de ticket Kerberos :

klist
klist purge
# Ré-authentifiez-vous et testez à nouveau

Résolvez les échecs d'authentification Kerberos en vérifiant et configurant les noms principaux de service.

Étape 1 : Vérifiez les SPN existants pour l'ordinateur cible :

setspn -L TargetServer$
setspn -Q HTTP/TargetServer
setspn -Q HTTP/TargetServer.domain.com

Étape 2 : Enregistrez les SPN manquants s'ils ne sont pas trouvés :

# Enregistrez les SPN pour le compte de l'ordinateur
setspn -S HTTP/TargetServer TargetServer$
setspn -S HTTP/TargetServer.domain.com TargetServer$
setspn -S WSMAN/TargetServer TargetServer$
setspn -S WSMAN/TargetServer.domain.com TargetServer$

Étape 3 : Vérifiez que l'enregistrement des SPN a réussi :

setspn -L TargetServer$
# Recherchez les entrées HTTP et WSMAN

Étape 4 : Testez l'authentification Kerberos après l'enregistrement des SPN :

Test-WSMan -ComputerName TargetServer -Authentication Kerberos
Enter-PSSession -ComputerName TargetServer -Authentication Kerberos

Étape 5 : Vérifiez les SPN en double qui pourraient causer des conflits :

setspn -X -F

Résolvez les problèmes d'authentification des certificats en vérifiant la validité des certificats et les chaînes de confiance.

Étape 1 : Vérifiez la configuration de l'écouteur WinRM HTTPS :

winrm enumerate winrm/config/listener
# Recherchez les entrées de transport HTTPS

Étape 2 : Vérifiez le certificat dans le magasin de certificats de l'ordinateur local :

Get-ChildItem -Path Cert:\LocalMachine\My
# Vérifiez les certificats avec l'utilisation d'authentification serveur

Étape 3 : Créez un écouteur HTTPS si manquant :

# Trouvez l'empreinte numérique du certificat approprié
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*$env:COMPUTERNAME*"}

# Créez un écouteur HTTPS
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="$env:COMPUTERNAME"; CertificateThumbprint="$($cert.Thumbprint)"}

Étape 4 : Testez la connectivité HTTPS :

Test-WSMan -ComputerName TargetServer -UseSSL
Test-NetConnection -ComputerName TargetServer -Port 5986

Étape 5 : Vérifiez la chaîne de confiance du certificat :

# Vérifiez la validation de la chaîne de certificats
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq "YourCertThumbprint"}
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)

Activez la journalisation détaillée de WinRM et effectuez un dépannage au niveau du réseau pour des problèmes d'authentification complexes.

Étape 1 : Activez la journalisation analytique et de débogage de WinRM :

# Activer la journalisation opérationnelle de WinRM
wevtutil sl Microsoft-Windows-WinRM/Operational /e:true

# Activer la journalisation analytique pour un dépannage détaillé
wevtutil sl Microsoft-Windows-WinRM/Analytic /e:true
wevtutil sl Microsoft-Windows-WinRM/Debug /e:true

Étape 2 : Configurez la journalisation du client WinRM :

winrm set winrm/config/client @{LoggingLevel="Verbose"}
winrm set winrm/config/service @{LoggingLevel="Verbose"}

Étape 3 : Surveillez les tentatives d'authentification en temps réel :

# Surveiller les événements WinRM lors des tentatives d'authentification
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WinRM/Operational'; StartTime=(Get-Date).AddMinutes(-5)} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Étape 4 : Analysez le trafic réseau avec netsh :

# Démarrer la trace réseau
netsh trace start capture=yes provider=Microsoft-Windows-WinRM tracefile=winrm_trace.etl

# Reproduire le problème d'authentification
# Arrêter la trace
netsh trace stop

Étape 5 : Vérifiez les paramètres de stratégie de groupe affectant WinRM :

Accédez à Éditeur de stratégie de groupe → Configuration de l'ordinateur → Modèles d'administration → Composants Windows → Gestion à distance de Windows (WinRM)

# Interroger les clés de registre pertinentes
Get-ItemProperty -Path "HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service" -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client" -ErrorAction SilentlyContinue