During a penetration test, an ordinary domain user account, the kind any phished employee has, asks Active Directory for a Kerberos service ticket for the SQL Server service account. Part of the ticket is encrypted with a key derived from that account's password, so the tester takes it offline and cracks it in under an hour. The password is an eight-year-old seasonal phrase, and the account is a member of Domain Admins.
That chain, called Kerberoasting, is an identity design failure rather than a software bug. On the CompTIA Security+ SY0-801 exam, identity management sits under objective 3.2, which expects you to manage the architecture that protects the infrastructure. This lesson covers group Managed Service Accounts, least-privilege account design for administrators, and privilege creep, the slow build-up of access that turns ordinary accounts into dangerous ones.
Service accounts are attractive targets because their passwords rarely change
Services such as SQL Server, IIS application pools, backup agents and scheduled tasks run under an identity. When that identity is an ordinary domain user created by hand, the same weaknesses appear in almost every environment:
- The password was set once, years ago, with "password never expires" checked, because changing it means updating every server that uses it and risking an outage.
- People know it: the administrator who created it, whoever installed the application, and anyone who reads the script or configuration file it was pasted into.
- It holds far more rights than it needs, often Domain Admins, because that made the installer stop complaining.
- It can sign in interactively, so a stolen password works at a console or over RDP.
Kerberoasting exploits the first weakness. Any authenticated domain user can request a service ticket for any account that has a service principal name (SPN), and part of that ticket is encrypted with a key derived from the service account's password. Domain controllers record the request only as event 4769, a routine service ticket request that blends in with thousands of others, and the cracking happens offline where nothing can detect it. A human-chosen password falls quickly. A short audit shows the exposure:
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties PasswordLastSet, PasswordNeverExpires |
Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires
SamAccountName PasswordLastSet PasswordNeverExpires
-------------- --------------- --------------------
svc_sql 3/14/2018 9:02:11 AM True
svc_backup 11/2/2019 4:40:57 PM True
A gMSA lets Active Directory own the password, so no person ever knows it
A group Managed Service Account (gMSA) is a domain account built for services, introduced in Windows Server 2012, whose password Active Directory generates and rotates itself. The Key Distribution Service on domain controllers computes the password from a secret root key, producing more than 200 bytes of random-looking data, and changes it automatically, every 30 days by default. Servers that are allowed to use the account retrieve the current password from a domain controller when they need it. No administrator types it, sees it or stores it.
That fixes each weakness from the previous section. Rotation happens without an outage, because every authorized server picks up the new password on its own. Nobody can leak a password they never had. And a long random password makes Kerberoasting pointless: the ticket can still be requested, but cracking it offline isn't feasible.
gMSAs replaced an earlier design, the standalone managed service account (sMSA) from Windows Server 2008 R2, which also rotated its own password but could be used on only one computer. The group version can be shared by many servers, which is what server farms, clusters and load-balanced applications need.
The password is managed, but the rights are not. A gMSA still gets only the permissions its service needs, such as the right to log on as a service on its hosts and access to one database, and it should never be added to Domain Admins.