Active Directory and Kerberos Integration

Microsoft Active Directory implements Kerberos 5 as its primary authentication protocol. Each Windows domain controller runs the KDC service, which includes both the Authentication Service and Ticket Granting Service. The domain name maps directly to the Kerberos realm name, and domain accounts correspond to Kerberos principals.

In an Active Directory domain, every domain controller can serve as a KDC, with replication ensuring consistent principal information across all DCs. The krbtgt account, whose password hash is the master secret for TGT encryption, exists in every domain. Its security is critical: compromise allows forging TGTs for any principal.

When a user sets their Active Directory password, Windows derives a Kerberos long-term key from the password using a key derivation function. This key is stored in the AD database alongside the NTLM hash. During Kerberos pre-authentication, the client demonstrates knowledge of this key without transmitting it.

NTLM (NT LAN Manager) is the legacy authentication protocol in Windows environments. Windows falls back to NTLM when Kerberos is not available, such as when accessing a resource by IP address instead of hostname, when the target is not domain-joined, or when a service principal name (SPN) is not registered correctly.

Service Principal Names (SPNs) are unique identifiers for service instances in Active Directory. Format: ServiceClass/FQDN:Port. For example, HTTP/webserver.corp.example.com:443. Kerberos uses the SPN to look up the correct service account key to encrypt the service ticket. Misconfigured or missing SPNs cause Kerberos to fall back to NTLM.

Windows uses SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) to negotiate between Kerberos and NTLM transparently. When a client connects to an IIS server, the server advertises SPNEGO support, the client attempts Kerberos first, and falls back to NTLM if Kerberos fails. This negotiation is invisible to users.

Kerberos behavior in Active Directory is configured via Group Policy in the Default Domain Policy. Settings include maximum ticket lifetime (default 10 hours), maximum TGT lifetime (default 7 days), maximum clock skew (default 5 minutes), and enforcement of pre-authentication. These settings apply domain-wide to all accounts.

PKINIT (Public Key Cryptography for Initial Authentication) is a Kerberos extension that allows using X.509 certificates (stored on smart cards or virtual smart cards) for AS-REQ pre-authentication instead of a password-derived key. The private key signs the AS-REQ, enabling hardware-backed passwordless Kerberos authentication.

MS-KKDCP (Microsoft Kerberos KDC Proxy Protocol) allows Kerberos authentication traffic to be tunneled over HTTPS, enabling domain-joined devices outside the corporate network to authenticate via Kerberos without a direct VPN connection to a domain controller. This is used in DirectAccess and some Azure AD scenarios.

Azure AD does not natively run Kerberos, but Azure AD Kerberos enables cloud-managed users to obtain Kerberos tickets for on-premises resources. Azure AD Connect Cloud Sync and Azure AD Kerberos service bridge the gap, allowing cloud-first organizations to maintain access to on-premises Kerberos-protected resources.

Kerberos armoring (FAST - Flexible Authentication Secure Tunneling) protects the pre-authentication exchange by tunneling it inside a TGT from a trusted machine account. This prevents offline dictionary attacks against the AS-REQ data, which is particularly important for accounts without pre-authentication requirements.

In Active Directory, what does the krbtgt account represent and why is its security critical?

Active Directory implements Kerberos 5 on domain controllers. User passwords derive Kerberos long-term keys stored in AD. SPNs map services to accounts for ticket encryption. NTLM is the fallback when Kerberos fails. PKINIT enables smart card authentication. The krbtgt account is the domain's root of trust: its compromise enables Golden Ticket forgery.