Windows Event ID 3065 – WinRM: WS-Management Service Authentication Error

Start by examining the detailed event information and current WinRM configuration:

1. Open Event Viewer → Applications and Services Logs → Microsoft → Windows → WinRM → Operational
2. Locate Event ID 3065 and note the error code, client IP, and authentication method
3. Check current WinRM configuration:

winrm get winrm/config
winrm enumerate winrm/config/listener

4. Verify WinRM service status:

Get-Service WinRM
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WinRM/Operational'; Id=3065} -MaxEvents 10

5. Review authentication methods enabled:

winrm get winrm/config/service/auth

Verify that remote connections work with known good credentials:

1. Test basic WinRM connectivity from the client machine:

Test-WSMan -ComputerName [TargetServer] -Port 5985
Test-WSMan -ComputerName [TargetServer] -Port 5986 -UseSSL

2. Attempt a PowerShell remote session with explicit credentials:

$cred = Get-Credential
Enter-PSSession -ComputerName [TargetServer] -Credential $cred

3. Check if the issue is specific to certain authentication methods:

Enter-PSSession -ComputerName [TargetServer] -Authentication Kerberos
Enter-PSSession -ComputerName [TargetServer] -Authentication NTLM

4. Verify time synchronization between client and server:

w32tm /query /status
w32tm /resync

If using HTTPS listeners, verify certificate validity and configuration:

1. Check SSL certificate binding for WinRM:

netsh http show sslcert
winrm enumerate winrm/config/listener

2. Verify certificate validity and chain:

Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*[ServerName]*"}
$cert = Get-ChildItem Cert:\LocalMachine\My\[Thumbprint]
$cert | Format-List *

3. Test certificate chain validation:

$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)

4. If certificate is expired or invalid, create a new HTTPS listener:

winrm delete winrm/config/listener?Address=*+Transport=HTTPS
$cert = New-SelfSignedCertificate -DnsName [ServerFQDN] -CertStoreLocation Cert:\LocalMachine\My
winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Hostname="[ServerFQDN]"; CertificateThumbprint="$($cert.Thumbprint)"}

Resolve Kerberos-specific authentication problems:

1. Check Service Principal Names (SPNs) for the target server:

setspn -L [ServerName]
setspn -Q HTTP/[ServerFQDN]

2. Verify Kerberos ticket cache on the client:

klist
klist purge

3. Check domain controller connectivity and time sync:

nltest /dsgetdc:[DomainName]
w32tm /query /peers

4. Enable Kerberos logging for detailed troubleshooting:

auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

5. Register missing SPNs if needed:

setspn -S HTTP/[ServerFQDN] [ServerName]
setspn -S HTTP/[ServerName] [ServerName]

Perform deep network analysis for complex authentication issues:

1. Enable WinRM analytic and debug logging:

wevtutil sl Microsoft-Windows-WinRM/Analytic /e:true
wevtutil sl Microsoft-Windows-WinRM/Debug /e:true

2. Capture network traffic during authentication attempts:

netsh trace start capture=yes tracefile=winrm_auth.etl provider=Microsoft-Windows-WinRM
# Reproduce the authentication failure
netsh trace stop

3. Analyze authentication flow with PowerShell cmdlets:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WinRM/Analytic'} | Where-Object {$_.Id -eq 3065}
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-1)}

4. Check registry settings for authentication behavior:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service" -Name auth_*
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client" -Name auth_*

5. Reset WinRM configuration if all else fails:

winrm invoke restore winrm/config @{}
Enable-PSRemoting -Force
Restart-Service WinRM