Answered by:
Enter-PSSession: WinRM cannot process the request, Kerberos authentication error 0x80090322

Question
-
Hi!
I've configured PowerShell Remoting on the server using Enable-PSRemoting commandlet.
But when I'm trying to connect to the server I'm constantly getting the following error:
PS C:\Users\sergeyp> Enter-PSSession SERVERNAME.DOMAINNAME.com Enter-PSSession : Connecting to remote server SERVERNAME.DOMAINNAME.com failed with the following error message : 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. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + Enter-PSSession SERVERNAME.DOMAINNAME.com + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (SERVERNAME.DOMAINNAME.com:String) [Enter-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
Also, in the System event log on a client computer I see the Security-Kerberos error described here:
http://technet.microsoft.com/en-us/library/52ddf7d9-a0e7-4c9d-be3c-3c35219f2d69.aspxError details:
Log Name: System Source: Microsoft-Windows-Security-Kerberos Date: 2/22/2013 1:42:39 PM Event ID: 4 Task Category: None Level: Error Keywords: Classic User: N/A Computer: ... Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server
SERVERNAME$. The target name used was HTTP/SERVERNAME.DOMAINNAME.com.
This indicates that the target server failed to decrypt the ticket
provided by the client. This can occur when the target server principal
name (SPN) is registered on an account other than the account the target
service is using. Please ensure that the target SPN is registered on,
and only registered on, the account used by the server. This error can
also happen when the target service is using a different password for
the target service account than what the Kerberos Key Distribution
Center (KDC) has for the target service account. Please ensure that the
service on the server and the KDC are both updated to use the current
password. If the server name is not fully qualified, and the target
domain (DOMAINNAME.COM) is different from the client domain
(DOMAINNAME.COM), check if there are identically named server accounts
in these two domains, or use the fully-qualified name to identify the
server.
...And... I have identical WinRM configuration on the other server, and it works fine.
I'm using Windows Server 2008 Standard SP2 and PowerShell 3.0.
I'm logging in as a domain user.
Both client and server are in the same domain.
The SPN HTTP/SERVERNAME.DOMAINNAME.com doesn't exist, but the corresponding SPN also doesn't exist for the computer on which PS Remoting works fine!
Could somebody help me with identification of this error source, please?
- Edited by Sergey Popov Friday, February 22, 2013 9:22 PM
Friday, February 22, 2013 9:21 PM
Answers
-
Hi Sergey,
In my opinion, it's possible that the existing HTTP/SERVERNAME SPN registered under the domain account is related the error. Please try the action below:
1. On the server, change IIS application pool to run under Local System.
2. Run the following commands to remove existing SPN:
setspn -D HTTP/SERVERNAME <domain account>
setspn -D HTTP/SERVERNAME.DOMAINAME.COM <domain account>
3. Then connect to the server again to see what will happen.
If the issue remains, disable Kernel mode authentication in IIS management console.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Wednesday, February 27, 2013 7:12 AM
All replies
-
Hi,
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Best Regards,
Aiden
If you have any feedback on our support, please click here
Aiden Cao
TechNet Community SupportMonday, February 25, 2013 2:27 AM -
Are you using the same credentials for both machines?
[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
Monday, February 25, 2013 2:49 AM -
Yes, I'm using my domain account.Monday, February 25, 2013 2:55 AM
-
Thank you, Aiden!Monday, February 25, 2013 2:56 AM
-
Use "setspn -l SERVERNAME" to check if the SPNs below are regisered:
WSMAN/SERVERNAME
WSMAN/SERVERNAME.DOMAINNAME.comRun "setspn -X" to confirm there does not exist duplicate SPN related the server.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Monday, February 25, 2013 6:17 AM -
Hi Diana!
Thank you for your help!
The SPNs listed bellow exist:
WSMAN/SERVERNAME
WSMAN/SERVERNAME.DOMAINNAME.comAlso, I've run "setspn -X" and it found 9 groups of duplicate SPNs, but no one of these SPNs is related to this server.
Monday, February 25, 2013 5:31 PM -
Log onto one of domain controllers, find and then right-click the server computer account, check if the option checked is the same as other working server. If they are not same, make change to the server computer account and choose same option.
In addition, run "setspn -q HTTP/SERVERNAME.DOMAINNAME.com" and "setspn -q HTTP/SERVERNAME" to check if these two SPNs are registred under other user objects.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Tuesday, February 26, 2013 9:46 AM -
Hi Diana!
I've run "setspn -Q HTTP/SERVERNAME" and yes, these SPNs are registered under the domain account which we use to run some application services.
Is this the reason? Should I delete these SPNs?
Is it possible to get any errors if I delete these SPNs?
Unfortunately, I'm unable to check delegation settings right now, but will do it ASAP.
- Proposed as answer by Mzzchun Wednesday, April 10, 2019 7:19 AM
Tuesday, February 26, 2013 2:24 PM -
Hi Diana!
I've checked delegation settings. For both servers it is "Do not trust this computer for delegation".
Tuesday, February 26, 2013 4:26 PM -
Hi Sergey,
In my opinion, it's possible that the existing HTTP/SERVERNAME SPN registered under the domain account is related the error. Please try the action below:
1. On the server, change IIS application pool to run under Local System.
2. Run the following commands to remove existing SPN:
setspn -D HTTP/SERVERNAME <domain account>
setspn -D HTTP/SERVERNAME.DOMAINAME.COM <domain account>
3. Then connect to the server again to see what will happen.
If the issue remains, disable Kernel mode authentication in IIS management console.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Wednesday, February 27, 2013 7:12 AM -
Hi Sergey,
Any update?
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Friday, March 1, 2013 2:09 AM -
Hi Diana!
Thank you very much for your help! After deleting SPNs PowerShell Remoting works fine.
Tuesday, March 5, 2013 7:52 PM -
Hi Sergey,
In my opinion, it's possible that the existing HTTP/SERVERNAME SPN registered under the domain account is related the error. Please try the action below:
1. On the server, change IIS application pool to run under Local System.
2. Run the following commands to remove existing SPN:
setspn -D HTTP/SERVERNAME <domain account>
setspn -D HTTP/SERVERNAME.DOMAINAME.COM <domain account>
3. Then connect to the server again to see what will happen.
If the issue remains, disable Kernel mode authentication in IIS management console.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Hi Diana,
i have the same problem (and if i delete HTTP SPN, all is OK), but i can't delete it. The SPN using NAVISION and CRM server. If i delete it, the NAVISION is not autorize on HTTP web services...
Is there any way how to fix issue with PowerShell Remoting?
Thanks
Honza Cerny
Wednesday, February 26, 2014 2:52 PM -
Hi Honza,
Did you ever find a solution as I am experiencing the same issue and I cannot remove the SPN either?
Thanks,
Emma
Friday, January 30, 2015 11:33 AM -
I am also experiencing this issue but cannot remove the SPNs. Has anyone found a solution?Wednesday, March 30, 2016 3:44 PM
-
As I have seen in this link:
https://www.reddit.com/r/PowerShell/comments/3ze9pp/cannot_use_powershell_remoting_when_a_http_spn/
You can create a port specific spn:
SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME
SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME
and then create a session using an option:
# Create and use session
$sessionOptions = New-PSSessionOption -IncludePortInSPN Enter-PSSession -Computername <computername> -SessionOption $sessionOptions
- Edited by Marcos Paulo Amorim Monday, July 18, 2016 11:13 PM
- Proposed as answer by erpomik Wednesday, December 5, 2018 2:26 PM
Monday, July 18, 2016 11:10 PM -
Hello,
and what shall I do, if I want to run the webapp pool with a domain account?
Is there an other solution?
Markus
Thursday, January 18, 2018 6:35 PM -
Try Below cmdlt:
Enter-PSSession -ComputerName pc1 -EnableNetworkAccess -Credential Domain\Username
Tuesday, April 3, 2018 11:21 AM -
Since this is the highest-ranked Technet forums result for this issue, I thought I'd put my solution here.
I had the same problem on one of my DCs. All the following were fine on the problem DC:
- SPNs for WSMAN were registered fine
- Running "winrm id" locally on the DC showed WINRM was running fine
- Port 5085 was listening and not blocked by firewall
However, while Test-WSMan from another DC appeared to show WINRM was available remotely, Winrm id -r:DCName failed with error 0x80090322.
In my situation, I found that while none of the other DCs had an SPN registered for HTTP, running SETSPN -q http/DCName found the HTTP SPN was bound to a service account.
Previously, the DC had been running Certificate Services, but this had been decommissioned. I've seen numerous other instances reported where an HTTP SPN for a web service running on a DC has caused clashes with WSMAN.
Running SETSPN -d http/DCName svc_account to simply delete the HTTP SPN from the account immediately fixed the problem.
- Edited by TracMac Wednesday, October 24, 2018 4:42 AM formatting
Wednesday, October 24, 2018 4:31 AM -
As I have seen in this link:
https://www.reddit.com/r/PowerShell/comments/3ze9pp/cannot_use_powershell_remoting_when_a_http_spn/
You can create a port specific spn:
SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME
SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME
and then create a session using an option:
# Create and use session
$sessionOptions = New-PSSessionOption -IncludePortInSPN Enter-PSSession -Computername <computername> -SessionOption $sessionOptions
Hello Marcos
This hint just saved my day, thank you for posting.
Only thing I would want to add, is that if you need secure PS Remoting, the port number is 5986.
Wednesday, December 5, 2018 2:30 PM -
Old topic, but the question still seems to pop on occasion and with quite a few backlinks to this thread. Everyone seems to focus on how to fix WinRM, but how about fixing the culprit? An option to consider in cases where a HTTP/hostname based SPN is creating an issue is to simply configure the HTTP based service to listen under a different name...
Fictitious example:
Breaks WinRM
Server: crmserver.contoso.com
SPN: HTTP/crmserver & HTTP/crmserver.contoso.com (typically on some service account for delegation)Fixes WinRM
Server: crmserver.contoso.com
DNS: crm.contoso.com (Additional DNS entry of type HOST, not CNAME which breaks Kerberos)
SPN: HTTP/crm & HTTP/crm.contoso.com (typically on some service account for delegation)
Other items to consider: Webserver bindings and certificate updates
HTH,-TGP
- Edited by Terry Phillips Monday, July 15, 2019 5:41 AM
Monday, July 15, 2019 5:40 AM -
Hi, i encountered a similar issue. After setting up the procedures for WinRM and i attempted to try #enter-pssession
My particular serverA is able to access serverB via #enter-pssession serverB on powershell , however when i attempt to #enter-pssession serverA (which is its own server) , i encountered the above errors similar to the original poster.
Using serverB, i am able to #enter-pssession serverA and also #enter-pssession serverB without any issues.
What would be the likely cause of that? They are all in the same domain, the setspn -l are equivalent on both serverA and serverB. TCP 5985 are both on listening mode. WinRM service is running too.
Saturday, August 3, 2019 2:07 AM -
I was getting that same error 'currently no logon servers available'
Instead of using credentials Domain\Username Try Username@Domain.com or the UPN of your account
Tuesday, August 6, 2019 2:39 PM -
If you need to retain the HTTP/SERVERNAME <DomainAccount> configuration , I found this very helpful
www dot reddit dot com/r/PowerShell/comments/3ze9pp/cannot_use_powershell_remoting_when_a_http_spn/
---
FYI: Someone sent me this outside of Reddit which may be useful to people:
Create a port-specific SPN
SetSPN.exe -s HTTP/$($env:COMPUTERNAME):5985 $env:COMPUTERNAME
SetSPN.exe -s HTTP/$($env:COMPUTERNAME).$($env:USERDNSDOMAIN):5985 $env:COMPUTERNAME
Then create a PSSession object using the -IncludePortInSPN parameter.
$sessionOptions = New-PSSessionOption -IncludePortInSPN
Enter-PSSession -Computername <computername> -SessionOption $sessionOptio
---
And check out the "IncludePortInSPN" option - on microsoft powershell new-pssessionoption documentation
docs dot microsoft dot com/en-us/powershell/module/microsoft.powershell.core/new-pssessionoption?view=powershell-6Tuesday, August 6, 2019 11:47 PM -
Dude, that exact solution was posted in this thread three years ago and is one of the two highest-ranked answers here.Friday, August 30, 2019 12:46 AM
-
Since this is the highest-ranked Technet forums result for this issue, I thought I'd put my solution here.
I had the same problem on one of my DCs. All the following were fine on the problem DC:
- SPNs for WSMAN were registered fine
- Running "winrm id" locally on the DC showed WINRM was running fine
- Port 5085 was listening and not blocked by firewall
However, while Test-WSMan from another DC appeared to show WINRM was available remotely, Winrm id -r:DCName failed with error 0x80090322.
In my situation, I found that while none of the other DCs had an SPN registered for HTTP, running SETSPN -q http/DCName found the HTTP SPN was bound to a service account.
Previously, the DC had been running Certificate Services, but this had been decommissioned. I've seen numerous other instances reported where an HTTP SPN for a web service running on a DC has caused clashes with WSMAN.
Running SETSPN -d http/DCName svc_account to simply delete the HTTP SPN from the account immediately fixed the problem.
Monday, December 2, 2019 4:06 PM