Aug 08 2017 05:09 AM
Hello
I have the similar problem as described here
If I have server with installled IIS role and SPN was registered as HTTP/<Machine> <domain>\<service domain account> I cant connect to this server using remote powershell. Have an error.
“WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos 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.”
Workaround as described in article doesnt work for me.
//Alexander
Apr 30 2018 01:39 AM
Hi
I had the same problem and found a solution by Marcos Paulo Amorim in https://social.technet.microsoft.com/Forums/windows/en-US/a4c5c787-ea65-4150-8d16-2a19c569a589/enter...
It solved the first part of the problem, but I still find it somewhat ugly since I like all my servers accessible in the same way
Cheers,
Anders
Feb 13 2024 10:56 AM
For anyone else having this issue, if you need to actually keep the Http and Https SPNs registered to your Service account to manage the app pool of a website, the only way I found to resolve this was to remove the https/servername https/fqdn spns from the service account and add the ports to when adding hte SPNs back. example: https/servername:443 http/servername:80. I was trying to connection via Winrs over an https listener, and setting a WINRM SPN for the server did not work for me since the service account still had SPNs for the full port range of http and https.