problems.
Configuring Constrained Delegation
Performing a Live Migration within a cluster removed the need for any special
security considerations when moving virtual machines, because the cluster account
was used throughout migration operations. However, Shared Nothing Live Migration,
Live Migration using SMB, and the ability to move storage to SMB shares introduce
some additional security (specifically, credential) considerations.
Outside of a cluster, each Hyper-V host has its own computer account without a
shared credential, and when operations are performed, the user account of the user
performing the action is normally used. With a Live Migration, actions are being taken
on the source and target Hyper-V servers (and file servers if the VM is stored on an
SMB share, but more on that later), which both require that the actions be
authenticated. If the administrator performing the Live Migration is logged on to the
source or the target Hyper-V server and initiates Shared Nothing Live Migration using
the local Hyper-V Manager, then the administrator’s credentials can be used both
locally and to run commands on the other Hyper-V server. In this scenario, CredSSP
works fine and allows the user’s credentials to be used on the remote server from the
client—basically, a single authentication hop from the local machine of the user
performing the action (which happens to be one of the Hyper-V servers) to a remote
server.
Remember, however, the whole goal for Windows Server 2012 (and above) and
management in general: remote management and automation. Having to log on to the
source or target Hyper-V server every time a Live Migration outside of a cluster is
required is a huge inconvenience for remote management. If a user was logged on to
their local computer running Hyper-V Manager and tried to initiate a Live Migration
between Hyper-V host A and B, it would fail. The user’s credential would be used on
Hyper-V host A (which is one hop from the client machine to Hyper-V host A), but
Hyper-V host A would not be able to use that credential on host B to complete the Live
Migration, because CredSSP does not allow a credential to be passed on to another
system (more than one hop).
This is where the option to use Kerberos enables full remote management. Kerberos
supports constrained delegation of authentication: When a user on their local
machine performs an action on a remote server, that remote server can use that user’s
credentials for authentication on another remote server. This initially seems to be a
troubling concept, that a server I remotely connect to can just take my credentials and
use them on another server, potentially without my knowing. The constrained part of
constrained delegation comes into play and requires some setup before Kerberos can
be used as the authentication protocol for Live Migration. To avoid exactly the
problem I just described, where a server could use a remote user’s credentials on
another server, delegation has to be configured for each computer account that is
allowed to perform actions on another server on behalf of another user. This