How to Troubleshoot Kerberos Authentication

Authentication failures involving Kerberos in Active Directory (AD) environments rarely stem from protocol bugs—they almost always trace to core infrastructure issues. This guide clarifies how to diagnose and resolve Kerberos authentication problems by mapping specific symptoms and error codes to underlying causes, guiding you through investigative steps that consistently surface and solve real issues in AD deployments.

Link to 1. How Kerberos Authentication Works in Active Directory1. How Kerberos Authentication Works in Active Directory

Kerberos, the default authentication protocol for Active Directory, is a multi-stage process that requires precise coordination between clients, servers, and domain controllers (KDCs). The main flow is:

Link to Stages of Kerberos AuthenticationStages of Kerberos Authentication

AS Exchange (Authentication Service): The client requests a Ticket Granting Ticket (TGT) from the KDC using its credentials. The KDC validates the request and issues a TGT if successful.
TGS Exchange (Ticket Granting Service): The client presents the TGT to the KDC, requesting a service ticket for a specific resource (identified by an SPN).
AP Exchange (Application Protocol): The client sends the service ticket to the target application server to access the resource.

Link to Critical DependenciesCritical Dependencies

Kerberos relies heavily on the following:

Time Synchronization: The system clocks of clients, servers, and KDCs must be closely aligned (maximum drift, by default, is 5 minutes).
DNS Resolution: Every participant relies on DNS to resolve domain controller and service hostnames.
SPN Configuration: Each service must be assigned a unique Service Principal Name (SPN) in Active Directory. SPN mismatches or duplicates disrupt ticket issuance.

If any of these foundations are misaligned, Kerberos authentication fails, often in ways that are subtle or misattributed to application bugs.

Link to 2. Recognizing and Categorizing Kerberos Failures2. Recognizing and Categorizing Kerberos Failures

Identifying a Kerberos authentication problem early is essential, as symptoms can overlap with other protocol failures.

Link to Common SymptomsCommon Symptoms

Event Log Errors: Event IDs 4768 (TGT issues), 4771 (pre-authentication), 4776 (NTLM fallback), or System events such as 4 (Kerberos).
Application Failures: Unexpected user logins prompts, HTTP 401/400 errors, or "KRB_AP_ERR_MODIFIED" messages.
NTLM Fallback: In many Windows environments, if Kerberos fails, authentication silently reverts to NTLM—confirm this with event logs.

Link to Distinguishing Kerberos from NTLM FailuresDistinguishing Kerberos from NTLM Failures

Kerberos failures produce identifiable log entries and error codes.
NTLM-only events (such as 4776 in the Security log) or successful authentication despite Kerberos errors often indicate fallback.
True Kerberos failures may be silent if fallback is permitted, leading to less secure authentication.

Link to 3. Essential First Checks: Time, DNS, SPN, and Ticket Cache3. Essential First Checks: Time, DNS, SPN, and Ticket Cache

Most Kerberos issues arise from deviations in these four areas. These are the first and most decisive checks.

Link to Time SynchronizationTime Synchronization

Kerberos is highly sensitive to time skew. If clocks are out of sync (default: more than 5 minutes), ticket issuance and validation fail, often with errors like "KRB_AP_ERR_SKEW" (Event ID 4).

Resolution: Validate time on clients, servers, and domain controllers. Use Windows time synchronization mechanisms to realign clocks.

Link to DNS and SPN ConfigurationDNS and SPN Configuration

DNS: Kerberos depends on DNS to resolve domain controllers and service addresses. Any ambiguity or incorrect resolution disrupts ticket requests.
SPN: Each service that uses Kerberos requires an SPN registered to the right Active Directory object—duplicates or missing SPNs cause authentication errors.
Resolution: Confirm that DNS resolves all necessary names and that SPNs are registered uniquely and correctly.

Link to Ticket Cache InspectionTicket Cache Inspection

Kerberos clients cache tickets. Old or invalid tickets can sabotage authentication.

Tool: The klist command displays the current ticket cache and enables purging tickets (klist purge) to force re-authentication and ticket renewal.

Link to 4. Diagnosing Using Logs and Error Codes4. Diagnosing Using Logs and Error Codes

Logs and error codes are the best guides to Kerberos failures. Key event logs and codes provide actionable insights.

Link to Key Windows Event IDsKey Windows Event IDs

Event ID	Meaning	Typical Use
4768	TGT (AS exchange) issued/failed	Starting point for failures
4771	Pre-authentication failure	Identify invalid credentials
4	Kerberos errors (AP exchange)	SPN/time/DNS issues

Link to Interpreting Common Error CodesInterpreting Common Error Codes

Error Code	What It Means	Underlying Cause
KRB_AP_ERR_MODIFIED	Ticket does not match service	SPN duplicate/wrong object
KRB_AP_ERR_SKEW	Time skew too great	System clocks not aligned
KDC_ERR_S_PRINCIPAL_UNKNOWN	SPN not found	Service not registered in AD
KDC_ERR_PREAUTH_FAILED	Bad password or clock skew	User/password/time mismatch
KDC_ERR_ETYPE_NOTSUPP	Encryption type mismatch	Config/compatibility issues

Examining these codes in conjunction with system and security logs enables you to rapidly converge on the root problem.

Link to 5. Troubleshooting Flow: Step-by-Step Guide5. Troubleshooting Flow: Step-by-Step Guide

A systematic approach shortens investigation and remediation time.

Link to Step 1: Reproduce and ObserveStep 1: Reproduce and Observe

Attempt the failing authentication.
Immediately examine system and security event logs for Kerberos-related events (start with events 4768, 4771, 4).

Link to Step 2: Correlate Error CodesStep 2: Correlate Error Codes

Use the error code (e.g., KRB_AP_ERR_MODIFIED) to narrow the probable cause (SPN, time, DNS).
Check whether the error occurs during TGT acquisition, service ticket issuance, or service access.

Link to Step 3: Check Time SynchronizationStep 3: Check Time Synchronization

Confirm that all participating systems are within 5 minutes of each other.

Link to Step 4: Validate DNSStep 4: Validate DNS

Ensure all system DNS records are correct and resolve as expected.

Link to Step 5: Inspect SPN RegistrationStep 5: Inspect SPN Registration

Validate that the service's SPN is registered exactly once and to the correct object.

Link to Step 6: Examine and Reset Kerberos Ticket CacheStep 6: Examine and Reset Kerberos Ticket Cache

Use klist to inspect tickets.
If in doubt, purge the cache to force new ticket issuance, then retest.

Link to Step 7: Consider MaxTokenSizeStep 7: Consider MaxTokenSize

If authentication fails for users with large group memberships (symptoms like HTTP 400 or incomplete group SID listings), investigate MaxTokenSize and adjust if required.

Link to Example Scenario: SPN ConflictExample Scenario: SPN Conflict

Error: KRB_AP_ERR_MODIFIED when accessing a service.
Steps: Find duplicate/conflicting SPNs; correct registration so only the target service account holds the relevant SPN; purge tickets; retest.

Link to 6. Special Topics: MaxTokenSize, Misconceptions, and NTLM Fallback6. Special Topics: MaxTokenSize, Misconceptions, and NTLM Fallback

Link to MaxTokenSize and Group MembershipMaxTokenSize and Group Membership

Windows builds an authentication token containing user and group SIDs. If the token exceeds MaxTokenSize (commonly due to large group membership), authentication fails. Watch for this in users in many groups.

Symptom: HTTP 400 errors or incomplete group membership on login.

Link to Addressing Common MisconceptionsAddressing Common Misconceptions

Kerberos always falls back to NTLM: Not guaranteed—depends on domain and policy settings.
SPN uniqueness only matters with delegation: False—conflicts break Kerberos regardless of delegation.
Most Kerberos errors are protocol bugs: Most are environmental or infrastructural.
Ticket cache problems require reboot: Not always; use klist to inspect and purge instead.
Time skew is harmless within a few minutes: Even small drifts beyond configured skew (usually 5 minutes) break authentication.

Link to 7. Summary and Next Steps7. Summary and Next Steps

Kerberos authentication troubleshooting is a matter of mapping observed failures to root causes within foundational infrastructure—system time, DNS, SPN uniqueness, and ticket health explain the vast majority of failures. Effective use of event logs, direct inspection of ticket caches, and precise interpretation of error codes enable reliable diagnosis and remediation.

For in-depth guidance, further reading, and advanced diagnostic tools, consult:

RFC 4120 for protocol details
Microsoft’s Kerberos authentication troubleshooting and service principal name documentation
Detailed error code explanations in Windows event log references
The official documentation for klist and MaxTokenSize considerations

Stay systematic, rely on evidence from event logs and diagnostic tools, and address infrastructure before delving into more complex protocol-level analysis.

Sources

RFC 4120: The Kerberos Network Authentication Service (V5)
Kerberos Authentication Troubleshooting Guidance - Windows Server
Service principal names - Win32 apps
klist (Windows commands)
Kerberos authentication problems - Windows Server (MaxTokenSize)
Kerberos Network Authentication Service (V5) Synopsis (MS-KILE)
Windows Event 4768 documentation