The Service Account Vulnerability
In a standard Windows Server environment, enterprise applications (like Microsoft SQL Server, IIS Web Pools, or custom scheduled tasks) cannot run as the logged-in administrator. They must run constantly in the background. Traditionally, IT administrators create a standard Active Directory user account (e.g., SVC_SQLAdmin), check the box “Password never expires,” and assign this account to the SQL service.
This is a massive security vulnerability. Because the password never expires, it is rarely changed. Because multiple administrators need to restart the service occasionally, the password is often shared in insecure Excel spreadsheets. If a hacker breaches the network and extracts the plaintext password for SVC_SQLAdmin from a compromised server’s memory, they instantly gain domain-wide access.
To eliminate this threat, Microsoft introduced Group Managed Service Accounts (gMSA). A gMSA is a highly specialized Active Directory account designed exclusively for services. The defining feature of a gMSA is that no human knows the password. Active Directory generates a complex, 120-character cryptographic password for the account, automatically rotates it every 30 days, and securely hands it directly to the authorized Windows Servers that need it. You can never “log in” as a gMSA interactively, making it immune to credential theft.
Step 1: Creating the KDS Root Key
Before you can create your first gMSA, you must generate a Key Distribution Service (KDS) Root Key in Active Directory. The Domain Controllers use this root key to mathematically generate the rotating passwords.
Log into a Domain Controller, open an elevated PowerShell prompt, and run:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)(Note: We use AddHours(-10) to trick AD into believing the key was generated in the past, bypassing the standard 10-hour replication wait time required in massive multi-site forests).
Step 2: Defining the Authorized Servers
A gMSA is useless if every server in the domain can request its password. You must explicitly define which specific servers are authorized to use the account.
Open Active Directory Users and Computers (ADUC). Create a new Global Security Group named SQL_Servers_Group. Add the computer objects of your SQL servers (e.g., SQL-PROD-01 and SQL-PROD-02) as members of this group.
Step 3: Creating the gMSA Account
You cannot create a gMSA using the graphical ADUC interface; you must use PowerShell.
On the Domain Controller, execute the following command to create a gMSA named gMSA_SQLService and explicitly grant password retrieval rights to the security group you created in Step 2:
New-ADServiceAccount -Name "gMSA_SQLService" -DNSHostName "gMSA_SQLService.yourdomain.local" -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers_Group"The account is now created in Active Directory. If you look closely in ADUC (ensure “Advanced Features” is enabled), you will see it listed under the hidden “Managed Service Accounts” OU.
Step 4: Installing the gMSA on the Target Server
Active Directory now owns the account, but the target SQL server does not yet know it is allowed to use it.
Log into the target server (SQL-PROD-01). Because you added this server to the security group, it requires a reboot to refresh its Kerberos ticket and recognize its new group membership.
After rebooting, open PowerShell on SQL-PROD-01 and install the Active Directory PowerShell module if it is not already present:
Install-WindowsFeature RSAT-AD-PowerShellNow, execute the command to install the gMSA on the local machine:
Install-ADServiceAccount -Identity "gMSA_SQLService"To definitively prove that the server successfully retrieved the 120-character password from the Domain Controller, run the test command:
Test-ADServiceAccount -Identity "gMSA_SQLService"If it returns True, the cryptographic exchange was successful.
Step 5: Configuring the Service to Use the gMSA
Now you can finally configure your application (e.g., the SQL Server service, IIS, or a Scheduled Task) to use the unhackable account.
- Open the Services MMC snap-in (
services.msc). - Right-click the target service and select Properties.
- Navigate to the Log On tab.
- Select This account.
- Type the gMSA account name, ensuring you append a dollar sign (
$) to the end (e.g.,YOURDOMAIN\gMSA_SQLService$). The dollar sign tells Windows this is a managed account. - Leave both password fields completely blank.
- Click OK.
When you start the service, the Windows Local Security Authority (LSA) intercepts the request, securely fetches the current password from the Domain Controller in the background, and injects it into the service.
Conclusion
Static service account passwords are a critical vulnerability that attackers exploit to traverse corporate networks. By migrating infrastructure services to Group Managed Service Accounts (gMSA), Windows Server administrators entirely automate the password rotation lifecycle, eliminating human password management and mathematically neutralizing credential-harvesting attacks.