Hosts outside your domain – Hyper-V with CredSSP
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.
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.
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
Enable-WSManCredSSP -Role server
These first command will enable remote management and Enable-WSManCredSSP will enable CredSSP authentication.
On the management device
- 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.
- Configure local group policy:
- Computer Configuration > Administrative Templates > System > Credentials Delegation > Allow delegating fresh credentials with NTLM-only server authentication
- Click Enable and add wsman/fqdn-of-hyper-v-host. to the
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "fqdn-of-host"
Enable-WSManCredSSP -Role client -DelegateComputer "fqdn-of-host"
- 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.