Understanding Kerberos Authentication in Active Directory
Kerberos is the default authentication protocol in Active Directory since Windows 2000, replacing the older and weaker NTLM challenge-response scheme for domain-joined clients and servers. It is a ticket-based system built around a trusted third party, the Key Distribution Center (KDC), which runs on every domain controller and issues time-limited, cryptographically signed tickets instead of transmitting passwords or password hashes across the network. Because tickets carry a short lifetime (10 hours by default for a Kerberos ticket-granting ticket, renewable for up to 7 days) and are bound to the requesting principal, replaying a captured ticket has a limited window of usefulness compared to replaying an NTLM hash.
Cricket analogy: Like an ICC match referee issuing a numbered match card to Virat Kohli before play instead of re-checking his passport every over, Kerberos issues a ticket once rather than re-sending the password like NTLM's repeated challenge-response.
The Kerberos Authentication Flow
Authentication begins when a client sends an AS-REQ (Authentication Service Request) to the KDC's Authentication Service, proving knowledge of its password by encrypting a timestamp with a key derived from it; the KDC responds with an AS-REP containing a Ticket-Granting Ticket (TGT) encrypted with the krbtgt account's secret key. The client then presents that TGT to the Ticket-Granting Service (TGS-REQ) whenever it needs to access a specific resource, such as a file share or SQL Server instance identified by a Service Principal Name (SPN), and receives back a service ticket (TGS-REP) that only the target server can decrypt. This two-step design means the user's actual password-derived key is used only once, during the initial AS exchange, minimizing its exposure on the wire.
Cricket analogy: Like a player first registering with the BCCI to get a central contract (the TGT) and then using that contract to get match-specific accreditation (the service ticket) for each IPL game.
Kerberos Tickets and Encryption
Every Kerberos ticket embeds a session key, timestamps, and a Privilege Attribute Certificate (PAC) that lists the user's group memberships and security identifiers so the target server can build an access token without an extra round trip to a domain controller. Modern domains should be configured to use AES256-CTS-HMAC-SHA1-96 for ticket encryption rather than the legacy RC4-HMAC (equivalent to NTLM's hash), which is still enabled by default in many environments and is a favorite target for offline cracking once a ticket is captured. Administrators can inspect a machine's current ticket cache with the klist command, and can force a specific encryption type on a service account using the msDS-SupportedEncryptionTypes attribute.
Cricket analogy: Like the DRS system encoding ball-tracking data with a specific, modern algorithm rather than the outdated manual third-umpire guesswork used decades ago, choosing AES256 over legacy RC4 matters just as much for security.
# View cached Kerberos tickets on the current machine
klist
# Check for duplicate or missing SPNs for a service account
setspn -L svc-sql01
setspn -X
# Force AES-only Kerberos encryption on a service account
Set-ADUser svc-sql01 -KerberosEncryptionType AES256Domain controllers are the authoritative time source for a domain. By default, the Kerberos maximum tolerance for computer clock synchronization (MaxClockSkew) is 5 minutes; anything beyond that is rejected outright with KRB_AP_ERR_SKEW, even if the credentials are perfectly valid.
Common Kerberos Failures
Because Kerberos ticket validity depends on synchronized clocks, a time skew beyond the default five-minute tolerance between a client and the KDC produces a KRB_AP_ERR_SKEW error and blocks authentication entirely, which is why domain controllers are the authoritative time source for a Windows domain via the Win32Time hierarchy. Another classic failure mode is the 'double-hop problem,' where a user authenticates to a front-end server that then needs to pass those same credentials to a back-end resource on the user's behalf; without delegation configured (constrained or resource-based constrained delegation), the second hop silently falls back to NTLM or fails. Duplicate or stale Service Principal Names registered on the wrong account also cause KDC_ERR_S_PRINCIPAL_UNKNOWN or ambiguous SPN errors that block clients from requesting a service ticket at all.
Cricket analogy: Like the third umpire's replay clock being out of sync with the field umpire's watch, causing a run-out decision to be rejected on a technicality even though the play itself was fine.
The krbtgt account's password hash encrypts every TGT issued in the domain. If an attacker with Domain Admin (or higher) access extracts it — often via a DCSync attack — they can forge arbitrary 'golden tickets' that impersonate any user, including Enterprise Admins, until the krbtgt password is rotated twice.
- Kerberos replaces NTLM's password-hash exchange with short-lived, signed tickets issued by the KDC running on every domain controller.
- Authentication is two-stage: an AS exchange yields a TGT, then a TGS exchange trades that TGT for a service-specific ticket.
- Tickets embed a PAC with group membership data so servers can build access tokens without contacting a domain controller again.
- Always prefer AES256-CTS-HMAC-SHA1-96 over legacy RC4-HMAC encryption for ticket protection.
- Clock skew beyond the default 5-minute tolerance causes authentication to fail outright with KRB_AP_ERR_SKEW.
- The double-hop problem requires explicit delegation configuration; without it, credentials can't be forwarded to a second-hop resource.
- The krbtgt account's key underlies every ticket in the domain and must be rotated (twice) after any suspected compromise.
Practice what you learned
1. What does a client receive after a successful AS-REQ/AS-REP exchange with the KDC?
2. Which encryption type should be preferred over legacy RC4-HMAC for Kerberos tickets?
3. What error occurs when a client's clock differs from the KDC's by more than the default tolerance?
4. What information does a ticket's Privilege Attribute Certificate (PAC) contain?
5. What is required to solve the Kerberos 'double-hop problem'?
Was this page helpful?
You May Also Like
Fine-Grained Password Policies
How Password Settings Objects (PSOs) let administrators apply different password and lockout rules to different groups of users within a single Active Directory domain.
Securing Privileged Accounts (Tiered Admin Model)
How Microsoft's tiered administration model, Privileged Access Workstations, and LAPS together prevent a single compromised low-trust machine from escalating into full domain compromise.
AD FS and Federation Basics
How Active Directory Federation Services issues claims-based security tokens to enable single sign-on with partner organizations and claims-aware applications.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics