Live migration is one of the most widely used features in Hyper-V, and while it is relatively easy to use, you...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
will first have to decide which authentication protocol you prefer.
Microsoft gives you two choices: CredSSP or Kerberos authentication. The problem is that the Hyper-V Manager doesn't give you much guidance as to which protocol is best.
The default option is Credential Security Support Provider (CredSSP), but the interface states that Kerberos authentication is more secure. However, Kerberos requires constrained delegation for Live Migration. So which protocol should you use?
Choosing a protocol
The reason CredSSP is the default authentication protocol in Windows Server 2012 and Windows Server 2012 R2 Hyper-V is because CredSSP can be used without any further configuration (beyond choosing a migration network). In other words, CredSSP is the default choice because it is easy to use.
However, CredSSP might not always be the best option. The Hyper-V Manager specifically states that Kerberos is more secure than CredSSP, but there is more to it than that. The biggest problem with using CredSSP is that the CredSSP protocol only allows credentials to be passed across a single hop. This means that if you want to perform a live migration then you will have to log in to the host server where the VM currently resides and launch the live migration from there. This might not be a big deal in small and medium-sized businesses, but it presents a major obstacle in large environments.
Kerberos authentication is not subject to the single hop limitation, but it requires the use of constrained delegation. When an administrator initiates a live migration, Hyper-V uses that administrator's credentials. CredSSP has a single hop limitation, meaning it is able to pass the administrator's credentials to a remote system, but the credentials cannot be passed any further. Kerberos does not have this limitation, meaning the administrator's credentials can be passed across multiple servers if necessary.
However, the ability to pass credentials across multiple servers could be a security risk. You don't want a remote server using your administrative credentials in any way that it sees fit. So, if you prefer to use the Kerberos protocol, be sure you also enable constrained delegation. Constrained delegation lets you limit what the account credentials can be used for.
Enabling constrained delegation
You must configure the actual delegation process through either the Active Directory Users and Computers console, or through PowerShell. To configure the delegation process through the Active Directory Users and Computers console, open the console and select the Computers container. Next, right-click on the server for which you wish to configure constrained delegation and select the Properties command from the resulting shortcut menu.
When the computer's properties sheet appears, select the Delegation tab, as shown in Figure B. Select the Trust This Computer for Delegation to Specified Services Only option. Make sure that the Use Kerberos Only option is selected, and then click the Add button.
When the Add Services dialog box appears, click the Users or Computers option and then enter the name of the computer account for which you want to enable delegation. When you do, you will see the Add Services dialog box shown in Figure C. You will need to select the Microsoft Virtual System Migration Service. You will typically also need to add delegation for the Common Internet File System (CIFS) service.
As you can see, using CredSSP authentication is the easiest option, but it requires you to log in locally to the Hyper-V host running the virtual machine that you want to live migrate. Kerberos offers better flexibility, but the use of constrained delegation is essential.
Dig Deeper on Server virtualization risks and monitoring