I configured a group policy for some systems in 1 domain to allow remote powershell. The policy works fine, I can remote powershell into any systems that have the gpo applied as long as I am in the domain where the systems are.
I then try to connect from my system in another domain and I get an error related to the IP address being used. I read that I had to set the trusted host config on my client, I did that and it still fails to connect. I am also trying to determine if I should be doing a "new-pssession" or "enter-pssession"?
Set-Item WSMan:\localhost\Client\TrustedHosts -Value *
The error I get is:
Enter-PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how toset TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
New-Session creates a persistent connection; Enter-PSSession can utilize that, or (if given a -computername), spins up and activates its own session. So the answer to that is, "either."
There are some specific steps for enabling access for administrators in other domains; read about_remote_troubleshooting for some tips.
You're also getting a good tip in the error message. You do have to use EITHER HTTPS or add the computer to TrustedHosts on your client computer (which it sounds like you've done). You ALSO have to use the -credential parameter with Invoke-Command, Enter-PSSession, or whatever. I'm not sure if you're aware of that - but the error message does state that.
And be aware that setting TrustedHosts to * is a good override of every security protection Microsoft provides. It's easy, but it does make it very easy for an attacker to spoof connections, grab your credentials, and do awful stuff. If you're just using * to test, okay, but be aware that it's not a very safe configuration.
This Message can mean many things. I suggest you create a new-pssessionoption object (http://msdn.microsoft.com/en-us/library/system.management.automation.remoting.pssessionoption_members(v=vs.85).aspx ) to skip all the Checks and use this with you new-pssession. Authentication Type Kerberos can be used if the Domains are trusted ... below some sample - this solves the problem with selfsigned certificate or without published or up-to-date crl-files which cause same error then shown by you.
$sessionopt= new-PSSessionOption -SkipCACheck:$true -SkipCNCheck:$true -SkipRevocationCheck:$true$session = New-PSSession -ConnectionURI $global:ConfigParam.rmsURL -Credential $global:Session.mycred -SessionOption $sessionopt -Authentication KerberosImport-PsSession $session
As a Last resort you might go with hvremote and following the 10 Secounds guide http://archive.msdn.microsoft.com/HVRemote to set Permission and FW Rules.
Thanks, so what is the best method of using Remote PS to get to this untrusted domain from my client?I know I need to specify the -credential, but also agree that adding in "*" to trusted hosts isn't the best idea either.
Put the specific host name, not *, into TrustedHosts. Configure the remote machine to have an HTTPS listener - the SSL certificate you'll install will make the mutual authentication happen.
I'm in the process of writing a complete step-by-step for this actually ;)