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 "web.rebeladmin.com" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"
In above Mygmsa1 is the service account and web.rebeladmin.com 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.