Skip to content

KDS Root Key & Kerberos Plumbing

Group Managed Service Accounts (gMSAs) eliminate human credential management by relying on a distributed, cryptographic password derivation engine built directly into Active Directory[cite: 1].

Understanding this plumbing requires examining two components: the Group Key Distribution Service (KDS) and the Kerberos Ticket Granting Service (TGS) exchanges that authorized hosts execute at runtime[cite: 1].

The KDS Architecture (kdssvc.dll)

The Group Key Distribution Service is a system service running inside the Local Security Authority (LSA) on every Windows Server domain controller[cite: 1].

  • Service Binary: %systemroot%\system32\kdssvc.dll[cite: 1]
  • Directory Container: CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=domain,DC=lan[cite: 1]

The KDS is not a database of passwords[cite: 1]. It is a pseudo-random function (PRF) key derivation engine[cite: 1]. When an authorized endpoint asks for a password, the KDS performs a deterministic calculation using a shared domain-wide secret: the KDS Root Key[cite: 1].

The KDS Root Key Lifecycle

Before any gMSA can be created or queried in an Active Directory forest, at least one KDS Root Key must be generated[cite: 1].

Root Key Generation Cmdlets

In production, a root key is provisioned using Active Directory PowerShell[cite: 1]:

# Production Provisioning (Subject to 10-hour replication delay)
Add-KdsRootKey

# Lab / Test Environments Only (Immediate Effective Time)
Add-KdsRootKey -EffectiveImmediately

The Ten-Hour Synchronization Boundary

When Add-KdsRootKey runs without parameters, Active Directory creates the key with an effective start time set 10 hours in the future[cite: 1].

Why Ten Hours? The ten-hour delay is not an arbitrary waiting period; the average Active Directory inter-site replication convergence boundary requires a guaranteed buffer so every Domain Controller possesses the root key before any host requests a derivation[cite: 1].

If an endpoint were permitted to use a new gMSA immediately[cite: 1]:

  1. Host A queries DC01 (the local DC that has the KDS Root Key)[cite: 1]. DC01 computes Password A[cite: 1].
  2. Service on Host A starts and registers Kerberos state[cite: 1].
  3. Host B (in a remote site) queries DC02 before the Root Key has replicated across the Inter-Site Topology Generator (ISTG) links[cite: 1].
  4. DC02 refuses the request or fails to derive the key, resulting in Invalid Credentials failures across federated services[cite: 1].

After 10 hours, the key crosses its effective timestamp and becomes automatically elected for password computation by all Domain Controllers[cite: 1].

The Password Calculus

You can think of KDS password generation not as a random string generator, but as a pure mathematical function of three inputs[cite: 1]:

  • KDS Root Key ($K_{\text{root}}$): The cryptographic secret stored in the Active Directory Configuration Partition[cite: 1].
  • Account SID ($\text{SID}_{\text{subject}}$): The unique Security Identifier of the gMSA object (prevents two gMSAs from ever generating the same password)[cite: 1].
  • Time Interval Index ($T_{\text{interval}}$): The current time block, calculated as the elapsed period since the start date divided by msDS-ManagedPasswordInterval (default: 30 days)[cite: 1].

Because the function is deterministic, any Domain Controller possessing the Root Key and presented with the same SID and Time Index will compute the exact same 120-character string, even if they never communicated with each other[cite: 1].

Kerberos Plumbing & Ticket Exchanges

When a service runs under a gMSA, its Kerberos authentication flows parallel traditional machine accounts but utilize refined attribute mappings[cite: 1].

1. Service Ticket (TGS) Mechanics

When a client connects to a service running under a gMSA (for example, MSSQL on port 1433)[cite: 1]:

  1. The client queries the KDC for a Ticket Granting Service (TGS) ticket matching the SPN MSSQLSvc/db01.lab.lan:1433[cite: 1].
  2. The KDC searches the Global Catalog, finds the SPN associated with the gMSA machine object, computes the current gMSA password, and encrypts the TGS using that key[cite: 1].
  3. The client presents the TGS to the database server[cite: 1].
  4. The database server's local LSASS session, which retrieved the derived password during service initialization, decrypts the ticket directly[cite: 1]. No domain controller connection is required for this decryption step[cite: 1].

2. Service for User (S4U) Extensions

gMSAs fully support Microsoft's S4U Kerberos extensions[cite: 1]:

  • S4U2Self: Allows the gMSA service to request a TGS ticket to itself on behalf of a user authenticated via non-Kerberos mechanisms (such as a basic form or legacy web logon) even if the user did not provide a Kerberos ticket[cite: 1].
  • S4U2Proxy: Allows the service to use that acquired ticket to request a further service ticket to backend resources (such as a database tier), provided Constrained Delegation is configured[cite: 1].

Edge Case: Clock Skew & Time Boundary Desynchronization

Because passwords are derived mathematically using a time block, NTP synchronization is critical[cite: 1].

  • Windows Kerberos has a hard-coded maximum clock skew tolerance of 5 minutes[cite: 1].
  • If a member server's NTP clock drifts beyond this limit, it fails to exchange Kerberos tickets with the domain KDCs[cite: 1].
  • If a Domain Controller's NTP clock drifts across an msDS-ManagedPasswordInterval boundary, it calculates a different rollover password than an un-drifted DC, producing Event ID 787 and Event ID 788 errors[cite: 1].

Next Steps