How Kerberos works
Kerberos revolves around a trusted third party called the Key Distribution Center (KDC), which in Active Directory environments lives on every domain controller. When a user logs in, the client proves knowledge of the password cryptographically and receives a ticket-granting ticket (TGT), a time-limited credential encrypted so only the KDC can read it. The password itself never crosses the network.
To reach a service such as a file share or an intranet site, the client presents its TGT to the KDC and requests a service ticket for that specific service. The service ticket is encrypted with a key derived from the service account's secret, so the service can decrypt it and trust the identity inside without contacting the KDC. Tickets carry timestamps and lifetimes, which is why Kerberos requires clocks to be synchronized, and mutual authentication lets the client verify the service too.
Why Kerberos matters
Kerberos is the authentication engine of the Windows domain and the reason domain-joined machines deliver seamless single sign-on: a user logs into their PC once and reaches file servers, printers, intranet applications, and SQL Server instances without another prompt. This browser-and-desktop experience, surfaced as Integrated Windows Authentication (IWA), predates web SSO by decades and still covers an enormous installed base, including Linux systems joined to AD.
Its design is also a double-edged sword worth understanding. Because service tickets are encrypted with keys derived from service account passwords, weak passwords enable the Kerberoasting attack, where any domain user requests tickets and cracks them offline. Compromise of the KDC's krbtgt account enables Golden Ticket forgery, granting an attacker arbitrary identities until the key is rotated twice. Defending Kerberos means long random service account passwords, modern encryption types, and monitoring for anomalous ticket activity.
Kerberos in practice
Inside the domain, Kerberos mostly just works once SPNs (service principal names) are registered correctly and clocks are in sync; misconfigured SPNs and silent fallbacks to the weaker NTLM protocol are the classic troubleshooting culprits. Auditing where NTLM is still used and eliminating it is a common hardening project.
The strategic question is how Kerberos coexists with modern identity. Cloud applications do not speak it, so organizations bridge the two worlds: the desktop Kerberos session becomes the first factor for a federation platform, which then issues SAML or OIDC tokens for everything else. Monosign supports Kerberos-based integrated Windows authentication as part of exactly this bridge, letting domain-joined users flow into modern SSO without retyping credentials.