Service accounts: moving to gMSA and dMSA without opening new gaps
Traditional service accounts are among the most frequent findings in our Active Directory audits: passwords never changed, often weak, sometimes known to several providers, and accounts placed in privileged groups "to make it work". Managed service accounts solve a large part of the problem, provided you understand who can read their password.
Why traditional service accounts are a problem
An ordinary service account is a user account whose password is entered in the configuration of a service, scheduled task or application. Changing it means updating every server, so nobody changes it. If it carries a service principal name, any domain user can request a ticket encrypted with that password and try to crack it offline: this is Kerberoasting. An old, weak password on a privileged account then becomes an open door.
gMSAs: how they work and what they bring
A group Managed Service Account (gMSA) is an account whose long, random password is generated and rotated automatically by the domain controllers, every 30 days by default. Nobody needs to know it. Authorised servers retrieve it themselves. The benefits are immediate:
- Kerberoasting becomes ineffective in practice, as the password cannot realistically be cracked;
- rotation is automatic, with no work on the servers;
- the account cannot be used for interactive sign-in.
Prerequisites: a KDS root key in the forest, created once, then creating the account while specifying the computers or group allowed to retrieve the password.
Who can retrieve the password
This is the first thing audits look at. The PrincipalsAllowedToRetrieveManagedPassword attribute lists the accounts allowed to read the password. Anyone who controls one of those accounts (a compromised server, a member of the authorised group, or someone able to modify that group) obtains the gMSA's password, and therefore its privileges. A gMSA in a privileged group whose password can be read by a group of poorly protected servers recreates exactly the problem it was meant to solve. Authorised principals must sit in the same tier as the account.
Limits and migration steps
Not every application supports gMSAs: Windows services, scheduled tasks, IIS application pools and SQL Server do, but an application that requires a password typed into its own configuration file will not. A migration goes like this:
- inventory service accounts, the servers that use them and their actual privileges;
- check each application's compatibility;
- create the gMSA with only the rights it needs, taking the opportunity to remove the account from privileged groups;
- install and test the account on the authorised servers, then switch the service over;
- disable the old account, monitor, then delete it.
Windows Server 2025 dMSAs, and the "BadSuccessor" warning
Windows Server 2025 introduces delegated Managed Service Accounts (dMSAs). They allow an existing service account to be migrated to a managed account by linking it to the old account, whose rights it takes over, and then disabling use of the old password. Their authentication is also tied to the identity of the authorised machines.
In 2025, Akamai researchers published the "BadSuccessor" technique: a user able to create a dMSA in any OU could declare it the successor of any account, including a domain administrator, and obtain its privileges. A single Windows Server 2025 domain controller was enough, even if the organisation did not use dMSAs. Microsoft has released a fix; make sure your domain controllers are up to date and check the current state of the guidance.
Restrict dMSA creation. Regardless of the fix, identify who can create child objects, in general or of the dMSA type, in your OUs. These rights are often granted broadly by old delegations. They should be reserved for Tier 0 administrators, and any dMSA creation should be monitored.
What an audit checks
- The inventory of traditional service accounts, their password age and membership of privileged groups.
- Accounts with a service principal name exposed to Kerberoasting.
- For each gMSA, the principals allowed to retrieve the password and how well they are protected.
- Rights to create child objects on OUs, particularly for dMSAs, and the patch level of Windows Server 2025 domain controllers.
- Effective disablement of old accounts after migration.