When working with PowerShell remoting, when you establish a session from your computer to a remote computer, all of the underlying bits are most likely going to rely on Kerberos authentication. If both ends belong to a trusted Active Directory domain, and assuming no issues with Kerberos, everything works just fine. But sometimes Kerberos isn't an option, nor even some of the other alternatives for PowerShell remoting.

For example, you may want to connect from a non-domain member to a domain member. Suppose from my workgroup machine I want to check the ARP cache on a domain member using Invoke-Command; as Figure 1 shows, this will fail.

 

This is because my computer has no way of trusting or authenticating the remote computer. But I can take matters into my own hands and configure PowerShell remoting on my end to trust that computer, or any others for that matter.

PowerShell uses the WSMAN protocols for remoting and there is a provision for something called TrustedHosts. These are computers that I explicitly will trust. In an evelated session I can see my current configuration using Get-Item.

PS S:\> get-item WSMan:\localhost\Client\TrustedHosts | Select Name,Value

Name                                    Value
----                                    -----
TrustedHosts

To add a computer, I'll modify this setting, again in an elevated PowerShell session.

PS S:\> set-item WSMan:\localhost\Client\TrustedHosts -value *.globomantics.local

Figure 2 illustrates the process.

 

I will now trust any computer in the Globomantics.local domain. Now I'll try my remoting command again, and this time it should work. By the way, I'm specifying a credential because obviously my workgroup credential is meaningless in the domain. The results are in Figure 3.

 

One thing I want to point out: the TrustedHosts list is very specific.

PS S:\> get-item WSMan:\localhost\Client\TrustedHosts | Select Name,Value

Name                                    Value
----                                    -----
TrustedHosts                            *.globomantics.local

What happens if I try a command like this:

PS S:\> invoke-command {ipconfig} –comp chi-win7-22 –cred Globomantics\administrator

As you can see in Figure 4 this fails.

 

One way around this would be to add the name to TrustedHosts.

PS S:\> set-item WSMan:\localhost\Client\TrustedHosts -value "chi-win7-22,*.globomantics.local"

Now this works.

 

If I wanted to come from a domain machine to a workgroup machine, I can use the same technique. On the domain machine I would add the workgroup machine name as a TrustedHost. If you need to do this for a number of domain members, this can also be set through Group Policy.

Naturally, you are taking authentication and security into your own hands with TrustedHosts. You're basically telling PowerShell, "Don't worry, I got this." Still, when Kerberos isn't an option, this is a very useful feature.

To learn more about troubleshooting Kerberos-related problems I hope you'll take a few minutes to read my accompanying article, Taming the Three-Headed Beast: Kerberos.