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.
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.