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, 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.

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