Managing Hyper-V can be done in several ways; using Hyper-V Manager, using System Center Virtual Machine Manager and, of course, using PowerShell. As a best practice in any management scenario, you manage a service from a remote machine. Whether this is a workstation running Windows 8 or a Remote Desktop Services server running Windows Server 2012 does not really matter, at least not from a technical perspective. I always suggest performing management from a central ‘management server’ where all management tools are installed and maintained. The whole idea being that you don’t want people logging in interactively on servers just for service management.
Managing Hyper-V in a remote scenario differs from the local scenario. In a local scenario you are logged on with your credentials and any operations are being run using your credentials. As long as your privileges are sufficient, you can perform any operation you wish. The situation changes in a remote scenario. Any operations you perform on the Hyper-V host itself will work. But operations that involve other Hyper-V hosts (or any remote host) fail if you have not made the proper arrangements.
For example, when you create a virtual machine (New-VM), your credentials are being used on the Hyper-V host. But when you move a virtual machine (Move-VM) the operation involves another Hyper-V host. Let’s call the host where you want to move the VM off the source host, the host where you want to move the VM to the destination host. The source host will use your credentials to move the virtual machine to the other host and this will fail because the source host is not allowed to use your credentials. It simply lacks the right to delegate your credentials. This is where Kerberos Constrained Delegation, also known as KCD, will help you out.
A little background on Kerberos delegation.
Ever since Windows 2000 we support the concept of delegation. A client might need to let an application or a service connect to other servers or services on its behalf. A client might use a front-end server, for example, that then needs to authenticate with a back-end server. The front-end server needs to authenticate to the back-end server with the client's credentials, because if it authenticated under its own service account, it would have different authorization than the user.
The Kerberos protocol includes a mechanism called delegation of authentication. When this mechanism is used, the client (the requesting service) delegates authentication to a second service by informing the KDC that the second service is authorized to act on behalf of a specified Kerberos security principal, such as a user that has an Active Directory directory service account. The second service can then delegate authentication to a third service.
In the Windows 2000 delegation model, the KDC does not limit the scope of services that a Kerberos principal's identity can be delegated to. That is, after a service account is trusted for delegation, it can request service tickets on behalf of a given user to any other service accounts. With constrained delegation, on the other hand, domain administrators can configure service accounts to only delegate to specific sets of service accounts. In Windows Server 2003 and higher, the ms-DS-Allowed-To-Delegate-To attribute is added to service accounts to help enforce constrained delegation. The ms-DS-Allowed-To-Delegate-To attribute lists the service principal names (SPNs) of other service accounts that a given service account is allowed to delegate to. When a Windows Server KDC processes a service ticket request via the constrained delegation extension, it will verify that the target service account is one that is listed in the ms-DS-Allowed-To-Delegate-To attribute.
Now that you know the technical explanation of Kerberos Constrained Delegation, I will go into the practical use and configuration in the scenario of remotely managing Hyper-V. For easy understanding I will use the setup of my own demo environment. In this environment there are two Hyper-V Server 2012 hosts and one Windows Server 2012 host. This is a rather simple environment in which the Hyper-V hosts simply run my virtual machines and the Windows Server 2012 host is being used as a file server to store virtual machine (configuration, virtual disks, smart paging and snapshots) and ISO files.
Let’s assume that this environment is pristine from a fresh installation of the hosts and the domain, so nothing has been modified for any specific purpose other than being able to logon with a domain account. In this scenario I am logged on using the domain administrator account. The three physical hosts have been joined to the domain and I have a ‘management server’ running Windows Server 2012 in a virtual machine. The diagram below is the logical representation of the hosts and servers.
Vmhost1 and vmhost2 are the Hyper-V hosts, fhost1 is the file server, mgmt1 is the ‘management server’ and contoso1 the Active Directory domain controller. Except for the Hyper-V hosts, all others run Windows Server 2012.
From mgmt1, I run the Hyper-V management tools being Hyper-V Manager and the Hyper-V PowerShell cmdlets. Obviously, I also run Server Manager and any role and feature tools for File and Storage Services, Active Directory and DNS from mgmt1.
Configuring Hyper-V from mgmt1 I don’t run into any issues. I am remotely managing Hyper-V using my domain credentials. As long as my management operations stay ‘inside’ vmhost1 then there are no authentication issues. But when the operation involves for example vmhost2, authentication fails and messages like ‘general access denied’ and ‘no credentials are available in the security package’ occur. Despite the fact that I am logged on as a domain administrator on mgmt1, I cannot perform any actions that involve vmhost2 when managing vmhost1. As you now know, KCD has not been configured yet.
For this to succeed, KCD has to be configured on vmhost1. To be more precise, vmhost1 needs to be trusted for delegation to specific services on vmhost2. These services are:
CIFS (Common Internet File System) is the updated name for SMB (Server Message Block). SMB is necessary for vmhost1 to access vmhost2 and create files/folders. The Microsoft Virtual System Migration Service is the migration capability of the Virtual Machine Management Service. This service performs operations like virtual machine migration and virtual machine replication. Once I have configured delegation for these services to vmhost2, I can perform management operations that involve vmhost2.
Suppose I want to store the virtual machine data on the file server fhost1. I would then need to configure vmhost1 to be able to delegate CIFS to fhost1. But if I want to move a virtual machine with storage on fhost1, I must configure delegation on vmhost2 as well, because vmhost2 needs access to the virtual machine data as well. I also want to use ISO images stored on the fhost1 file server from within my virtual machines. With delegation configured for the CIFS service type to fhost1 on both vmhost1 and vmhost2, I can use SMB shared storage on both Hyper-V hosts and use ISO images stored on fhost1.
You can configure delegation from the GUI tool Active Directory Users and Computers. This is what it looks like for VMhost1:
Notice that I have checked the ‘Expanded’ view which then shows both single label and FQDN host entries.
Obviously you can configure this from PowerShell too by using the Set-ADObject cmdlet. You will need to supply the distinguished name of the host and provide the hash table entries for the attribute msDS-AllowedToDelegateTo.
Below is a script I use to configure KCD on my Hyper-V hosts. It is nothing fancy or advanced, it is just easy to use since I don’t have to remember the attribute name and construct the hash table. The script offers an Add, Replace and Remove switch.
You can verify you delegation using Get-AdObject. For example:
Get-AdObject "cn=vmhost1,cn=computers,dc=contoso,dc=com" -Properties msDS-AllowedToDelegateTo
This will then show:
Detailed Kerberos protocol explanation can be found here.
Update 2012-09-25I have updated the Set-KCD.ps1 script. It can be downloaded here.
Great article. Thanks for sharing
Is mgmt1 in the domain? What happens if it is not a domain machine?
For example mgmt1 is not domain machine , run migration via WEB Scripting Locator from any language such as java, python and powershell scripts.
If I am in a "Proof of concept" scenario, and don't care about applying contraints to the list of services that the host can present delegated credentials to, could I just set
"Trust this computer for delegation to any service (Kerberos Only)"?
Unfortunately you really must set each and every service else it just doesn't work. I tested the "Trust this computer for delegation to any service (Kerberos Only)" as Matt Dendle mentioned, but whilst that works for well known services like CIFS (e.g.
browsing/accessing files across Hyper-V machines) it failed to authenticate for the Live Migration service (and probably the other services like replication then). Only when I manually added entries for each source/target server (both HOST and FQDN) and each
service I wanted to use (cifs, "Hyper-V Replica Service", "Microsoft Virtual Console Service", "Microsoft Virtual System Migration Service") then it worked.
I have been struggeling with this almost an entire day.Turns out that you can't have your Hyper-V server using a 2003 domain controller as logonserver (the domain functional level can be 2003, but when your Hyper-V server is logging on to a 2003 DC, you get the same error as if you haden't configured KCD at all)
I'm trying to setup this config in a cross-forest situation. However I can not configure Delegation for computer accounts in another domain. Does KDC powershell solve this?
seams to be hit or miss migrating from management/admin PC's but if I logged into the actual server hosting the guest VM and did the migration the credentials error went away and the machine migrated.
I allowed delegation from Kerberos for all services and still no change.