2.2 Service Account Types & Group Managed Service Accounts (gMSA)

Service Account Types & Group Managed Service Accounts (gMSA)

Running background services, line-of-business applications, scheduled tasks, and Internet Information Services (IIS) worker processes requires identity security principals known as service accounts. Historically, administrators relied on standard domain user accounts with non-expiring passwords, exposing enterprise environments to credential dumping, Kerberoasting, and severe password rotation overhead.

Modern Windows Server hybrid infrastructures leverage Managed Service Accounts (MSAs)—specifically Group Managed Service Accounts (gMSAs)—to automate credential management, enforce Kerberos cryptographic isolation, and support scalable multi-server load-balanced farms.

---

1. Comparison of Service Account Options

Windows Server environments support four distinct types of service accounts, each tailored to specific workload isolation requirements.

---

2. gMSA Architecture and Security Mechanics

A Group Managed Service Account (gMSA) is an Active Directory computer-like object class (msDS-GroupManagedServiceAccount) whose password lifecycle is governed centrally by domain controllers running the Microsoft Key Distribution Service (KDS) (kdscli.exe).

+-----------------------------------------------------------------------------------+
|                         gMSA ARCHITECTURE & PASSWORD FLOW                         |
|                                                                                   |
|  [HOST SERVER: WebServer01]                      [DOMAIN CONTROLLER / KDS]        |
|   - Member of 'SG_WebFarmHosts'                     - Holds KDS Root Key          |
|   - IIS App Pool running as:                        - Generates 240-byte complex  |
|     'CONTOSO\gMSA_Web$'                               passwords via KDS algorithm |
|          |                                                  |                     |
|          | 1. MS-SAMR / RPC Password Request                |                     |
|          |    (Host proves identity via computer account)   |                     |
|          |------------------------------------------------->|                     |
|          |                                                  |                     |
|          | 2. DC validates WebServer01 is in                |                     |
|          |    'PrincipalsAllowedToRetrieveManagedPassword'  |                     |
|          |                                                  |                     |
|          | 3. DC returns current managed password           |                     |
|          |<-------------------------------------------------|                     |
|          |                                                                        |
|   [HOST SERVER: WebServer01]                                                      |
|   - Caches password in LSA secret memory                                          |
|   - Authenticates service seamlessly                                              |
+-----------------------------------------------------------------------------------+

Core Security Benefits of gMSA:

1. Cryptographic Complexity: KDS generates a 240-byte random password using combined AES-256 keys derived from the KDS root key and the gMSA object's attributes.
2. Automatic 30-Day Rotation: Passwords rotate automatically every 30 days (ManagedPasswordIntervalInDays). The DC calculates both the current and prior password, ensuring zero service disruption during rotation cycles.
3. Mitigation of Kerberoasting: Standard domain accounts with weak passwords can be requested by any authenticated user for Kerberos ticket cracking offline. gMSAs utilize 240-byte machine-generated keys that render offline brute-force cracking mathematically infeasible.
4. Interactive Logon Prevention: gMSAs cannot be used for interactive console or RDP logons, reducing attack surface.

---

3. Key Distribution Services (KDS) Root Key Requirements

Before creating the first gMSA in an Active Directory forest, the KDS Root Key must be generated in the Active Directory Configuration partition. The KDS root key is used by domain controllers to derive the unique passwords for all gMSAs.

Production Deployment vs. Test/Lab Deployment

# PRODUCTION: Create KDS Root Key with standard 10-hour replication wait
# Domain controllers will not issue gMSA passwords until 10 hours have elapsed
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(10))

# TEST/LAB ONLY: Backdate the effective time by 10 hours for IMMEDIATE activation
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Verify active KDS Root Keys in the forest
Get-KdsRootKey

[!IMPORTANT] The 10-Hour Replication Rule: In production environments, domain controllers enforce a default 10-hour delay after root key creation before allowing gMSA password computation. This ensures that all domain controllers across the forest have fully replicated the root key before any client host requests a password. Running New-ADServiceAccount immediately in production without waiting 10 hours (or without backdating in a lab) will result in Test-ADServiceAccount returning $False or throwing error 0x80070005 / Key does not exist.

---

4. End-to-End gMSA Provisioning Workflow

Deploying a gMSA requires five distinct, sequential operations:

# STEP 1: Create an AD Security Group containing all authorized host computers
New-ADGroup -Name "SG_WebFarmServers" `
            -GroupScope Global `
            -GroupCategory Security `
            -Path "OU=SecurityGroups,DC=contoso,DC=com"

Add-ADGroupMember -Identity "SG_WebFarmServers" -Members "WEB01$", "WEB02$"

# STEP 2: Create the gMSA object in Active Directory
New-ADServiceAccount -Name "gMSA_WebFarm" `
                     -DNSHostName "webfarm.contoso.com" `
                     -PrincipalsAllowedToRetrieveManagedPassword "SG_WebFarmServers" `
                     -ServicePrincipalNames "HTTP/webfarm.contoso.com", "HTTP/webfarm" `
                     -ManagedPasswordIntervalInDays 30 `
                     -Path "CN=Managed Service Accounts,DC=contoso,DC=com"

# STEP 3: Install the gMSA on EACH host server (Run locally on WEB01 and WEB02)
# Requires Remote Server Administration Tools (RSAT) Active Directory module
Install-ADServiceAccount -Identity "gMSA_WebFarm"

# STEP 4: Test password retrieval and host authorization (Must return True)
Test-ADServiceAccount -Identity "gMSA_WebFarm"

# STEP 5: Configure the application / service to use the gMSA
# In IIS Application Pool, set Identity to: Custom Account
# Format: CONTOSO\gMSA_WebFarm$
# Password fields: Leave completely BLANK

[!CAUTION] The Trailing Dollar Sign Requirement: When configuring a Windows Service, IIS Application Pool, or Scheduled Task to run under a gMSA, you MUST append a trailing dollar sign ($) to the account name (e.g., CONTOSO\gMSA_WebFarm$) and leave both password fields completely blank. Omitting the $ sign causes Windows to treat the account as a standard user, resulting in logon failure 0xC000006E (STATUS_ACCOUNT_RESTRICTION).

---

5. Service Principal Names (SPNs) & setspn Syntax

A Service Principal Name (SPN) is a unique identifier of a service instance registered in Active Directory, allowing Kerberos mutual authentication between clients and services. If an SPN is missing or duplicated, Kerberos authentication fails and the client falls back to NTLM (or fails entirely if NTLM is blocked).

SPN Formatting Rules

• Standard format: serviceclass/host:port/servicename or serviceclass/host
• Examples: HTTP/webfarm.contoso.com, MSSQLSvc/sql01.contoso.com:1433

Core setspn.exe Command Reference

:: Register an SPN with duplicate checking (RECOMMENDED)
setspn -s HTTP/webfarm.contoso.com CONTOSO\gMSA_WebFarm$

:: List all SPNs registered to an account
setspn -l CONTOSO\gMSA_WebFarm$

:: Scan the entire forest for duplicate SPNs (Crucial troubleshooting tool)
setspn -x

:: Delete an invalid or obsolete SPN
setspn -d HTTP/webfarm.contoso.com CONTOSO\OldServiceAcct

---

6. Kerberos Delegation Architectures

When a front-end application (e.g., a web server) needs to impersonate an authenticated user to access a backend resource (e.g., a SQL database), Active Directory provides three Kerberos delegation models:

+-----------------------------------------------------------------------------------+
|                         KERBEROS DELEGATION COMPARISON                            |
|                                                                                   |
|  [1. UNCONSTRAINED DELEGATION (High Risk)]                                        |
|   - Front-end server receives client's full Ticket Granting Ticket (TGT).         |
|   - Front-end can impersonate user to ANY service across the ENTIRE forest.       |
|   - If front-end is compromised, attacker steals all cached TGTs in LSASS.        |
|                                                                                   |
|  [2. CONSTRAINED DELEGATION (KCD - Service-Configured)]                           |
|   - Front-end uses S4U2Proxy to request tickets only for SPECIFIC backend SPNs.   |
|   - Configured on the FRONT-END account (msDS-AllowedToDelegateTo).               |
|   - Requires Domain Admin to configure; cannot cross trust boundaries easily.     |
|                                                                                   |
|  [3. RESOURCE-BASED CONSTRAINED DELEGATION (RBCD - Modern Best Practice)]         |
|   - Configured on the BACKEND RESOURCE (msDS-AllowedToActOnBehalfOfOtherIdentity).|
|   - Backend resource owner controls which front-end services can delegate to it.  |
|   - Does NOT require Domain Admin privileges; works cleanly across forest trusts. |
+-----------------------------------------------------------------------------------+

Configuring Resource-Based Constrained Delegation (RBCD)

RBCD delegates control to the backend service administrator without granting them domain-level privileges:

# Allow front-end gMSA (gMSA_WebFarm) to delegate to backend SQL Server (SQL01)
$FrontEnd = Get-ADServiceAccount -Identity "gMSA_WebFarm"
Set-ADComputer -Identity "SQL01" -PrincipalsAllowedToDelegateToAccount $FrontEnd

# Verify delegation configuration on the backend server
Get-ADComputer -Identity "SQL01" -Properties PrincipalsAllowedToDelegateToAccount