Skip to content

SPN Governance, Kerberos Delegation, and Cryptographic Boundaries

1. The Identity Mechanics of Service Principal Names

A Service Principal Name (SPN) is the unique identifier by which a Kerberos client associates a service instance with a target service logon account[cite: 1]. In standard user account models, SPNs introduce immediate operational risk: they are manually registered by administrators, lack strict validation against directory objects, and link directly to accounts vulnerable to offline brute-force cracking[cite: 1].

When applied to Group Managed Service Accounts (gMSAs), the SPN boundary fundamentally shifts from an administrative task to an automated directory primitive[cite: 1].

Class Semantics and Attribute Storage

Standard user accounts store SPNs on the user object class, requiring the setspn command-line utility or manual writes to the servicePrincipalName attribute[cite: 1]. In contrast, a gMSA inherits from the computer class hierarchy[cite: 1]:

top -> person -> organizationalPerson -> user -> computer -> msDS-ManagedServiceAccount -> msDS-GroupManagedServiceAccount

Because gMSAs are recognized as computer-tier objects by the directory[cite: 1]:

  1. Namespace Ownership: The account owns its service principal namespace[cite: 1].
  2. Computer Descriptor Validation: Host member servers querying the directory validate SPN mappings against computer security descriptors rather than generic user objects[cite: 1].
  3. Schema Mutual Exclusion: The Active Directory schema enforces strict mutual exclusion[cite: 1]. Duplicate SPN registration across the forest triggers native schema collisions (STATUS_DUPLICATE_NAME / LDAP Error 68), preventing ticket hijack attacks[cite: 1].

2. Cryptographic Defense: Kerberoasting Resilience

To appreciate why gMSA SPN architecture is resilient against Kerberoasting, the raw cryptographic exchange must be evaluated from first principles[cite: 1].

The Kerberoasting Attack Sequence on Standard Accounts

  1. Ticket Request: An unprivileged domain user requests a Ticket Granting Service (TGS) ticket from the Key Distribution Center (KDC) for an arbitrary registered SPN (e.g., MSSQLSvc/db01.lab.lan:1433)[cite: 1].
  2. Key Lookup: The KDC looks up the SPN, identifies the owning account, and retrieves the account's password hash (typically derived via NTLM/RC4 or AES-256 keys)[cite: 1].
  3. Ticket Generation: The KDC generates the TGS ticket (KRB_TGS_REP)[cite: 1]. The ticket's session key and Privilege Attribute Certificate (PAC) are encrypted using the target service account's secret key[cite: 1].
  4. Memory Extraction: The requesting user extracts the ticket directly from local memory (LSA session)[cite: 1].
  5. Offline Cracking: The ticket is subjected to an offline dictionary or brute-force attack[cite: 1]. Because the domain controller does not log an alert when a legitimate domain user asks for a TGS ticket, this extraction occurs entirely out of sight of standard SIEM ingestion[cite: 1].

The Mathematical Failure of Offline Attacks on gMSAs

When a gMSA holds the SPN, the attack pattern collapses entirely[cite: 1]:

The KDC encrypts the TGS payload using the derived gMSA key[cite: 1]. This key is derived from a 120-character, cryptographically randomized byte array generated via pseudo-random function (PRF) algorithms leveraging the KDS Root Key, the account Security Identifier (SID), and the current time cycle interval[cite: 1].

Standard RC4-HMAC and AES ticket cracking engines (such as Hashcat or John the Ripper) rely on dictionary attacks against human-entropy strings[cite: 1]. A 120-character cryptographic password with high entropy yields a keyspace so vast that offline recovery is computationally infeasible before the interval expires and the key rolls over[cite: 1].

Inspection Primitives

To inspect SPN mappings and supported encryption types for a target gMSA via PowerShell[cite: 1]:

Get-ADServiceAccount -Identity "svc_sql_prod" -Properties ServicePrincipalNames, msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes, @{Name="SPNs";Expression={$_.ServicePrincipalNames}}

Encryption Flag Bitmask Breakdown

Hex Value Algorithm Security Posture
0x00000001 DES-CBC-CRC Deprecated / Vulnerable[cite: 1]
0x00000002 DES-CBC-MD5 Deprecated / Vulnerable[cite: 1]
0x00000004 RC4-HMAC Vulnerable to fast hashing[cite: 1]
0x00000008 AES128-CTS-HMAC-SHA1-96 Secure[cite: 1]
0x00000010 AES256-CTS-HMAC-SHA1-96 Mandatory Production Baseline[cite: 1]

A hardened gMSA must have msDS-SupportedEncryptionTypes set to 0x18 (or 24 in decimal), enforcing AES-128 and AES-256 only, completely disabling RC4-HMAC ticket fallback[cite: 1].

3. Kerberos Delegation Paradigms

In modern multi-tier enterprise architecture, front-end engines (web nodes, API gateways, load balancers) must access backend storage and compute tiers (SQL Server, file clusters) while preserving the identity of the invoking client[cite: 1]. The delegation architecture governs how credentials and tickets traverse these network boundaries[cite: 1].

Model 1: Unconstrained Delegation (The Structural Vulnerability)

  • Operational Mechanic: The client requests a ticket to the intermediate service[cite: 1]. The client's Ticket Granting Ticket (TGT) is embedded inside the Service Ticket (TGS) and forwarded directly to the intermediate server[cite: 1]. The intermediate server extracts the user's TGT and stores it inside LSASS memory[cite: 1].
  • Structural Failure: The intermediate server now possesses full delegated authority for that user[cite: 1]. If an adversary compromises the intermediate tier, they harvest all cached TGTs from LSASS and replay them against any resource across the Active Directory forest[cite: 1].
  • gMSA Governance Rule: Under no circumstances should a gMSA ever be configured for Unconstrained Delegation (userAccountControl bit 0x80000 / TRUSTED_FOR_DELEGATION)[cite: 1].

Model 2: Constrained Delegation (Traditional / Service-Centric)

Introduced in Windows Server 2003, Constrained Delegation bounds the intermediate identity's impersonation capability to an explicit list of target SPNs[cite: 1].

  • Operational Mechanic: Configured directly on the intermediate service account object using the multi-valued attribute msDS-AllowedToDelegateTo[cite: 1]. When the intermediate service requests a ticket on behalf of a user, the KDC inspects msDS-AllowedToDelegateTo[cite: 1]. If the target SPN matches, the KDC issues the service ticket[cite: 1].
  • Structural Limitation: Administrative rights over the intermediate account are required to grant access to the backend resource[cite: 1]. If a backend database administrator needs to allow a new front-end service to connect, they must request a directory modification on the front-end object from Domain Admins[cite: 1].

Model 3: Protocol Transition (S4U2Self and S4U2Proxy)

Constrained delegation operates under two Microsoft Kerberos protocol extensions[cite: 1]:

  • Extension A — Service-for-User-to-Self (S4U2Self): Enables a service to request a Kerberos service ticket to itself on behalf of an arbitrary client[cite: 1]. The client does not need to authenticate via Kerberos initially; they can authenticate via forms, OAuth, SAML, or NTLM[cite: 1]. The service uses S4U2Self to obtain a valid Kerberos ticket for that client name within its own boundary[cite: 1].
  • Extension B — Service-for-User-to-Proxy (S4U2Proxy): Takes the ticket acquired via S4U2Self (or via native Kerberos authentication) and presents it to the KDC to acquire a downstream ticket to an SPN listed in msDS-AllowedToDelegateTo[cite: 1].
  • Security Control: If protocol transition is not explicitly required, set the delegation flag to "Use Kerberos Only" rather than "Use any authentication protocol" to prevent unauthorized protocol elevation at the perimeter[cite: 1].

Model 4: Resource-Based Constrained Delegation (RBCD)

Introduced in Windows Server 2012, RBCD inverts the delegation trust relationship entirely, establishing modern best practice for multi-tier gMSA environments[cite: 1].

  • Operational Mechanic: Instead of configuring the outgoing path on the front-end identity, the trust boundary is enforced on the target resource[cite: 1]. The backend resource (e.g., the database host computer account or a database gMSA) populates its own attribute: msDS-AllowedToActOnBehalfOfOtherIdentity[cite: 1]. This attribute stores a binary Security Descriptor (SDDL) containing an explicit Access Control Entry (ACE) granting the front-end gMSA the right to act on its behalf[cite: 1].

The Architectural Advantages of RBCD:

  • Separation of Privilege: The owner of the backend resource grants or revokes access without needing Domain Admin rights or access to modify the front-end object[cite: 1].
  • Cross-Domain Support: RBCD works seamlessly across Active Directory domain boundaries within a forest without requiring complex inter-domain trust configurations[cite: 1].
  • Zero LSASS TGT Exposure: The client's TGT is never forwarded to or stored on intermediate hosts, neutralizing credential dumping vectors[cite: 1].

4. Implementation Blueprint: Configuring RBCD for a gMSA

  • Front-End Web API running under gMSA: svc_web_api[cite: 1]
  • Backend SQL Server running under gMSA: svc_sql_data[cite: 1]
# Step 1: Retrieve the Security Identifier (SID) of the front-end gMSA
$FrontEndgMSA = Get-ADServiceAccount -Identity "svc_web_api"
$FrontEndSID = $FrontEndgMSA.SID

# Step 2: Generate the Raw Security Descriptor for RBCD
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($FrontEndSID))"
$BinarySD = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($BinarySD, 0)

# Step 3: Commit the Security Descriptor to the Backend Resource
Set-ADServiceAccount -Identity "svc_sql_data" -Replace @{"msDS-AllowedToActOnBehalfOfOtherIdentity" = $BinarySD}

# Verification Command:
Get-ADServiceAccount -Identity "svc_sql_data" -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Select-Object Name, @{Name="AllowedToActSDDL";Expression={(New-Object Security.AccessControl.RawSecurityDescriptor($_.msDS-AllowedToActOnBehalfOfOtherIdentity, 0)).GetSddlForm("All")}}

5. Operational Failure Modes and Verification

Symptom 1: Kerberos Error KRB_AP_ERR_BAD_INTEGRITY (0x1f)

  • Root Cause: Encryption type mismatch[cite: 1]. The client or domain controller attempted to use RC4-HMAC while the gMSA was strictly hardened for AES-256, or host clock skew corrupted the ticket verification hash[cite: 1].

Symptom 2: Kerberos Error KRB_ERR_RESPONSE_TOO_BIG (0x34)

  • Root Cause: The user account being impersonated belongs to dozens of security groups, inflating the Privilege Attribute Certificate (PAC) beyond the maximum UDP datagram threshold (typically 1472 bytes)[cite: 1]. The client must be forced to use TCP for Kerberos exchanges via the MaxPacketSize registry parameter under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters[cite: 1].

Symptom 3: STATUS_AUTHENTICATION_FIREWALL_FAILED (0xc0000413)

  • Root Cause: When delegating across trust boundaries, the intermediate identity lacks the "Allowed to Authenticate" permission on the target computer object[cite: 1].