Kerberos Authentication: How It Works and How to Secure It

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 11 November 2026.

Part of the Wolfcore Resources library: Ports, protocols and services.

In one sentence: Kerberos is the system a Windows network uses to prove who you are without sending your password around, by giving you short-lived digital passes (tickets) that servers accept.

What it is

Kerberos is the main sign-in protocol in Active Directory, the directory that holds a Windows business network’s accounts. Microsoft says Windows Server implements the industry-standard Kerberos version 5 defined by the IETF, so the same ideas apply on other systems that use it.

Three parties are involved: the client acting for a user or computer, the service the user wants, and the Key Distribution Center (KDC) that both trust. On Windows, the KDC runs on every domain controller and uses the Active Directory database.

Microsoft contrasts it with the older NTLM protocol: NTLM does not let a client verify a server’s identity, while Kerberos makes no assumption that servers are genuine. That is called mutual authentication. See ntlm-authentication for the older protocol. The network port is covered in port-88-kerberos.

How it works

Sign in. When a user signs in, the client contacts the KDC to prove who they are and gets a ticket-granting ticket (TGT). The TGT lets the client ask for services without presenting the password again, and it is cached until it expires.
Ask for a service ticket. To use a file share or database, the client shows its TGT to the KDC and asks for a ticket for that specific service. Each service is identified by a service principal name (SPN) tied to a service account.
Present the ticket. The client gives the service ticket to the service. The service can authenticate the client without contacting a domain controller for each connection.

Two practical rules follow. Clocks must agree: Microsoft says the time difference between the domain controller and the client or server must be under five minutes. And names matter: a missing or duplicated SPN makes Kerberos fail, which is when Windows quietly falls back to NTLM.

Kerberos can also pass a user’s identity from a front-end service to a back-end one, called delegation. Microsoft lists three kinds and says unconstrained delegation is not recommended because it does not restrict which services the account can use.

Who it affects and how badly

Sole trader to 10 staff: usually cloud-only, so Kerberos is not in daily play.
10 to 50 staff (accountancy, legal, construction, charities with a server): the worst case is a weak service account that opens the server, causing days of downtime.
50 to 250 and 250 plus (schools, councils, manufacturers, care providers, retail groups): domain-wide compromise, ransomware and lost client work. In the UK, EU, US and Armenia, regulated firms also face reporting duties, with the data affected deciding the regime.

Real examples

MITRE records Kerberoasting (taking service tickets and cracking them offline) as used in the SolarWinds compromise and by ransomware-linked groups such as Wizard Spider, among others. Microsoft changed Windows defaults in response to CVE-2022-37966 so accounts without an explicit setting use AES instead of RC4.

How it is attacked

The common weakness is not Kerberos itself but how it is configured. In Kerberoasting, any domain user can request a ticket for any SPN, and if it is encrypted with RC4 the service account’s password can be attacked offline. Short, old service account passwords fail first. Stolen tickets, over-privileged service accounts and unconstrained delegation turn one foothold into wide access. This page does not give attack steps, only the mechanism.

Worked example for a small business (illustration only)

An invented example, not a real client. A 40-person manufacturer’s ERP system runs under a service account with a six-year-old password and domain admin rights, because the vendor’s guide said so. A compromised workstation asks for its ticket, the password is cracked offline and the attacker owns the domain within hours. The cost is production halted, a rebuild and possible customer penalties. The fix is a managed service account, AES only, least privilege and alerts.

What we check on a test

Which accounts have SPNs, how old their passwords are and what groups they belong to.
Which encryption types the domain allows and whether RC4 tickets are still issued.
Whether delegation is configured, and whether it is unconstrained.
Whether admin accounts are separate from day-to-day accounts and where they sign in.
Whether ticket request patterns would be noticed in your logs.

The UK angle

The NCSC’s identity and access guidance says to use a tiered model for admin accounts, give admins separate accounts for email and browsing, and log and monitor authentication events. Cyber Essentials v3.3 requires separate accounts for administrative activities only. Both limit what a stolen Kerberos ticket can reach.

How to detect it

Turn on Kerberos service ticket auditing and review Security events 4768 (TGT) and 4769 (service ticket). MITRE’s detection strategy looks for many ticket requests from one account in a short period, and RC4 (type 0x17) in event 4769.
Use klist on a client to see which tickets it holds. If you expected Kerberos and there is no ticket, something fell back.
Use Microsoft’s open-source scripts to audit RC4 use, as described in the RC4 guidance.
Send domain controller logs to a SIEM so a person or service reads them.

How to prevent it

Use long random passwords for service accounts. MITRE suggests 25 or more characters, or group managed service accounts.
Allow AES and remove RC4 via the group policy “Network security: Configure encryption types allowed for Kerberos”.
Give service accounts the least privilege they need, never Domain Admin.
Avoid unconstrained delegation.
Keep domain controller and client clocks in sync.
Fix missing and duplicate SPNs so Windows does not fall back to NTLM.
Patch domain controllers first and keep them off the internet.

Frequently asked questions

Does Kerberos make me type my password for every server? No. Microsoft says the ticket-granting ticket lets the client request services without presenting the password again.

Why does Kerberos need the clocks to match? Tickets carry timestamps, and Microsoft says the difference between the domain controller and the client or server must be under five minutes.

What is Kerberoasting? It is an attack on service account passwords using service tickets that can be attacked offline, which is why service account passwords must be long.

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan.

Kerberos authentication: how it works, how it is attacked and how to secure it