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?
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/
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.