SCVMM-08 Configuring Distributed Key Management(DKM)

http://www.vkernel.ro/blog/configuring-distributed-key-management-dkm-in-vmm-2012
Configuring Distributed Key Management (DKM) in VMM 2012
Before we start digging into the practice stuff, I want to put some theory here so you can at least make an idea what Distributed Key Management or DKM is and why do you need to know how to configure it. VMM encrypts some of the data in the VMM database like the administrator passwords, Run As account credentials and product key information. In order for the VMM server to be able to access that information, its using decryption keys that are stored on the local server. Well…they where until server 2012, but now you can choose to store them in Active Directory Domain Services (AD DS). I know you are thinking that storing the decryption keys on the local VMM server is good or it was good enough for you. The problem arises when you need to move the VMM installation to another computer; the encrypted data will not be retained, because the encryption is tied to the specific computer on which VMM is installed. One other problem will pop-up when you try to cluster your VMM servers. If the decryption keys are stored locally and the node that encrypted the data (active node) fails, the other node(s) will not be able to decrypt the SQL information in the database since they don’t have the right decryption keys. This is why Microsoft made it possible to store the encryption keys in AD DS; a concept called Distributed Key Management or DKM.
DKM is configured during the installation of VMM, NOT after. When you get to the Configure service account and distributed key management page of the installation wizard you have the option to configure it by checking the box Store my keys in Active Directory and provide the path to the keys container. If the account you are logged in with has permissions to modify/edit the AD schema (not recommended) you can simply type the path to the keys container and hit Next.


To follow the installation best practice, log in with a domain user account that has administrative permissions only on the VMM server (svc_vmm in this example) and create the keys container manually in AD. For more information on rights requirements for VMM administrative tasks read this Microsoft article.
For the next part I’m presuming you have full access to a domain controller to edit the schema. If not you will have to ask an AD administrator to do this for you.
Open Active Directory Services Interfaces Editor (ADSI Edit) from the Administrative Tools menu, right-click the root object and choose Connect to.



Leave the defaults here and click OK.


Now we need to create a new container for the VMM encryption keys, so browse to the System container, right-click it and choose New > Object. This can be created on any level of the hierarchy, but I like to put this in the System container.


In the Create Object window select container and click Next.


Give it a name and continue. You can name this whatever you like, just don’t put spaces and special characters in it.






And the container is created, but we are not done yet. We need to set the proper permissions on this container in order for the VMM wizard to be able write in it. Right-click the container and choose Properties.

Go to the Security tab > Advanced > Add





click the Select a Principal link, then type the account that you are using to install VMM.

Click OK. Give it full control and make sure on the Applies to box the option This object and all descendant objects is selected; it is very important. Save the changes.


Back to our VMM installation wizard; provide the Distinguished Name (DN) for the VMM container then click Next to continue. In my case is:

CN=VMMDKM,CN=System,DC=vkernel,DC=local

After the installation, you can take a look at the container in ADSI Edit. You can see it was populated, which is good. It means it worked.


As you saw, configuring a DKM for VMM is not hard, actually is very easy, but this is a must if want to create highly available VMM servers.