Hosts outside your domain – Hyper-V with CredSSP

Manage a Windows remote host outside your domain, or in a workgroup

Connecting to and managing hosts outside your domain, or in a Workgroup

Your management devices and hosts will often be members of the same domain.  Kerberos handles authentication in this scenario, typically without the need for additional configuration.  When a host is outside of your domain (either on another non-trusted domain, or isolated in a Workgroup), Kerberos cannot be utilized.  Instead you’ll need to connect to Hyper-V with CredSSP.

The following error will be encountered when engaging hosts outside of your domain:

Under the hood the Hyper-V manager and other RSAT tools leverage WinRM/PSRemoting to establish a connection and perform actions. By default WinRM wants to leverage Kerberos, and it is unable to do so. We can confirm this by trying to establish a basic PSSession:

PS C:\>Enter-PSSession HYPV0
Enter-PSSession : Connecting to remote server HYPV0 failed with the following error message : WinRM cannot process the
request. The following error occurred while using Kerberos authentication: Cannot find the computer HYPV0. Verify that
the computer exists on the network and that the name provided is spelled correctly. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession HYPV0
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (HYPV0:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Note that we get a very similar error, with Kerberos failing to authenticate. Windows Remote Management defaults to Kerberos and a fallback to CredSSP won’t work without additional configuration.

Video Walk-through

If you prefer video format over written documentation I demo how to configure your host and management device to use CredSSP:

Managing Hyper-V with CredSSP

To enable authentication via CredSSP you will need to make configuration changes to both the host to be managed, and your management device.

On the host

  1. Enable-PSRemoting
  2. Enable-WSManCredSSP -Role server

These first command will enable remote management and Enable-WSManCredSSP will enable CredSSP authentication.

On the management device

  1. Ensure you are able to resolve the hostname – adjust the host file on your management device if you are unable to ping the hostname of the host you will be managing
    • PS C:\>ping HYPV0
      Ping request could not find host HYPV0. Please check the name and try again.
  2. Configure local group policy:
    1. Computer Configuration > Administrative Templates > System > Credentials Delegation > Allow delegating fresh credentials with NTLM-only server authentication
    2. Click Enable and add wsman/fqdn-of-hyper-v-host. to the
  3. Set-Item WSMan:\localhost\Client\TrustedHosts -Value "fqdn-of-host"
  4. Enable-WSManCredSSP -Role client -DelegateComputer "fqdn-of-host"
  5. Connect to host you wish to manage

A few thoughts on using CredSSP

When management devices and hosts are part of the same domain, you typically authenticate to them using a network logon (Kerberos). A network login proves to the remote server that you have valid credentials, without actually sending those credentials to the remote server. This is a good thing.

With CredSSP you send the credentials directly to the remote server you are managing, which will maintain the user’s credentials. Should the remote server become compromised, the passed credentials could be as well. Consequently, this is why you have to explicitly add remote servers to manage to your TrustedHosts group as indicated above.

You should be aware of this limitation when leveraging this in production and pass credentials via CredSSP only to highly trusted servers. Joe Biaelek covers some CredSSP limitations in his great write-up Accidental Sabotage: Beware of CredSSP

Finally, when managing Hyper-V with CredSSP (or other windows hosts), the risk factor is relatively low.  (You maintain the same level of risk establishing a RDP session to a server, for example).  Just be aware of the limitations of CredSSP and make sure it makes sense for your production use cases.

Be the first to comment

Leave a Reply

Your email address will not be published.


*