PowerShell remoting with a one-way trust

powershellwindows-server-2008-r2winrm

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?

Best Answer

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/

Related Solutions

Powershell Remoting: One way trust

The fact that you get a corporate ip doesn't necessary mean that you are on the same subnet / domain.

What kind of access do you have ? You could either create a reverse ssh tunnel from DMZ machines , or using a machine that have access to the DMZ as a proxy.

Powershell remoting to a server using CNAME, not COMPUTER NAME

What I did to resolve this issue was to create a proxy function for Enter-PSSession that resolves the CNAME for me. This might not work in your case, depending on why you need to use the CNAME, but this works for me.

Details on proxy powershell functions: http://www.windowsitpro.com/blog/powershell-with-a-purpose-blog-36/windows-powershell/powershell-proxy-functions-141413

Full function:

function Enter-PSSession {
[CmdletBinding(DefaultParameterSetName='ComputerName')]
param(
    [Parameter(ParameterSetName='ComputerName', Mandatory=$true, Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
    [Alias('Cn')]
    [ValidateNotNullOrEmpty()]
    [string]
    ${ComputerName},

[Parameter(ParameterSetName='Session', Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
[ValidateNotNullOrEmpty()]
[System.Management.Automation.Runspaces.PSSession]
${Session},

[Parameter(ParameterSetName='Uri', Position=1, ValueFromPipelineByPropertyName=$true)]
[Alias('URI','CU')]
[ValidateNotNullOrEmpty()]
[uri]
${ConnectionUri},

[Parameter(ParameterSetName='InstanceId', ValueFromPipelineByPropertyName=$true)]
[ValidateNotNull()]
[guid]
${InstanceId},

[Parameter(ParameterSetName='Id', Position=0, ValueFromPipelineByPropertyName=$true)]
[ValidateNotNull()]
[int]
${Id},

[Parameter(ParameterSetName='Name', ValueFromPipelineByPropertyName=$true)]
[string]
${Name},

[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[switch]
${EnableNetworkAccess},

[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[Parameter(ParameterSetName='Uri', ValueFromPipelineByPropertyName=$true)]
[system.management.automation.pscredential]
${Credential},

[Parameter(ParameterSetName='ComputerName')]
[ValidateRange(1, 65535)]
[int]
${Port},

[Parameter(ParameterSetName='ComputerName')]
[switch]
${UseSSL},

[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[Parameter(ParameterSetName='Uri', ValueFromPipelineByPropertyName=$true)]
[string]
${ConfigurationName},

[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[string]
${ApplicationName},

[Parameter(ParameterSetName='Uri')]
[switch]
${AllowRedirection},

[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[ValidateNotNull()]
[System.Management.Automation.Remoting.PSSessionOption]
${SessionOption},

[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[System.Management.Automation.Runspaces.AuthenticationMechanism]
${Authentication},

[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[string]
${CertificateThumbprint})


begin
{
    try {
        $outBuffer = $null
        if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer))
        {
            $PSBoundParameters['OutBuffer'] = 1
        }
        $PSBoundParameters['ComputerName'] = ([System.Net.Dns]::GetHostByName($PSBoundParameters['ComputerName'])).HostName
        $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Microsoft.PowerShell.Core\Enter-PSSession', [System.Management.Automation.CommandTypes]::Cmdlet)
        $scriptCmd = {& $wrappedCmd @PSBoundParameters }
        $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
        $steppablePipeline.Begin($PSCmdlet)
    } catch {
        throw
    }
}

process
{
    try {
        $steppablePipeline.Process($_)
    } catch {
        throw
    }
}

end
{
    try {
        $steppablePipeline.End()
    } catch {
        throw
    }
}
<#

.ForwardHelpTargetName Enter-PSSession
.ForwardHelpCategory Cmdlet

#>

}

The only line I added was:

$PSBoundParameters['ComputerName'] = ([System.Net.Dns]::GetHostByName($PSBoundParameters['ComputerName'])).HostName

This simply resolves the CNAME to the FQDN in the proxy function before calling the native Enter-PSSession.

This allows me to set *.mydomain.local in my TrustedHosts via Group Policy, and I can still use "Enter-PSSession ShortName" or "Enter-PSSession CNAME" without having to mess with additional SPNs, etc.

Best Answer

Related Solutions

Powershell Remoting: One way trust

Powershell remoting to a server using CNAME, not COMPUTER NAME

Related Topic