12

I am currently trying to enable Windows Remote Management (specifically, Powershell Remoting) between 2 untrusted domains, and having no luck.

A brief description of my setup:

  • domain1 - my workstation is on this domain
  • domain2 - the server I wish to connect to is on this domain

There is no trust between these domains.

I'm attempting to create the Powershell remote connection using the following commands from my workstation (joined to domain1):

param (
    [Parameter(Mandatory=$True)]
    $server
)

$username = "domain\user"
$password = read-host "Enter Password for $username" -AsSecureString

$credential = New-Object System.Management.Automation.PSCredential($username, $password)

$session = New-PSSession "$server" -Authentication CredSSP -Credential $credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $session

Which results in the following error message:

New-PSSession : [computername.domain2.com] Connecting to remote server computername.domain2.com failed with the following error message : The WinRM client
cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted. The identity of the target
computer can be verified if you configure the WSMAN service to use a valid certificate using the following command: winrm set winrm/config/service '@{CertificateThumbprint=""}'  Or
you can check the Event Viewer for an event that specifies that the following SPN could not be created: WSMAN/. If you find this event, you can manually create the SPN using
setspn.exe .  If the SPN exists, but CredSSP cannot use Kerberos to validate the identity of the target computer and you still want to allow the delegation of the user credentials to the target
computer, use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials with NTLM-only
Server Authentication.  Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be
one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. Try the request again after these changes. For more information, see the about_Remote_Troubleshooting Help topic.

I have tried/verified the following things:

  1. I verified that an SPN exists for both WSMAN\computername & WSMAN\computername.domain2.com in domain2.
  2. Verified that Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials with NTLM-only Server Authentication was set correctly.
  3. Configured winrm on the target computer to use ssl.
  4. Configured CredSSP on the target computer and my local workstation using the following commands:
Enable-WSManCredSSP -Role Server #on the target computer
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
  1. I've verified that no FW rules, either local to the computers on or the network are blocking my access.

None of which have allowed me to successfully connect to the target computer in domain2 from my workstation in domain1. I can successfully connect to other servers that are joined to domain1, just not servers in domain2. Is there anything else I should be looking for and/or try to get this to work?

UPDATE 06/08/2015 I have in fact been able to verify that I can connect to the server from my workstation without using CredSSP, which would be fine; however, I need to be able to run scripts against SharePoint, and doing so without CredSSP fails with a permissions error.

Nick DeMayo
  • 287
  • 4
  • 14
  • Have you tried being more specific about what you're delegating your credentials to? For example `Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com` (https://msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx, point 3.) – john Jun 08 '15 at 13:53
  • There's also this: http://serverfault.com/questions/277573/cannot-get-credssp-authentication-to-work-in-powershell – john Jun 08 '15 at 13:53
  • Unfortunately, none of those suggestions have worked. – Nick DeMayo Jun 08 '15 at 15:06
  • Try cd WSMan:\localhost\Client followed by Set-Item .\TrustedHosts -Value "*" -Force – Drifter104 Jun 08 '15 at 15:47
  • Nope, that doesn't work either I'm afraid; same error message. – Nick DeMayo Jun 08 '15 at 15:49
  • 1
    Have you reviewed this https://msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx – user2320464 Jun 08 '15 at 23:29
  • 1
    Oooo! I found the answer in the article you linked too. I had tried in the past setting "AllowFreshCredentialsDomain" to have an SPN, but that didn't work. Turns out, I could set "AllowFreshCredentialsWhenNTLMOnly" and "AllowFreshCredentialsWhenNTLMOnlyDomain" and it works! user2320464, if you could please post your comment as an answer, I will accept it and you get the bounty! – Nick DeMayo Jun 09 '15 at 10:48
  • @NickDeMayo - That's great news! Glad it worked and thanks for the bounty! – user2320464 Jun 10 '15 at 15:03
  • @user2320464 I edited your answer below to specify the portion of the article that solved my issue, accepted, and awarded the bounty. Thanks so much! – Nick DeMayo Jun 10 '15 at 15:04

1 Answers1

2

This MSDN article shows how to configure WinRM for multi-hop support which also addresses making connections when Kerberos is not an option. Brief summary below.

Windows Remote Management (WinRM) supports the delegation of user credentials across multiple remote computers. The multi-hop support functionality can now use Credential Security Service Provider (CredSSP) for authentication. CredSSP enables an application to delegate the user's credentials from the client computer to the target server.

CredSSP authentication is intended for environments where Kerberos delegation cannot be used. Support for CredSSP was added to allow a user to connect to a remote server and have the ability to access a second-hop machine, such as a file share.

Specifically, the section in the article pertaining to the Registry Entry / Group Policy Setting AllowFreshCredentialsWhenNTLMOnly solved the issue I was having. From the article:

If neither Kerberos authentication nor certificate thumbprints are available, the user can enable NTLM authentication. If NTLM authentication is used, the Allow Fresh Credentials with NTLM-only Server Authentication (AllowFreshCredentialsWhenNTLMOnly) policy must be enabled, and an SPN with the WSMAN prefix must be added to the policy. This setting is less secure than both Kerberos authentication and certificate thumbprints, because credentials are sent to an unauthenticated server.

For more information about the AllowFreshCredentialsWhenNTLMOnly policy, see the policy description provided by the Group Policy editor and KB 951608. The AllowFreshCredentialsWhenNTLMOnly policy is located at the following path: Computer Configuration\Administrative Templates\System\Credentials Delegation.

Community
  • 1
user2320464
  • 759
  • 5
  • 14