Using Constrained Delega to remotely manage a server running Hyper-V that uses CIFS/SMB file share

[LEFT][CODE]http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx[/CODE]

P.S.: After writing this blog post, I found that the specific scenario of using Hyper-V VHDs files on a file share is not supported by Microsoft in Windows Server 2008. This is documented at [url=http://technet.microsoft.com/en-us/library/dd183729.aspx]Planning for Disks and Storage[/url]. Look for a note that says "Network-attached storage (NAS) is not supported for Hyper-V".
As explained in my previous blog post at [url=http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx]Jose Barreto's Blog : Storing Windows Server 2008 Hyper-V files on a CIFS/SMB file share[/url], you can store your Windows Server 2008 Hyper-V files in a CIFS/SMB file share. This additional storage option can be used for the VM configuration, VHDs, snapshots and ISOs. That post explains the required permissions, describes in detail how to do it and also offers some performance tips.
In specific cases, however, additional configuration (beyond what is described in that first post) is required. That happens when you need to manage the server running Hyper-V remotely. You see, in that case, your remote management client typically does not have the permission to talk to the file server on behalf of the server running hyper-V. Let me try to use a little diagram to clarify the scenario:
[IMG]http://blogs.technet.com/photos/josebda/images/3079772/original.aspx[/IMG]
As described in the diagram, I'm running the Hyper-V Manager on SPTCLIENT1 (which can be runnung Windows Vista SP1 or Windows Server 2008) to configure the VMs on SPTNODE1 (running Windows Server 2008 x64) storing the files in a share on the file server STPSERVER1 (running Windows Server 2008 to benefit from the improvements in SMBv2 and in the TCP/IP stack).
If you try to create a new VM stored in the file share in that scenario, you get an error message saying that your access is denied, even though the file share is properly configured with permission to the Hyper-V computer and the user. The exact message is “The operation failed. Failed to create external configuration store at ‘\\SERVER\SHARE\FOLDER’: General access denied error (0x80070005). User ‘DOMAIN\USER’ failed to create external configuration store at ‘\\SERVER\SHARE\FOLDER’: General access denied error (0x80070005).” Here’s a screenshot:
[IMG]http://blogs.technet.com/photos/josebda/images/3079773/original.aspx[/IMG]
To work around this problem, you have two choices. An easy option is to connect directly to the server running Hyper-V (using a Remote Desktop Connection) and run the Hyper-V Manager directly there. This is usually fine, unless you’re running a core install of Windows Server 2008. Since there is no MMC in a Core install, you can’t run the Hyper-V Manager directly on the server, even though you can RDP to it. As you can probably guess from the diagram, my end goal is to create a two-node cluster and I would like to keep the parent partition as light as possible. Although a Core install is not required by Hyper-V, it is always highly recommended.
Fortunately there is second choice to address the issue: Constrained Delegation. By configuring the computer account of the server running Hyper-V in Active Directory, you can authorize the impersonation required by this scenario. You can start by running the “Active Directory Users and Computers” MMC on your domain controller. Right-click the computer account of the server running Hyper-V and select “Properties”.
[IMG]http://blogs.technet.com/photos/josebda/images/3079774/original.aspx[/IMG]
Next, go to the “Delegation” tab to confirm that this computer is not trusted for delegation (the default).
[IMG]http://blogs.technet.com/photos/josebda/images/3079775/original.aspx[/IMG]
You need to configure delegation, but you shouldn’t authorize it to all computers or for all kinds of services. The best practice from a security standpoint is to authorize exactly what you need and nothing else. To do that, select “Trust this computer for delegation to specified services only”, select “Use any authentication protocol” and click on the “Add…” button.
[IMG]http://blogs.technet.com/photos/josebda/images/3079776/original.aspx[/IMG]
In the dialog to select the account, enter the name of the file servers. After you select the server, you will see the screen below, showing all services available. In this case we’re delegating the CIFS protocol (also known as SMB). You don’t need to select any other services in this case.
[IMG]http://blogs.technet.com/photos/josebda/images/3079777/original.aspx[/IMG]
Here’s the screen with the final configuration.
[IMG]http://blogs.technet.com/photos/josebda/images/3079778/original.aspx[/IMG]
We can now remotely connect to SPTNODE1 and reuse the credentials when connecting to SPTSERVER1 to access CIFS/SMB services. When I retry that operation from SPTCLIENT1, as expected, it works just fine…
[IMG]http://blogs.technet.com/photos/josebda/images/3079779/original.aspx[/IMG]
In my case, I also had to apply the same configuration to the computer account of the other cluster node: SPTNODE2.
I hope this clarifies all the details on how to configure Constrained Delegation to remotely manage a Hyper-V server that uses CIFS/SMB file shares. Keep in mind that the restriction to impersonate a user stems from a security concern that needs to be properly addressed by granularly granting only the minimum required permissions. Resist the temptation of delegating all services to all computers, without constraints.
Now I’m on to my configuration of a Hyper-V Failover Cluster using only a file server share for storage. But that’s a topic for another blog post…




[/LEFT]