THE HARDENING BRIEF | Issue #005 Weekly security findings for sysadmins.
The Finding
Since they aren't used by anyone but are instead intended for operational purposes and run in the background, service accounts are often overlooked.
Service accounts are attractive to hackers because they usually have high privileges and, in most environments, are never touched again after setup. Unfortunately, in the wild, one often sees service accounts with very weak passwords, which, combined with a last password change date of June 2012, make them one of the easiest targets for a domain compromise.
The problem stems mainly from the fact that standard AD users are used for service accounts.
With Group Managed Service Accounts, Microsoft has designed a solution that automatically changes the password of service accounts every 30 days to a 240-byte, randomly generated password. No human ever sees it. No human ever types it. Windows handles the full lifecycle.
This increases security, particularly against attacks such as Kerberoasting.
In this issue, I will explain how to replace your service accounts with managed service accounts.
WHY IT MATTERS
Any authenticated domain user can request a Kerberos service ticket for any account with a Service Principal Name. The ticket is encrypted with the service account's password hash. If that password is 'Summer2019!' and was last changed four years ago, an attacker cracks it offline in minutes with Hashcat.
Once cracked, they own whatever that service account has access to. SQL boxes, Exchange, backup systems. Sometimes Domain Admin.
gMSA accounts eliminate this attack path. The password is 240 bytes of random data, rotated every 30 days by default, and no human can retrieve it in plaintext. Even if an attacker pulls the TGS ticket, cracking 240 bytes of entropy is not realistic.
THE FIX
Prerequisites:
Your domain and forest functional level must be Windows Server 2012 or higher. You need the Active Directory PowerShell module installed on the DC where you'll run the commands. One Domain Controller with the KdsSvc service running.
Step 1: Create the KDS Root Key
This is a one-time operation per domain. The root key is what generates and rotates all gMSA passwords.
Add-KdsRootKey -EffectiveImmediately
Despite the flag name, this key won't actually be usable for 10 hours. That wait is by design so the key replicates to all DCs. In a lab where you only have one DC and want to skip the wait:
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))Do not use the lab shortcut in production. Seriously.
Step 2: Create the gMSA
New-ADServiceAccount -Name "svc_yourservice" `
-DNSHostName "svc_yourservice.yourdomain.com" `
-PrincipalsAllowedToRetrieveManagedPassword "SERVER01$"
Name: whatever naming convention you use. Prefix with svc_ or gmsa_ so they're easy to identify later.
DNSHostName: the account name followed by your domain FQDN. This entry doesn't need to exist in DNS.
PrincipalsAllowedToRetrieveManagedPassword: the computer account(s) allowed to use this gMSA. Separate multiple servers with commas. Use a security group if you have more than a few servers.
Optional: change the rotation interval from the default 30 days:
New-ADServiceAccount -Name "svc_yourservice" -DNSHostName "svc_yourservice.yourdomain.com"
-PrincipalsAllowedToRetrieveManagedPassword "SERVER01$" `
-ManagedPasswordIntervalInDays 60Step 3: Install on target server
On each server that needs to use the gMSA, run:
Install-ADServiceAccount -Identity "svc_yourservice"
Then verify:
Test-ADServiceAccount "svc_yourservice"If this returns True, you're good. If it returns False, the computer account probably isn't listed in PrincipalsAllowedToRetrieveManagedPassword. Fix it, reboot (or run klist purge and gpupdate /force), and test again.
If AD PowerShell module is not installed run this command first:
Install-WindowsFeature RSAT-AD-PowerShell
Step 4: Assign to a service
Open services.msc, find the service, go to the Log On tab. Enter the account as YOURDOMAIN\svc_yourservice$ (note the trailing dollar sign). Leave the password field empty. Restart the service.
Step 4b: Assign to a Scheduled Task
Scheduled tasks can't be configured through the GUI for gMSA. Use schtasks:
schtasks /Change /TN "Your Task Name" /RU "YOURDOMAIN\svc_yourservice$" /RP ""The task also needs 'Log on as a batch job' rights. Assign this via GPO:
Computer Configuration > Policies > Windows Settings > Security Settings
Rollback:
Change the service or task back to the original account. You still have the old credentials. If you don't have the old credentials, that's a separate problem and exactly why you should be switching to gMSA in the first place.
Limitations to be aware of:
gMSA only works for Windows services, IIS app pools, and Scheduled Tasks. If your application requires you to type a password into a config file or a login dialog, gMSA won't work. SQL Server 2014 and later supports gMSA. Exchange on-premises has limited gMSA support. Check with your vendor before migrating third-party services.
DETECTION
To detect Kerberoasting attempts against your remaining standard service accounts, enable 'Audit Kerberos Service Ticket Operations' under Account Logon in Advanced Audit Policy Configuration on your DCs.
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enableWatch for Event ID 4769 where the Ticket Encryption Type is 0x17 (RC4). In a modern environment, most Kerberos traffic should be AES. RC4 requests targeting user accounts with SPNs are a strong indicator of Kerberoasting.
If you use Defender for Identity, external alert ID 2410 fires on suspected Kerberos SPN exposure.
QUICK BRIEF
What: Standard AD user accounts running as service accounts with static passwords
Who's at risk: Any domain running services under regular user accounts with SPNs
Fix time: 30 minutes per service (plus 10-hour KDS key wait on first run)
Cost: Free
Requires reboot: No (service restart only)
Next issue: LAPS. Because your local admin passwords are probably identical across every machine.