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.

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

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.

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

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

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.

Root Key Generation Cmdlets

In production, a root key is provisioned using Active Directory PowerShell:

# 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 exactly 10 hours in the future.

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.

If an endpoint were permitted to use a new gMSA immediately:

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

After 10 hours, the key crosses its effective stamp and becomes automatically elected for password computation by all Domain Controllers.

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:

  • KDS Root Key (K sub root): The cryptographic secret stored in the Active Directory Configuration Partition.
  • Account SID (Subject SID): The unique Security Identifier of the gMSA-Object (prevents two gMSAs from ever generating the same password).
  • Time Interval Index (T sub interval): The current time block, calculated as the elapsed period since the start date divided by msDS-ManagedPasswordInterval (default: 30 days).

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.

Kerberos Plumbing & Ticket Exchanges

When a service runs under a gMSA, its Kerberos authentication flows parallel traditional machine accounts but utilizes refined attribute mappings.

1. SERVICE-TIRE_KEY (TGS) Mechanics

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

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

2. Service for User (S4U) Extensions

gMSAs fully support Microsoft's S4U Kerberos extensions:

  • 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.
  • S4U2proxy: Allows the service to use that acquired ticket to request a further SERVICE-TIRE_ticket to backend resources (such as a database tier), provided Constrained Delegation is configured.

Edge Case: Clock Skew & Time Boundary Desynchronization

Besause passwords are derived mathematically using a time block, NTTP synchronization is critical.

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

Next Steps