Step-by-Step: How to work with Group Managed Service Accounts (gMSA)

Published Sep 25 2019 09:01 PM 54.1K Views
Senior Member

Services Accounts are recommended to use when install application or services in infrastructure. It is dedicated account with specific privileges which use to run services, batch jobs, management tasks. In most of the infrastructures, service accounts are typical user accounts with “Password never expire” option. Since these service accounts are not been use regularly, Administrators have to keep track of these accounts and their credentials. I have seen in many occasions where engineers face in to issues due to outdated or misplace service account credential details. Pain of it is, if you reset the password of service accounts, you will need to update services, databases, application settings to get application or services up and running again. Apart from it Engineers also have to manage service principle names (SPN) which helps to identify service instance uniquely.


After considering all these challenges Microsoft has introduced Managed Service Accounts with windows server 2008 R2. However, one managed service accounts only can use with one computer. But there are operation requirements which required to share same service account in multiple hosts. Microsoft network load balancer, IIS server farms are good example for these. All the hosts in these server groups required to use same service principal for authentications. Group Managed service accounts provides the same functionalities as managed service accounts but its extend its capabilities to host group levels. This is first introduced with windows server 2012.


Group managed service accounts got following capabilities,

  • No Password Management
  • Supports to share across multiple hosts
  • Can use to run schedule tasks (Managed service accounts do not support to run schedule tasks)
  • It is uses Microsoft Key Distribution Service (KDC) to create and manage the passwords for the gMSA.

Key Distribution Service was introduced with the windows server 2012. KDS shares a secret (root Key ID) among all the KDS instance in the domain. This value will change periodically. When gMSA required a password, windows server 2012 domain controller will be generated password based on common algorithm which includes root key ID. Then all the hosts which shares the gMSA will query from domain controllers to retrieve the latest password.


Requirements for gMSA

  • Windows server 2012 or higher forest level
  • Widows server 2012 or higher domain member servers (Windows 8 or upper domain joined computers also supported)
  • 64-bit architecture to run PowerShell command to manage gMSA

Tip – gMSA not supported for the Failover Clustering setup. But it is supported for services which is run upon Failover clusters.


In order to start the configuration process, we need to create KDS root key. This need to run from domain controller with domain admin or enterprise admin privileges.


Add-KdsRootKey –EffectiveImmediately


Once this is executed, it has default 10 hours’ time limit to replicate it to all the domain controllers and start response to gMSA requests. In testing environment with one domain controller, it can force to remove this waiting time and start to response gMSA immediately. This is NOT recommended for production environment.


Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))


After that we can create the first gMSA account. First I have created an AD group “IISFARM” and add all my IIS servers to it. This farm will be using the new gMSA account.


New-ADServiceAccount "Mygmsa1" -DNSHostName "" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"


In above Mygmsa1 is the service account and is the FQDN of the service. Once its processed we can verify the new account using,


Get-ADServiceAccount “Mygmsa1”




Next step is to install it on server in IIS Farm. It needs active directory PowerShell module to run it. It can be install using RSAT.


Install-ADServiceAccount -Identity "Mygmsa1"


Tip – If you created the server group recently and add the host, you need to restart the host computer to reflect the group membership. Otherwise above command will fail.

Once its executed we can test the service account by running,


Test-ADServiceAccount " Mygmsa1"




Similar to managed service account, when you configure the gMSA with any service, leave the password as blank.


Uninstall Service Account


There can be requirements to remove the managed service accounts. This can be done by executing,


Remove-ADServiceAccount –identity “Mygmsa1”


Above command will remove the service account Mygmsa1. This is applying to both type of managed service accounts.


Do you need to assign permissions (through groups and file security)  to the gmsas?  I am looking particularly at SQL.

Senior Member

Thanks you Soo much sir it very useful for me. 


Thanks for the Details, however i'm looking for a solution / alternative to configure DB mail when SQL Server running on gMSA account.


Thanks in Advance

Occasional Visitor

"Windows server 2012 or higher forest level" is ambiguous as a requirement. Does this meean Forest Functional level or does it mean that all DCs in a forest need to be on 2012 or later? Also is this a Domain thing or a Forest thing?
You also fail to mention whether the KDS Root Key requirement is Domain or Forest level thing.

Frequent Visitor

@Lorribot Forest functional level must be Server 2012. Domain member servers where this is configured must be Server 2012. Considering that Server 2008 is deprecated, you should safely assume that this is not supported on anything lower than a 2012 functional level. And, since you need to be EITHER a Domain Admin or Enterprise Admin, assume this is a Domain setting.

Established Member

Is the step Install-ADServiceAccount -Identity "Mygmsa1" required for a gMSA?  This article: Install-ADServiceAccount (ActiveDirectory) | Microsoft Docs says that Install-ADServiceAccount "Installs an Active Directory managed service account on a computer or caches a group managed service account on a computer."  What does the "install" actually do?

Occasional Visitor

@TerryZolinskiThe lack of clarity over whether something is domain or forrest dependant is something I have to deal with on a day to day basis, yes we should not have set up our Forrest as we did but it was done in 2000 and that was different times with different versions of Exchange and business needs, now we have to live with it as the pain of moving would be immense (don't get me satrted on O365 problems we run in to). We have a root domain and 7 geo-based sub domains, I have no control over the root (Forrest) or other subdomains so it is important to me that the differences between where stuff is configured is explicitly and clearly stated such as if it has to be that the FFL is set 2012 or the DFL is 2012 or later. Whether yo need to be an Enterprise Admin or domain Admin is also important, many articles say Enterprise Admin but if you are only running stuff against a domain it is only Domain Admin you need, or say Domain admin but they actually need Enterprise Admin again these terms seem to be interchangable to some writers.
If you are in the happy place of only having a single domain/forrest over which you have total control lucky you as this stuff will be unimportant.

Frequent Visitor

@Lorribot If you need definitive answers, why are you reading a community article and asking the community? Not that community members are here to serve you, but I found the answer to what you are looking for in about 30 seconds of Googling over on Getting Started with Group Managed Service Accounts | Microsoft Docs. In this article you will see the scope is domain, so this means the domain schema matters, not the forest schema.


If you have a problem with free information, perhaps you should take it upon yourself to find the answers you are looking for rather than complain to people who are just trying to help. My comment was merely to help steer you in the right direction. You're not the only one dealing with a complex environment, so don't assume community members are below you.


You're welcome for the free information.

Version history
Last update:
‎Sep 20 2019 04:19 AM
Updated by: