Lion Cipher Lab
Stop service-account Kerberoasting with a group Managed Service Account (gMSA)
- Identity & Access Management
- Intermediate
- ~60 min
- Free · no account required
Why it matters
Service accounts are the quiet weak point of almost every Active Directory. An application, a SQL Server, a scheduled task or a web app needs to run as some domain identity, so an admin creates a normal user account, gives it a password, and — because rotating it means coordinating an outage with whoever owns the app — that password is set once and left for years. To let Kerberos authenticate the service, the account is given a Service Principal Name (SPN): a label like MSSQLSvc/db01.corp.local:1433 that ties a service on a host to that identity. Here is the problem, and it is the whole…
What you'll learn
- explaining in plain words what a Service Principal Name (SPN) is, why any account that carries one is a Kerberoasting target, and why the crack happens OFFLINE against the account's password
- defining a group Managed Service Account (gMSA): an AD-managed identity whose password Active Directory generates (240 bytes / 256 characters) and auto-rotates (default every 30 days), that no human ever knows
- creating the Key Distribution Services (KDS) root key with Add-KdsRootKey — and knowing why a fresh single-DC lab needs the backdated -EffectiveTime shortcut that a real multi-DC forest must never use
- creating a gMSA with New-ADServiceAccount and authorising exactly which member hosts may retrieve its password via -PrincipalsAllowedToRetrieveManagedPassword pointed at a group
- installing the gMSA on a domain-joined member server with Install-ADServiceAccount and verifying it end-to-end with Test-ADServiceAccount (which must return True)
- running a Windows service or scheduled task under the gMSA — supplying the account name ending in `
Stop service-account Kerberoasting with a group Managed Service Account (gMSA) — Lion Cipher Lab with NO password field — and confirming with Get-ADServiceAccount that the secret is machine-managed", "measuring the before/after: contrasting a normal SPN service account (human-chosen, crackable password) with the gMSA (machine-generated, auto-rotated, not a realistic Kerberoast target)", "judging when to reach for a gMSA vs a normal service account, why it beats a calendar-reminder rotation process, its honest limits (functional level 2012+, no interactive logon, SPN still present), and where dMSA fits on Server 2025" ], "educationalLevel": "Intermediate", "timeRequired": "PT60M", "about": "Identity & Access Management", "datePublished": "2026-09-30", "provider": { "@type": "Organization", "name": "Lion Cipher", "url": "https://www.lioncipherlabs.com" }, "isPartOf": { "@type": "WebSite", "@id": "https://www.lioncipherlabs.com/#website", "name": "Lion Cipher" } } with NO password field — and confirming with Get-ADServiceAccount that the secret is machine-managed - measuring the before/after: contrasting a normal SPN service account (human-chosen, crackable password) with the gMSA (machine-generated, auto-rotated, not a realistic Kerberoast target)
- judging when to reach for a gMSA vs a normal service account, why it beats a calendar-reminder rotation process, its honest limits (functional level 2012+, no interactive logon, SPN still present), and where dMSA fits on Server 2025
Steps in this lab
- From zero: SPNs, Kerberoasting, and why a human-chosen service password is the whole problem
- The fix in one idea: what a gMSA is and why AD-generated passwords beat human ones
- Create the KDS root key (and the single-DC backdating shortcut, stated honestly)
- Create a retrieval group and the gMSA with New-ADServiceAccount
- Install and verify on the member server (Install- then Test-ADServiceAccount)
- Run a service as the gMSA — account name ending in $, NO password
- Measure the before/after: the same Kerberoast attempt, two very different results
- The honest negative: what gMSA does NOT do, and where dMSA is going