Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

My question is similar to Powershell Remoting: One way trust, however there are differences and the resolution (adding the server to the trusted list) does not work for me.

I have two domains. DOMAIN and DOMAINDMZ. DOMAIN has an incoming trust from DOMAINDMZ. That is DOMAINDMZ trusts DOMAIN, but not vice versa.

I have an administrative user DOMAIN\myadmin who is a member of the Administrators local group on several servers in the DOMAINDMZ domain:,,, etc. I can log into these servers with DOMAIN\myadmin from the console or RDP.

I am attempting to log into SERVERA and run a PowerShell script on SERVERB using PowerShell remoting. Remote Management is enabled on SERVERB. I start an elevated PowerShell session on SERVERA, and then attempt to use the Invoke-Command cmdlet. I receive the following error:

PS C:\Windows\system32> Invoke-Command -ComputerName -ScriptBlock {hostname}    
[] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.
     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.
        + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
        + FullyQualifiedErrorId : PSSessionStateBroken

If I provide a credential object containing a user in the DOMAINDMZ domain, the error goes away and the scriptblock executes as expected:

PS C:\Windows\system32> Invoke-Command -ComputerName -Credential DOMAINDMZ\Administrator -ScriptBlock {hostname}

Given the error I suspect the issue is related to the trust and Kerberos, but I'm not clear what I can do to resolve. Should I be setting an SPN for DOMAIN\myadmin or SERVERB? Is there something else I can try?

share|improve this question
It sounds like you have an External trust (one-way, non-transitive forest trust) but I believe Kerberos authentication only works with a Forest trust (two-way, transitive forest trust). – joeqwerty Feb 28 '12 at 22:03
@joeqwerty Well that certainly complicates matters. – shufler Feb 28 '12 at 22:10

1 Answer 1

up vote 3 down vote accepted

As Joeqwerty said, it's usually accepted that you're going to be using NTLM auth with an external trust, and Kerberos with a forest trust.

However, it is possible to get Kerberos authentication working with an external domain, but there are conditions.

The trust has to be created using the fully qualified domain name (FQDN). Kerberos referral fails if the FQDN is missing from the Trusted Domain Object.

User name syntax is UPN and the UPN suffix is resolvable to a DC in DNS (implicit UPN)

UDP 389, UDP/TCP 88, and UDP/TCP 464 ports are open for the domain controllers in the user domain.

The server name in the trusting resource domain has to be the FQDN, and the domain suffix of the server name has to match the AD DS domain’s DNS FQDN.

If it's still causing you too much heartburn after that, I'd recommend switching to Negotiate authentication protected with SSL.

Some additional reading/references:

share|improve this answer
Thanks Ryan. I've seen this documentation and to my knowledge the environment meets all the conditions: FQDN was used to set up the trust. I have tried UPN syntax, ports are open (firewalls are disabled), and I've specified the FQDN of the server I'm connecting to (it's in the trusting domain), and the domain suffix matches DNS. – shufler Feb 28 '12 at 23:02
Bummer... I'll keep thinking about it and come back if I figure it out. :) – Ryan Ries Feb 28 '12 at 23:04
Not sure why I used an external trust. Changed the trust to a one-way forest trust and remoting works as expected. – shufler Feb 29 '12 at 15:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.