WinRM 0x8033809D and servicePrincipalNames

 

I had a brand new server that wasn’t letting me connect to it via WinRM.  Since we have an automated build process that configures the WinRM listener, and I could connect to other servers from the same batch, it was an unexpected failure.

Even locally on the server I couldn’t connect to WinRM.

C:\temp>winrm get winrm/config
WSManFault
    Message = WinRM cannot process the request. The following error occured while using Negotiate authentication: An unknown security error occurred.
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config.

Error number:  -2144108387 0x8033809D
An unknown security error occurred.

Following the advice in the error message I verified that duplicate SPNs were not the issue.  There was only one computer in the forest with that server’s name, and it was the expected object.

Once again NetMon to the rescue!

A network trace showed a Kerberos request for a ticket for the HTTP/<server FQDN> servicePrincipalName.  The ticket was obtained successfully, but then a second request for the same ticket.  I thought that was odd, so I searched the forest for that specific SPN.  It turns out we had reused the computer name from a decommissioned FIM instance and that the proxy account that previously ran Windows SharePoint Services had a SPN for HTTP/<server FQDN>.  There were not duplicate SPNs (HOST is an alias for many SPNs including HTTP) since there was only one instance of the HOST SPN and one instance of the HTTP SPN, but the SPN was placed on the wrong object, so the ticket was being encrypted with the wrong password.  Removing the old HTTP SPN from the WSS proxy account solved the problem.

So the key takeaway is WinRM relies on the HTTP/<server FQDN> SPN, which is a non-default SPN and is usually simply covered by the HOST/<server FQDN> SPN.  Ensuring the HTTP SPN is set correctly is a corner-stone for making WinRM function.