gMSA adoption and use-cases

  • Last Post 31 January 2017
eccoleman posted this 26 January 2017

Hello,   I’m curious how widely-adopted the use of group-managed Service Accounts (gMSA) has been. I’m particularly looking for higher-ed institution examples.  What sort of business cases drove you to using gMSAs? And how have you delegated the control and ownership of those account objects to multiple units/separate OU delegation? Did you have to create a new KDS Root Key?  Any situations where you thought this would work and the service didn’t support gMSAs?   We’re only looking at this at a high-level so far to see if it could partially address the boundless growth of ‘unmanaged’ domain-based service accounts being shared or used in more than one place.   Thanks for any insight!


Erik Coleman Senior Manager, Enterprise Systems Technology Services at Illinois University of Illinois at Urbana-Champaign    

Order By: Standard | Newest | Votes
barkills posted this 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.





froosh posted this 27 January 2017

[Not directly related to gMSA adoption] I use “OWNER RIGHTS” ( to limit the rights a delegate receives on objects they create. Requires all DCs to be running 2008 or newer, or the rights are ignored. Set an inherited generic owner rights ACL high in your OU hierarchy (e.g. maybe just Read Permissions [RC]) and only permissions created through delegation will every apply to lower objects. Regards, Robin Frousheger | Technical LeadMicrosoft Systems | University ServicesThe University of Melbourne 


SmitaCarneiro posted this 27 January 2017

We’re encouraging folks to use in in our new domain that we’ve just started migrating to. The carrot is ‘you don’t have to change its password or file for a security exemption’. So far the IAMO has used it and

now a college is using it with SQL 2016 for SCCM. We create the gMSAs for others when requested.

We have way too many service accounts in the old domain and this is one way of trying to cut down on that number in the new environment.


Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

Ross Enterprise Center

3495 Kent Avenue, Suite 100

West Lafayette, IN 47906



a-ko posted this 27 January 2017

Biggest challenge for gMSAs is that they’re limited to Windows service usage, and not so great for situations where you’ve got applications that need embedded credentials (i.e.

a web app that performs LDAP queries).


This tends to be the biggest con to a gMSA. It also doesn’t work for any accounts you’ve created for services for keytab files (for Kerberos integration). You can generally count

any *nix-based application to just simply not like it.


Effectively, anywhere you’d have an option to modify the Windows Service account, you’d want to use a gMSA. Otherwise, you’re stuck using regular accounts.



daemonr00t posted this 27 January 2017

Yup, they were created to run as services only.

Even if you get to find its password they don’t support explicit logons.


~danny CS

Sent from Mail for Windows 10



barkills posted this 27 January 2017

Uh … that’s not quite true.


You can also use gMSAs with scheduled tasks. And in fact, in the majority of cases I use gMSAs, that’s the scenario. That scenario is spelled out in the documentation I shared previously.





daemonr00t posted this 27 January 2017

You are right Brian.

I was forgetting that. You can also use them for IIS pools too.

Happy weekend to everyone.


~danny CS

Sent from Mail for Windows 10



Bharathian posted this 30 January 2017

I feel the security boundary for GMSA is the computer object. Anyone have access to the server can utilize the GMSA. It would have been better to isolate the access process wise.






Icolan posted this 31 January 2017

Has anyone found a way around the requirement to have the PowerShell ActiveDirectory component installed on every machine you want to use a gMSA on?  According to the documentation you have to run Install-ADServiceAccount to cache the password on the machine, but that cmdlet is only installed if you install the RSAT PowerShell ActiveDirectory module.  We don't have that installed by default on most of our servers and the version in 2012 at least will only run locally.