3

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.

Scenario:
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: servera.domaindmz.com, serverb.domaindmz.com, serverc.domaindmz.com, 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 serverb.domaindmz.com -ScriptBlock {hostname}    
[serverb.domaindmz.com] 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 serverb.domaindmz.com -Credential DOMAINDMZ\Administrator -ScriptBlock {hostname}
SERVERB

Question:
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?

shufler
  • 962
  • 1
  • 6
  • 18
  • 2
    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

2 Answers2

4

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:

http://technet.microsoft.com/en-us/library/dd560679(WS.10).aspx

http://jorgequestforknowledge.wordpress.com/2011/09/07/kerberos-authentication-over-an-external-trust-is-it-possible-part-1/

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 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 myadmin@domain.com, 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
0

If you end up down end up down this rabbit hole, and nothing else works...

https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/kfso-not-work-in-external-trust-event-is-17

Is the trick that finally fixed things for me.

Maybe it will help some other unlucky soul.

Symptoms
In Windows Server 2008 R2 and later versions of Windows Server, the following Group Policy settings can be used to configure KFSO:

Computer Configuration \ Administrative Templates \ System \ Kerberos \ Use Forest Search Order

Computer Configuration \ Administrative Templates \ System \ KDC \ Use Forest Search Order

With these settings configured, Kerberos authentication may work in external trusts in a single-domain forest environment. However, it may fail when the specified forest contains multiple domains.
stevens
  • 101
  • 1