Service accounts for starting Windows services or scheduled tasks are often configured with the "password never expires" attribute and then used for years. Often such service accounts are also alienated for a specific purpose and used on many servers for a wide variety of tasks. Service accounts with far-reaching authorizations and passwords that never expire then make it easier for attackers. Group Managed Service Accounts (gMSA accounts) are an alternative.
Group Managed Service Accounts (gMSA accounts) are better suited for launching scheduled tasks and services than normal Active Directory user accounts with never expiring passwords. The main advantage of gMSA accounts is that no password needs to be managed for this account. gMSA accounts are configured on the servers and Windows takes over the password management for the account.
This simplifies the management of service accounts as no manual user interaction is required to change the password regularly. In addition, these accounts are restricted to specific servers, so the gMSA accounts cannot be easily misused and used on many servers for different tasks.
Preparation for gMSA accounts (KDS Root Key)
In order for gMSA accounts to be created and used, a KDS root key is first required to generate the passwords. The KDS root key can be generated with the following command:
Add-KdsRootKey -EffectiveImmediately
You must now wait 10 hours before the first accounts can be created. This is a function to ensure that all domain controllers have completed replication before the first gMSA accounts are created. This prevents passwords from being generated before all domain controllers are able to respond to password requests / password changes. Even if there is only one domain controller, you still have to wait 10 hours.
Tip: If you don't want to wait 10 hours, you can use the following command, but this only works if there is no KDS root key yet:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
However, the safe way is to wait for the 10 hours and check the successful replication to avoid problems.
Create gMSA accounts
After the 10 hours have passed, new gMSA accounts can be created with the following command:
New-ADServiceAccount -Name msa_ex19ex1 -DNSHostName msa_ex19ex1.frankysweblab.de -PrincipalsAllowedToRetrieveManagedPassword EX19EX1$
The "Name" parameter defines the name of the new account; the name of the account followed by the FQDN of the domain should be selected for the "DNSHostName" parameter. This entry does not have to be created in the DNS. The "PrincipalsAllowedToRetrieveManagedPassword" parameter specifies which servers may use the account (multiple servers can be specified separated by commas).
The new account can now be found in the "Managed Service Accounts" OU in the Active Directory:
The account can now be assigned the appropriate permissions so that scripts or services can be executed. For example, the gMSA account can now be added to the Exchange group "View-Only Organization Management", so that scripts that require read access to the Exchange organization can be started with this account:
If it is necessary that local administrator rights are required on the server, the account can also be added to the local admin group of the server:
By default, the gMSA account changes its password every 30 days. The password is changed automatically and no manual intervention is required. The following command can be used to create an account with a 60-day password change interval:
New-ADServiceAccount -Name msa_ex19ex1 -DNSHostName msa_ex19ex1.frankysweblab.de -PrincipalsAllowedToRetrieveManagedPassword EX19EX1$ -ManagedPasswordIntervalInDays 60
The following command can be used to view all attributes of an account:
Get-ADServiceAccount msa_ex19ex1 -Properties *
Use gMSA accounts
To start a service with a gMSA account, only the corresponding account must be selected, the password field remains empty:
After the service has been restarted, the gMSA account is used. Retrieving and changing the password after the specified time is now done automatically.
For a scheduled task, assigning the account via the shell works with the following command:
schtasks /Change /TN "FrankysWeb Demo" /RU "frankysweblab\msa_ex19ex1$" /RP ""
Restrictions
Unfortunately, there are also restrictions for gMSA accounts. These accounts are very suitable for scheduled tasks and Windows services, but these accounts cannot be entered and used in applications. For example, many applications require a service account to be able to retrieve information from the Active Directory; these accounts are then usually entered statically in the application. In this case, the automatic password change does not work. In this case, only special, usually quite complex, PAM solutions or good documentation combined with a great deal of discipline and a good audit process can help.