CODEWITHSUNDEEP
powershellactive-directory
Manoj Rai
Manoj Rai

Reputation: 91

Remote PowerShell "WinRM cannot process the request." - works one way only

I have been having trouble executing PowerShell script on a remote server. Basically, I have 2 servers SERVER-A and SERVER-B.

Executing Invoke-Command and Enter-PSSession remote on SERVER-B works from SERVER-A, But I get * "WinRM cannot process the request. The following error with error code 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred..." when I do the other way.

I tried adding and removing SPN (HTTP & WSMAN) entry in both server and tested in each scenario, it stayed the same.

I did check the Firewall configuration and the windows remoting is enabled.

The only difference between the server is that SERVER-A is on a Private network and SERVER-B is on the domain network. I can't change the SERVER-A network to the domain as I think it is a primary domain controller.

I am a developer and do not have much experience in this field. Not sure how to make SERVER-B able to remote PowerShell in SERVER A.

EDIT

In the event viewer I see error:

I tried the above steps. But I see in the event viewer error that the method of authentication used was Kerberos. I see error: "The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SERVER$. The target name used was HTTP/SERVER.DOMAIN. 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. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.LOCAL) is different from the client domain (DOMAIN.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server."

Some suggested it might be due to client and DC time not being in sync, but I verified that it's the same.

Upvotes: 1

Views: 18489

Answers (3)

Manoj Rai
Manoj Rai

Reputation: 91

Sorry, I never got back to this issue but in my case, this seems to have errored since my client server had been turned off for a long time. Not sure If that's the case but it started working after couple of days later.

Upvotes: 0

Peter Widmer
Peter Widmer

Reputation: 132

I had the same errormessage. For me it worked, if I provided the credentials upfront (i.e. entering them manually when running the script, which is ok in my scenario). I guess, that the kerberos-ticket is already available then.

$cred = Get-Credential -UserName "YourDomain\YourUser" -Message "Enter your credentials"
$server = "YourServer"
invoke-command -Credential $cred -Authentication Credssp -ComputerName $server -ScriptBlock { Write-Host "test" }

Upvotes: 0

Kartik Bhiwapurkar
Kartik Bhiwapurkar

Reputation: 5159

• As you are conveying that Server A is a primary domain controller while Server B is a domain member system, then both the systems are bound by the security policies and defined directory schema of the domain authority. Thus, please check the below Group policy setting in your Group Policy server/AD server whether it is enabled or disabled. If it is enabled, then please disable it, as this setting will disable the authentication protocol negotiation for WinRM service.

‘ Group Policy Management -> Default Domain Policy -> Edit -> Computer Configuration -> Administrative Templates -> Windows Component -> Windows Remote Management -> WinRM Service -> Disallow Negotiate Authentication -> Disabled ’

• Once the above has been done, update the Group policy setting through the ‘gpupdate /force’ command on the Primary domain controller as well as the member server. Then restart the Windows Remote Management (WS-MAN) service on both. Then, please try changing the IIS application pool to run under ‘Local System’ and delete the existing SPNs as below and agin connect to the Server B to check. If the issue remains, disable Kernel mode authentication in IIS management console.

 ‘ setspn -D HTTP/SERVERNAME <domain account>
     setspn -D HTTP/SERVERNAME.DOMAINAME.COM <domain account> ‘

Also, please refer to this community thread below and try doing the steps as mentioned in it as it might help in executing Remote powershell scripts on the other Server without any issues as it is regarding adding DNS records in the DNS server and local hosts file too: -

https://serverfault.com/questions/877459/remote-powershell-not-working-but-test-wsman-does

Upvotes: 2

Related Questions