Group Managed Service Account
Managed Service Account (comes with Windows Server 2008 R2) and Group Managed Service Account (comes with Windows Server 2012 R2) are objects that automate the management of service accounts and periodic password change process. Unlike MSA, GMSA can also be used in cluster structures with more than one server. This article will explain how to configure the GMSA account as it is more up-to-date.
- The password of the GMSA account is set by the KDC as 120 characters long and is automatically updated every 30 days. There is no need for any manual interaction on the server side during this process.
- Because GMSA passwords are set automatically, they are not affected by Password Policies and Fine-Grained Password Policies.
- Also, GMSA accounts neither have interactive logon rights like standard service accounts nor have high privileges unless granted especially. However, these accounts contain different risks, and we will discuss these risks in another article.
- GMSA’s can also be used for scheduled tasks other than services. However, to use it in scheduled tasks, Logon as batch job privilege must be given to the GMSA.
Powershell and ActiveDirectory module are mostly used to create a GMSA. In addition to this method, these operations can also be performed with the Managed Service Accounts GUI application of CJWDEV.
KDS Root Key and GMSA password operations can be performed by Domain Controller servers with Windows Server 2012 / R2 or higher operating systems.
For the schema changes required for GMSA operations, the Active Directory schema version must be at least Windows Server 2012.
The operating system of the servers to use the GMSA must be Windows Server 2012 and above or Windows 8 and above. Also, the Powershell Active Directory module must be installed in these systems to perform the necessary operations.
To create a GMSA, it is necessary to create a KDS Root Key first. It is sufficient to create this key once in a domain environment.
If you have created the KDS Root Key object before, you do not need to create it again.
It is sufficient to create the KDS Root Key object only in the main (root) domain. This object cannot be created on the child domain
Also, after running the following command, it is necessary to wait 10 hours for the KDS Root Key object to replicate between Domain Controllers properly.
Querying the KDS Root Key object in the domain
Creating the KDS Root Key object in the domain
To manage the servers where the GMSA accounts will be used, servers can be added into a security group. In this way, services can be managed by adding and removing from the group without making any changes on the GMSA object. Although this process is recommended, it is not mandatory for the use of GMSA.
If you create a group and add the servers to this group, you need to restart the servers for the activation of a group membership.
The group created for servers where the GMSA will be used
After performing these operations, a GMSA can be created using the following commands.
Creating GMSA using Powershell ActiveDirectory module
The server names which will use the GMSA or the parent group name of these servers should be set to the “PrincipalsAllowedToRetrieveManagedPassword” parameter. As can be understood from the name of the parameter, these servers have the right to read and use the password of the GMSA. For this reason, this parameter should be configured correctly, and irrelevant accounts should not be written to this parameter. Also, if this parameter was given as a group value, the change of group members should be monitored.
After the GMSA is created, it can be viewed with Active Directory Users and Computers application.
After the GMSA is created, login to the server where the service is running and run the following commands.
Installing the GMSA on the server
There is no need to enter a password while using the GMSA in the service.