26 January 2017
Our customer documentation is at:
The details there help with orientation, provisioning, and especially with the groups aspect of gMSAs since all of our AD group management is done via a Grouper-based Groups service. There are sections on a number
of the things you’ve asked.
The KDS root key was so long ago that my memory is thin, but yes, my recollection is that yes that is requirement to getting gMSAs going. Before we did that, no one could create them, including domain admins.
Under the covers, gMSAs are based on an object class which inherits from the computer object class (which in turn is based on the user class and so on). Since we’ve delegated computer objects to delegated OU
admins, we didn’t have a huge problem delegating management of them too—especially since from a samAccountName namespace collision aspect, we have policy/practices for computers and these could just re-use the same naming policy/practice. (And conveniently
since our grouper implementation already integrates with AD computer objects, all gMSAs were instantly possible group members)
In terms of delegation permissions, we gave permissions to create/delete the object class, but chose to not delegate gMSAs lesser cousin the MSA (msDS-ManagedServiceAccount). That’s because gMSA is superior in
every way to a MSA, and we didn’t want anyone using a MSA when they could use a gMSA instead.
One note about delegation on this object type which is worth thinking about are the domain-wide security implications like SPNs and even Kerberos delegation. In other words, once you delegate creation, they are
object owners/admins and have a wider degree of ability to set security related attribute values which can have domain-wide impacts such as those I’ve mentioned. We have mitigations in place to catch misuse, so weren’t overly concerned about this, but your
tolerance and/or mitigations might make this a potential issue.
In terms of customer recommendations, we encourage anyone who needs an application identity for use with our AD to use a gMSA because it has stronger security characteristics than any of our centrally provisioned/managed
identities. Most customers aren’t eager to try a gMSA. That said, we currently have 78 provisioned. Compared to an overall user population of about 800,000, that’s extremely small, but I see it as a win every time a customer chooses this over an identity that
some human holds and sets a password on.