luisgonzales.net

How to Troubleshoot Authentication Issues Like a Pro

Kerberos is like the nervous system of Windows authentication—when it breaks, the whole enterprise feels it. But troubleshooting Kerberos can feel like unraveling a mystery wrapped in base64 tickets and obscure event logs.

If you’ve ever faced vague “access denied” errors, SPN mismatches, or double-hop headaches, this one’s for you.

A Quick Refresher: How Kerberos Works

1. Client requests a Ticket Granting Ticket (TGT) from the KDC (typically a domain controller).
2. Client requests a service ticket for a specific SPN (service principal name).
3. Client presents the service ticket to the server hosting the service.
4. Server validates it—access granted (or not).

Step-by-Step Kerberos Troubleshooting

1. Check the System Time (Yes… Seriously)

Kerberos is very sensitive to time drift. A skew of more than 5 minutes can cause ticket failures, so Ensure:

• Domain controllers and clients are synced with the same NTP source.
• Use w32tm /query /status to check sync status.

2. Verify SPNs Are Set Correctly

SPNs (Service Principal Names) map services to service accounts. If they’re missing or duplicated, Kerberos breaks.

Run:

setspn -Q */servername

Look for:

• Missing SPNs for services like HTTP, MSSQLSvc, CIFS.
• Duplicate SPNs (Kerberos hates ambiguity).

 Create the service account, if it doesn’t exist (I’ve had this happen with an application team)

setspn -A HTTP/server.domain.com domain\svc-account

Check Event Logs

• On the client: Look under System and Security logs for Kerberos errors (Event ID 4771, 4768, 4624).
• On the server: Look for failed authentication attempts or missing SPNs.

If needed, enable verbose Kerberos logging (registry tweak) for deeper insight.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

"LogLevel"=dword:00000001

Use klist to View and Purge Tickets

Kerberos, tickets can become stale, especially after changes to SPNs or service accounts.

Run:

klist

To purge and refresh:

klist purge

Then re-authenticate by accessing the service again. If needed here a list of klist commands: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist

Look for Double-Hop Problems

The classic "double-hop" issue arises when a server needs to access a second resource as the user. Kerberos doesn't allow this unless:

• You use Kerberos constrained delegation.
• The service is configured incorrectly.
• The user is using, NTLM not Kerberos

Check authentication protocols in logs or use tools like Network Monitor or Wireshark to see Kerberos or is it NTLM.

If the server is using delegation

• Use Active Directory Users and Computers (ADUC) > right-click the service account > Delegation tab.
• Ensure it's set to:
• "Trust this user for delegation to specified services only"
• Use Kerberos only (for security)

Here are some Tools that make troubleshooting Kerberos easier

• setspn.exe – SPN management
• klist – Ticket viewer/purger
• Kerberos Configuration Manager (KCM) – Microsoft’s GUI tool for SPNs
• Sysinternals Procmon – Catch access issues in real time
• Network Monitor/Wireshark – Sniff out protocol-level details

Pro Tips

• Always test changes in a staging environment first.
• Be explicit with SPNs; ambiguity = trouble.
• Don’t forget group policy refresh after changes: gpupdate /force.
• Document SPN ownership and naming conventions for your organization

Wrapping Up

Kerberos is powerful, fast, and secure—but also finicky. Most issues boil down to SPN misconfigurations, stale tickets, or double-hop challenges. With the right tools and a methodical approach, you can demystify Kerberos and keep authentication flowing smoothly.