SPN Governance & Delegation

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. 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.

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

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. In contrast, a gMSA inherits from the computer class hierarchy:

Path: top -> person -> organizationalPerson -> user -> computer -> msDS-ManagedServiceAccount -> msDS-GroupManagedServiceAccount.

Because gMSAs are recognized as computer-tier objects by the directory:

First: The account owns its service principal namespace.

Second: Host member servers querying the directory validate SPN mappings against computer security descriptors rather than generic user objects.

Third: The Active Directory schema enforces strict mutual exclusion. Duplicate SPN registration across the forest triggers native schema collisions (STATUS_DUPLICATE_NAME / LDAP Error 68), preventing ticket hijack attacks.

Cryptographic Defense: Kerberoasting Resilience

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

The Kerberoasting Attack Sequence on Standard Accounts:

Step 1: 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).

Step 2: 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).

Step 3: The KDC generates the TGS ticket (AP-REQ / KRB_TGS_REP). The ticket's session key and privilege attribute certificate (PAC) are encrypted using the target service account's secret key.

Step 4: The requesting user extracts the ticket directly from local memory (LSA session).

Step 5: The ticket is subjected to an offline dictionary or brute-force attack. 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.

The Mathematical Failure of Offline Attacks on gMSAs:

When a gMSA holds the SPN, the attack pattern collapses entirely:

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

Standard RC4-HMAC and AES ticket cracking engines (such as Hashcat or John the Ripper) rely on dictionary attacks against human-entropy strings. 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.

Inspection Primitives:

To inspect SPN mappings and supported encryption types for a target gMSA via PowerShell:

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

Encryption Flag Bitmask Breakdown:

0x00000001: DES-CBC-CRC (Deprecated / Vulnerable)

0x00000002: DES-CBC-MD5 (Deprecated / Vulnerable)

0x00000004: RC4-HMAC (Vulnerable to fast hashing)

0x00000008: AES128-CTS-HMAC-SHA1-96 (Secure)

0x00000010: AES256-CTS-HMAC-SHA1-96 (Mandatory Production Baseline)

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.

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. The delegation architecture governs how credentials and tickets traverse these network boundaries.

Model 1: Unconstrained Delegation (The Structural Vulnerability)

Operational Mechanic:

The client requests a ticket to the intermediate service. The client's Ticket Granting Ticket (TGT) is embedded inside the Service Ticket (TGS) and forwarded directly to the intermediate server. The intermediate server extracts the user's TGT and stores it inside LSASS memory.

Structural Failure:

The intermediate server now possesses full delegated authority for that user. 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.

gMSA Governance Rule:

Under no circumstances should a gMSA ever be configured for Unconstrained Delegation (userAccountControl bit 0x80000 / TRUSTED_FOR_DELEGATION).

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.

Operational Mechanic:

Configured directly on the intermediate service account object using the multi-valued attribute msDS-AllowedToDelegateTo.

When the intermediate service requests a ticket on behalf of a user, the KDC inspects msDS-AllowedToDelegateTo. If the target SPN matches, the KDC issues the service ticket.

Structural Limitation:

Administrative rights over the intermediate account are required to grant access to the backend resource. 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.

Model 3: Protocol Transition (S4U2Self and S4U2Proxy)

Constrained delegation operates under two Microsoft Kerberos protocol extensions:

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. The client does not need to authenticate via Kerberos initially; they can authenticate via forms, OAuth, SAML, or NTLM. The service uses S4U2Self to obtain a valid Kerberos ticket for that client name within its own boundary.

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.

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.

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.

Operational Mechanic:

Instead of configuring the outgoing path on the front-end identity, the trust boundary is enforced on the target resource.

The backend resource (e.g., the database host computer account or a database gMSA) populates its own attribute: msDS-AllowedToActOnBehalfOfOtherIdentity.

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.

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.

Cross-Domain Support: RBCD works seamlessly across Active Directory domain boundaries within a forest without requiring complex inter-domain trust configurations.

Zero LSASS TGT Exposure: The client's TGT is never forwarded to or stored on intermediate hosts, neutralizing credential dumping vectors.

Implementation Blueprint: Configuring RBCD for a gMSA

Scenario:

Front-end Web API running under gMSA: svc_web_api

Backend SQL Server running under gMSA: svc_sql_data

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

Construct an Access Control Rule granting Principal Access to the front-end SID:

$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")}}

Operational Failure Modes and Verification

Symptom: Kerberos Error KRB_AP_ERR_BAD_INTEGRITY (0x1f)

Root Cause: Encryption type mismatch. 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.

Symptom: 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). The client must be forced to use TCP for Kerberos exchanges via the MaxPacketSize registry parameter under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.

Symptom: 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.