How does Kerberos authentication work?

Kerberos is a network authentication protocol that proves who a user or service is by using tickets issued by a trusted key server, so passwords never cross the network. A client gets a ticket-granting ticket once, then trades it for a ticket to each service it wants to use. RFC 4120 defines version 5.

What problem does it solve?

RFC 4120 says Kerberos verifies the identities of principals, such as a workstation user or a network server, on an open, unprotected network. It does this without relying on the host operating system's word, without trusting host addresses, without requiring that every host be physically secure, and on the assumption that packets can be read, modified and inserted at will. It uses a trusted third party and shared secret key cryptography.

What happens when you log in and open a share?

The core flow has three actors: the client, a service, and the key distribution center, which runs an authentication server (AS) and a ticket-granting server (TGS).

1. AS exchange. The client asks the AS for credentials. The AS replies with a ticket-granting ticket (TGT) and a temporary session key, encrypted in the client's key. Only someone who knows the user's secret can open the reply.
2. TGS exchange. The client sends the TGT to the TGS and asks for a ticket to a named service. The reply is encrypted in the session key from the TGT.
3. Service request. The client sends the service ticket to the service. The ticket holds the client's identity and a copy of a session key, all encrypted in the service's key. The service decrypts it and now trusts the identity.

Constructed example: Priya signs in at 09:00. Her laptop gets one TGT. At 09:05 she opens a file share, and at 09:20 an internal wiki. Each of those uses a separate service ticket, but she typed her password once.

Why do clocks matter?

Kerberos relies on timestamps to stop replayed messages. RFC 4120 says the degree of looseness is set per server but is typically on the order of five minutes, and that if clocks are synchronized over a network, that synchronization protocol must itself be secured. A machine with a wrong clock fails to authenticate, which is why many Kerberos outages look like mysterious login failures.

What does it not cover?

The RFC is careful here. Many applications use Kerberos only when starting a stream connection. Unless the application also encrypts or integrity-protects the stream, identity verification applies only to the start of the connection and does not prove that later messages came from the same principal.

Where do attackers go after Kerberos?

Tickets are valuable, so MITRE ATT&CK lists a family of techniques under Steal or Forge Kerberos Tickets (T1558). One is Kerberoasting (T1558.003). A user who holds a valid TGT can request service tickets for service principal names from the domain controller. Part of such a ticket may be encrypted in a way that can be attacked offline, since its key comes from the password of the service account. Weak service account passwords fall quickly.

MITRE's mitigations are practical: enable AES Kerberos encryption instead of RC4 where possible, use long and complex service account passwords (ideally 25 or more characters) that expire, consider group managed service accounts or a vault, and limit service accounts to the minimum privileges, keeping them out of groups such as Domain Admins. Detection looks for unusual service ticket requests with RC4 encryption.

How to check or apply this

1. List service accounts that have service principal names, and who owns each.
2. Check password length and age on those accounts. Replace weak ones, or move to managed accounts that rotate automatically.
3. Prefer AES for ticket encryption and find out which systems still need RC4.
4. Remove service accounts from privileged groups unless there is a documented reason.
5. Monitor service ticket requests and alert on bursts, odd accounts or RC4 use.
6. Keep time sources reliable and secured, and alert on clock drift.
7. Protect the key distribution center like your most sensitive system, because it is.

Quick check

Sources

• RFC 4120, The Kerberos Network Authentication Service (V5)
• MITRE ATT&CK: Steal or Forge Kerberos Tickets, T1558
• MITRE ATT&CK: Kerberoasting, T1558.003

Last reviewed: 18 October 2026.