VMM 2012 Distributed Key Management (DKM)

Virtual Machine Manager 2012 (VMM/SCVMM) 2012 adds something that was lacking in VMM 2007/2008/20008 R2: clustered VMM servers.  VMM 2012 is the gateway to the private cloud and you want that gateway to be fault tolerant at the hardware, OS, and service level.  If you want to have a clustered VMM server then you will need to get to grips with some new concepts.

The VMM database contains a lot of information.  Some of that information can be sensitive, such as product keys or administrator passwords.  You don’t want just anyone getting a copy of that database (from offsite stored backup tapes, for example [which should be encrypted anyway]) and figuring out a way into gaining administrative rights to your network.  For this reason, VMM uses encryption to protect the contents of this database. 

By default the decryption keys for accessing the encrypted data are stored on the VMM server.  Now imagine you have set up a clustered VMM server and those keys are stored locally, as seen below.

The first node with the local keys would encrypt the SQL data and access it with no issue at all.  But what would happen after a failover of the VMM service from Node 1 to Node 2?  The decryption keys are unavailable, on Node 1, and Node 2 has no way to read the encrypted data in clear text.  There goes the uptime of your cloud!

That’s why we have a new concept called Distributed Key Management (DKM) in VMM 2012.  Instead of storing the decryption keys on the server, they’re stored in a specially created container in Active Directory.  This means that the decryption keys can be accessed by both of the VMM cluster nodes, and either node can read the encrypted data in clear text.

You can configure the option to enable DKM when you install the first member of the VMM cluster.  You can optionally do this even if you’re setting up a non-clustered VMM server.  It’ll mean the keys are safe in AD, and it gives you the flexibility to easily set up a cluster without too much mucking around.

When you enable the option to use DKM, you have two choices:

• Installing as a Domain Administrator: You can enter the LDAP path (e.g. CN = VMMDKM, CN = System, DN = demo, DN = local) and the installer will use your rights to create the VMM container inside of the default System container.
• Not Installing as a Domain Administrator: You can get a domain admin to create the container for you, ensuring that your new user account will have Read, Write, and Create all child objects permissions.  You can enter the LDAP path (as above) that is provided by the domain administrator.

I like SystemVMMDKM for two reasons:

1. ConfigMgr uses SystemSystemsManagement for its advanced client objects
2. VMMDKM is quite descriptive. 

Now Node 1 of the VMM server cluster will use the DKM/AD-stored decryption keys and access the secured data in the SQL Server instead of storing them locally.

After a failover, Node 2 can also read those DKM/AD-stored decryption keys to access the encrypted data successfully:

Decryption keys; I bet your security officer is concerned about that!  I haven’t mentioned the protection of these keys yet.  Note how we didn’t do anything to lock down that container?  Normally, Authenticated Users will have read permissions.  We sure don’t want them to read those decryption keys!  Don’t worry, the VMM group has you covered.

In the new container, you will find an object called DC Manager <unique GUID>.  This is a container that DKM has created and contains the protected keys for the VMM server/cluster you just set up.

It is protected using traditional AD permissions.  VMM is granted rights based on what account is running VMM.  I prefer to install VMM using a domain user account, e.g. demoVMMSvc.  That account was granted full control over the container object and all descendent (contained) objects:

Note that Authenticated Users is not present.  In fact what you will find is:

• Self: Inherited with apparently no rights
• System: Full Control on the container object only
• Enterprise Domain Controllers: Read tokenGroups (Descendent User Objects), Read tokenGroups (Descendent Group Objects), Read tokenGroups (Descendent Computer Objects)
• Enterprise Admins: Full Control on this and descendent objects
• Domain Admins: Full Control on this and descendent objects
• Administrators: It’s long but basically it’s not Full Control and no delete rights on this and descendent objects
• Administrator: Full Control on this and descendent objects

In other words, VMM 2012 DKM is a pretty sure way to:

• Enable a SQL database to securely store sensitive data for a highly available VMM cluster running across multiple servers
• Allow those nodes of a highly available VMM cluster to share a single set of decryption keys to access the encrypted data in the SQL database

Now you have some very special data in your AD – like you didn’t already!  But if you’re “just” a virtualisation administrator/engineer or a consultant, you better make sure that someone is backing up AD.  Lose your AD (those DKM keys), and you lose that sensitive data in the SQL database.  While you’re verifying the existence of a working AD backup (System State Backup of a few DCs, maybe), make sure that the backup is secure in terms of access rights to data and encryption.  You’ve got sensitive encryption keys in there after all.