In one of my previous blog posts I talked about managed service accounts. Before start on this I really recommend you to read it to have better understanding. It can find on http://www.rebeladmin.com/2018/01/active-directory-managed-service-accounts-powershell-guide/ . As I explained in there one managed service account 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.
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.