Troubleshooting
Problem
Unable to establish remote PowerShell sessions (Enter-PSSession or Invoke-Command) to Windows servers when default HTTP Service Principal Names (SPNs) are registered to a non-computer service account.
Symptom
When attempting to connect via PowerShell Remoting, the following error is returned:
Connecting to remote server <FQDN> failed with the following error message:
WinRM cannot process the request. The following error with error code 0x80090322 occurred while using Kerberos authentication:
An unknown security error occurred.
In Kerberos ticket decryption logs or Wireshark captures, the error KRB5KRB_AP_ERR_MODIFIED may be observed.
Cause
The HTTP/<servername> and HTTP/<serverfqdn> SPNs are registered to a service account (e.g., for SQL Server Reporting Services, SharePoint, Microsoft Dynamics, etc.) instead of the computer account. When WinRM attempts Kerberos authentication using these default HTTP SPNs, the target server is unable to decrypt the ticket because the encryption key belongs to the service account, not the computer account running the WinRM service. This triggers the 0x80090322 error.
Environment
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Any server where third-party applications have registered HTTP SPNs on a service account.
Diagnosing The Problem
Verify Conflicting SPN Registration On a domain controller or any machine with AD PowerShell tools, run:
setspn -Q http/<ServerName.FQDN>
setspn -Q http/<ServerName.FQDN>
Confirm whether the SPN is registered to a user/service account instead of the computer account (HOST/
Check WinRM Client Configuration On the machine initiating the connection, run:
winrm get winrm/config/client
Expected relevant settings:
Auth → Basic = false
Auth → Kerberos = true
Auth → Negotiate = true
Default Ports → HTTP: 5985, HTTPS: 5986
- Confirm Application Requirement for HTTP SPN Verify if SQL Server Reporting Services, SharePoint, Microsoft Dynamics, or similar applications are installed and configured to run under a service account that requires the HTTP SPN.
- (Optional) Network Trace Confirmation Perform a simultaneous Wireshark capture on both the client and target server. Look for:
Client sending a POST /wsman request over port 5985
Server responding with KRB Error: KRB5KRB_AP_ERR_MODIFIED
Resolving The Problem
Preferred Resolution – Include Port in SPN (Recommended) Force PowerShell Remoting to include the port number in the SPN (WSMAN/<server>:5985), which is owned by the computer account and not conflicted.
On the initiating machine, use:
PowerShell
$opt = New-PSSessionOption -IncludePortInSPN
Enter-PSSession -ComputerName <ServerName_or_FQDN> -SessionOption $opt
or for persistent sessions:
PowerShell
Invoke-Command -ComputerName <ServerName_or_FQDN> -SessionOption (New-PSSessionOption -IncludePortInSPN) -ScriptBlock { <commands> }
Alternative Resolution – Force WinRM Client to Use WSMAN SPN Prefix Configure the client to request WSMAN/<server> SPNs instead of HTTP/<server> SPNs.
On the initiating machine, create the following registry key:
- Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client
- Name: spn_prefix
- Type: REG_SZ
- Value: WSMAN
After adding the key, restart PowerShell or the machine. Subsequent connections will use WSMAN SPNs, avoiding the conflicting HTTP SPNs entirely.
Both solutions are safe and do not require modification or removal of the application-required HTTP SPNs.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
26 November 2025
UID
ibm17252832