In a previous article on Constrained Delegation, we looked the need to allow Hyper-V hosts to perform impersonation/delegation on behalf of your virtualisation administrators or other Hyper-V hosts for certain SMB 3.0 storage operations.
Per-user Active Directory controls exist to prevent certain accounts from being impersonated even in cases where constrained delegation may be allowed.
The Account is sensitive and cannot be delegatedattribute for each user account in Active Directory can prevent it from being used for delegation. Consider the following:
- Hyper-V host hyperv01.vmlevel.com is configured for constrained delegation for the SMB service on a Tintri VMstore, vmstore01.vmlevel.com. The Service Principal Name configured for delegation is cifs/vmstore01-data.vmlevel.com.
- Alice does not have the Account is sensitive and cannot be delegated checkbox checked on her account in Active Directory.
- Bob does have the Account is sensitive and cannot be delegated checkbox checked against his account in Active Directory.
In this case, if Bob attempts to use Hyper-V Manager on his desktop to create a VM running on the Hyper-V host above, but stored on the Tintri VMstore, he’ll see an error message from the Hyper-V host telling him that access has been denied.
If Alice tries the same thing, she’ll be able to create and administer VMs.
Tintri doesn’t have any explicit best practices around which accounts to set or clear this flag for — it’s up to the business. However, many operations require the use of delegation. If you find that some users are able to perform VM administration tasks, but others cannot, it’s worth checking the state of this user account flag in Active Directory.