Remote shell access to Exchange on separate domain

by czoller at 2012-10-03 07:29:41

I’m trying to be able to connect to an Exchange server on a different domain than the source workstation for the purpose of automated reporting based on PS scripts I’ve created. There is no trust between these domains, however I know domain admin credentials for the target domain. I’ve looked at tons of documents on how to make this work, yet I still get errors. I can create a new-pssession from PowerShell and connect to this server, but I cannot Connect-ExchangeServer via the EMS. I have added my source workstation to the TrustedHosts list on the target server. Also, there is no name resolution between these domains, but I’ve added it to my hosts file. I cannot seem to connect with either FQDN of the target Exchange server or the NetBIOS name. In doing some research, some are suggesting changing allowable authentication methods on the PS virtual directory, but I don’t know about doing this. Also, I’ve created the authentication token on the target server which allows authentication from machines on workgroups or other domains. I can connect to this target Exchange server via UNC path after authenticating as domain admin. Are there any other ideas? I’ve spent untold number of hours trying to make this work and am running out of ideas. Thanks in advance.
by DonJ at 2012-10-06 07:30:33
So, you’ve potentially got a few things going on. If you haven’t looked through the free "Secrets of PowerShell Remoting" at, I’d suggest that.

First, TrustedHosts isn’t used by the target server; it’s used by the initiating device (we’ll call it the Client). It must be used in conjunction with the -Credential parameter. If you add the target’s IP address to your client, you can connect via IP that way. This applies to PowerShell Remoting - e.g., New-PSSession, Invoke-Command, etc. Enter-PSSession is a good, interactive way to test that the connection is working. Changing permissions on the PowerShell directory has nothing whatsoever to do with Remoting.

Because you’re crossing domain trust boundaries, you can’t rely on the default Kerberos protocol, and in most places it’s the only one enabled by default. You probably want to enable something like Basic. That has to be done on the server, in the WS-MAN configuration, which you can access on its local WSMAN: drive - this can also be done via a GPO. On your client, it’s a parameter of New-PSSession (or Enter-PSSession, or whatever). It can also be persistently enabled on your local WSMAN: drive.

My suggestion would be to NOT run Connect-ExchangeServer on your client. Don’t rely on the Exchange tools you’ve installed locally (if at all) whatsoever. Instead, use either Enter-PSSession or Invoke-Command to load and run the commands on the server itself. That will help avoid a lot of the authentication issues, and get you down to dealing with basic Remoting, which is complex enough as it is. If you’re able to successfully run Enter-PSSession to connect, and able to load the Exchange module and run Exchange commands on the remote machine, I can show you how to make that more convenient and accessible from your client computer using implicit remoting. But getting the session up and running with the right credential is the first step.
by czoller at 2012-10-06 13:06:54
Don, thanks for your note. I’ve done the following:

1.) I am successful at Enter-PSSession from a machine bound to the same domain as the server of interest.
2.) I enabled basic authentication on this server through Set-Item WSMan:\localhost\Service\Auth\Basic $true.
3.) I entered the following command from my workstation on a different domain and still was not able to connect to a remote PowerShell session: Enter-PSSession -ComputerName <name_here> -Authentication Basic -Credential (Get-Credential). I tried both target domain administrator credentials and also local admin ones without any luck.
4.) Error message delivered is the following:

Enter-PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot process
the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration an
d try the request again. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:16
+ enter-pssession <<<< -computername <name_here> -authentication basic -credential (get-credential)
+ CategoryInfo : InvalidArgument: <name_here>:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed

As stated earlier, I have manually added the target computer name to my hosts file, because there is no conditional forwarder setup as you outlined in your document.
by czoller at 2012-10-06 18:04:41
Update: I was finally able to get it to work with Enter-PSSession. I changed the way the client machine was listed in TrustedHosts from;computer_name> to just <computer_name> and that seemed to do it. I also had to authenticate using the domain admin account; strangely I was seeing "access denied" when I tried to use the local administrator’s account. Now, I’m trying to New-PSSession to import the Exchange cmdlets via
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://COMPUTERNAME/PowerShell -credential DOMAIN\ADMINISTRATOR
I also made sure that basic authentication was enabled, yet I see the following error:

[COMPUTERNAME] Connecting to remote server failed with the following error message : The WinRM client cannot process th
request. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (COMPUTERNAME:
0) returned an ‘access denied’ error. Change the configuration to allow Negotiate authentication mechanism to be used
r specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer na
e as the remote destination. Also verify that the client computer and the destination computer are joined to a domain.
To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user
name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_T
oubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) , PSRemotingTransportExc
+ FullyQualifiedErrorId : PSSessionOpenFailed
by czoller at 2012-10-06 19:55:07
Success finally!

This is what I had to do on the remote Exchange Server’s side: Enable Basic Authentication on PowerShell site. I also enabled Windows Authentication when this didn’t work. I then restarted the default site containing PowerShell. This still didn’t work, so I changed the New-PSSession to -ConnectionUri https://COMPUTERNAME/PowerShell/ and it worked.

After reading your ebook on the relevant sections, I gleaned an important bit of information I didn’t know: If not using SSL authentication with a cert (and therefore adding entries in the TrustedHost section), because this relies upon mutual authentication, you must add the opposite machine to the TrustHosts list for each server. If going from ClientA to ServerB, "ClientA" must be added to TrustedHosts on ServerB and "ServerB" must be added to ClientA’s TrustedHosts list.

Now, a couple questions:

1.) Most of the code samples I have seen describe creating an implicit session by specifying the Exchange server via HTTP. In most or all of these, the client and server reside in the same domain, and indeed, this worked for me in my home domain, but not going across domain boundaries without a trust. Is this the way it must be done in these cases, or have I missed something?
2.) Was it really necessary to enable Basic Authentication or Windows Authentication for the PowerShell module on the target Exchange server’s site?
3.) Aside from making sure that the TrustedHosts list on client and server just enable the opposite, can I take any steps to ensure I haven’t opened up unnecessary security risks? I probably need to go back and enable all hosts in the opposing domains in the TrustedHosts list since I’m trying to build this system out for future automation tasks, and all hosts on these domains are within a well-secured organization that does not allow open binding.

Thanks again, Don!
by DonJ at 2012-10-07 07:04:59
1. "Implicit session" doesn’t have any meaning. There’s something called "Implicit remoting," which in v2 uses the Import-PSSession cmdlet. It works identically to what you’ve seen - all remoting, in fact, uses the same technology. If you got it working with Enter-PSSession, the exact same configuration will work for other remoting techniques.

2. You didn’t enable it for the PowerShell module, you enabled it for WinRM/WS-MAN, which PowerShell utilizes. And yes, you did need to - the computers need a common authentication mechanism, and without a shared domain trust, Kerberos won’t do it.

3. Properly managing TrustedHosts is the biggest step, and you’ve done that. SSL (HTTPS) would be a much better approach, though. Trusted hosts does support wildcards - but avoid the generic "*" wildcard, meaning "all computers." Again, however, SSL would be better - no lists to manage at all that way.