Kerberos authentication is a ticket-based authentication protocol used by companies to let users prove their identity to a service. Sometimes called a computer network authentication protocol, Kerberos relies on a trusted third party—the key distribution center (KDC)—to issue time-limited, encrypted tickets that verify a user’s identity. This approach is convenient and secure for the user. Once authenticated, Kerberos enables single sign-on (SSO), allowing the user to access multiple services without entering their password again.
Key takeaways
- Kerberos is a ticket-based authentication protocol—it proves identity over an insecure network without ever sending the password across it.
- It runs on a trusted third party called the Key Distribution Center (KDC), made up of an authentication server, a ticket-granting server, and a database of users and services.
- Kerberos authentication uses symmetric key cryptography and short-lived, time-stamped Kerberos tickets, which is what makes single sign-on work and replay attacks hard to achieve.
- Kerberos authentication protocol is the default authentication in Microsoft Active Directory, and MongoDB Enterprise supports it so people can reach the database with their existing corporate login.
Table of contents
- Why was Kerberos created?
- What is the Key Distribution Center (KDC) in Kerberos authentication?
- How do you get your secret key in Kerberos?
- How does kerberos work in a typical workplace?
- What are the benefits of Kerberos?
- What are the challenges and weaknesses of Kerberos?
- What are the security risks of Kerberos?
- How does Kerberos compare to other authentication protocols?
- Does MongoDB support Kerberos authentication?
- Secure your database with Kerberos
- FAQs
- Related resources
Why was Kerberos created?
Kerberos was created to solve a single problem: how to prove who you are over a network without sending your password across it. For many services, authentication still requires a password. You type it in, the system checks it, and you’re allowed into the application. The problem with a password is that it can be intercepted by hackers when it travels across a network. And once they have your password, they can sign in as you and do whatever you can do. Kerberos was built to solve this vulnerability. It proves who you are over a network without sending your password across it.
The protocol came out of MIT in the late 1980s, built for a campus computing project called Project Athena. The name comes from Cerberus, the three-headed dog of Greek myth that guarded the gates of the underworld—a nod to the three parties in every Kerberos exchange: the client, the service, and the trusted go-between (the KDC).
The client can be a person logging in or a device or application acting on its own. The service can be a file share, an email server, a printer—or a database. When the service is your MongoDB deployment, Kerberos is what lets someone reach it with their corporate credentials instead of a separate database password.
What is the Key Distribution Center (KDC) in Kerberos authentication?
The Key Distribution Center (KDC) is the trusted go-between for you and the service you’re trying to reach. Its job is to authenticate users and verify user identities before any service is reached.
The KDC consists of three parts:
- Authentication server (AS): Handles client authentication during login and issues a ticket-granting ticket (TGT).
- Ticket-granting server (TGS): Issues tickets for specific services after you’ve authenticated. This is also called the ticket-granting service.
- KDC database: Holds a record for every registered user and service. Each of these—a person, or a service like a database—is called a principal in Kerberos, and every principal has its own secret key. Because it stores multiple secret keys, one for each principal, the KDC database is what the rest of the system depends on.
One thing to remember: the KDC is the trusted center, but nothing it issues lasts forever.
How do you get your secret key in Kerberos?
When your account is created, Kerberos stores information derived from your password—but not the password itself—in the KDC database. Later, each time you log in, your device recreates the same secret key from the password you type, and it matches what the KDC already has on file.
This secret key is a symmetric key: the same key encrypts and decrypts. Because your device and the KDC each hold it independently, neither one ever has to send it across the network—which is how Kerberos keeps passwords from being transmitted.
That shared secret key is the foundation of Kerberos. Because your device and the KDC both know it, the KDC can verify you and issue tickets to applications, servers, and other resources—using tickets in place of your password from that point forward.
How does Kerberos authentication work in a typical workplace?
The best way to understand how Kerberos authentication works is to see it in action. Let's follow Alexi, a project manager, as he starts his day.
Alexi logs into his work laptop at 8 a.m. Over the next hour, he opens his email, pulls a file off the shared drive, and jumps into the project app his team uses—and not once does he stop to type in his password again. As far as Alexi knows, signing in once gets him into all of the tools he uses—and that’s exactly what happened.
Let’s replay that morning in slow motion. Behind Alexi’s morning routine, Kerberos is exchanging Kerberos tickets on his behalf, so each system lets him in without making him prove who he is all over again.
A few terms before we go under the hood:
- AS (authentication server): Verifies the user’s identity and issues the TGT.
- TGS (ticket-granting server): Exchanges the TGT for service tickets.
- TGT (ticket-granting ticket): Proof that the user has already authenticated.
- Session key: A temporary shared secret used for secure communication.
- Service ticket: A ticket that grants access to a specific service.
The steps below show what’s happening underneath—the part Alexi never sees during the Kerberos authentication process.
Step #1: Alexi signs in
He enters his username and password. His password never leaves his laptop—only his username goes to the authentication server (AS), part of the KDC. (In a Microsoft Windows environment, a domain controller plays this role.)
The AS looks up Alexi’s account and sends back two encrypted items:
- A session key, for secure communication with the TGS.
- A ticket-granting ticket (TGT), proof that he’s logged in. The TGT can also include his client network address, which helps tie the ticket to his machine.
Alexi’s computer decrypts the session key using the secret key it derives from his password—the same key the KDC used to encrypt it. The TGT stays sealed, since it's encrypted for the TGS, and his laptop holds onto it for the next step.
Step #2: Alexi’s computer trades the TGT for a service ticket
When Alexi clicks the project app, his laptop sends the sealed TGT to the ticket-granting server (TGS) along with a request for that specific app. No password this time—the TGT does the authentication.
The TGS opens the TGT with its own key—the one it was sealed with in Step #1, which is why only the TGS can read it. Inside, it finds the session key, the same one Alexi’s laptop recovered a moment ago. Now both sides hold that key, so the TGS can confirm the requested service really comes from him. It issues a service ticket for the app.
Step #3: Alexi reaches the app
His laptop presents the service ticket to the project app, which opens it with the service’s secret key and confirms it’s valid. The authentication check runs both ways: the app proves itself back to his laptop, too—confirming it’s the real thing and not an imposter. The app lets him in, instantly, with no password. From Alexi's seat, he just clicked and it opened. Underneath, three tickets changed hands to make that one click safe—for both Alexi and the app.
Alexi's morning shows why Kerberos is worth the setup. His password never crossed the network—only Kerberos tickets did, so there was nothing in transit for someone to steal. It’s also effortless: because his laptop held the first TGT, it could reach the shared drive, the project app, and everything else without signing in again. That’s single sign-on (SSO)—authenticate once, and every Kerberos-enabled tool opens without another login.
What are the benefits of Kerberos?
Kerberos’s main benefits include single sign-on, passwords that never cross the network, and mutual authentication between users and services. Alexi’s morning showed the first two already—no password traveling through the network, and one sign-in for the whole day. Below is a more detailed and fuller list of why the Kerberos protocol has been used for decades.
Single sign-on: Lets users authenticate once and reach every service they’re cleared for, without repeating logins. This offers better security and less password fatigue—fewer passwords to remember means fewer to lose track of or get stolen.
Passwords stay off the network: A password is never transmitted. The secret key derived from it never leaves the user’s machine—and the Kerberos tickets that travel in its place are encrypted, so there's nothing on the wire worth intercepting.
Mutual authentication: Both sides verify each other—the user proves themselves to the service, and the service proves itself back. That’s what stopped imposters in Alexi’s last step and why it stops man-in-the-middle attacks, where someone slips between two parties and poses as one of them.
Reusable tickets: Each ticket stays valid for a set lifetime, so once a user is verified, their computer reuses the same ticket instead of returning to the KDC for a new one every time.
Wide support: Kerberos is an open standard built into Windows, Linux, and macOS, and supported across a broad range of services, including enterprise databases. Many Unix-like operating systems—including FreeBSD and Red Hat Enterprise Linux—also include software for Kerberos authentication of users or services. Because it works the same way everywhere, a large organization can rely on it alone instead of running several different authentication systems.
What are the challenges and weaknesses of Kerberos?
Kerberos's main challenges and weaknesses are its reliance on a single KDC, strict clock synchronization, per-service key management, complex setup, and the manual work of connecting realms. Some are design trade-offs; others are simply the upkeep of running it well.
The KDC is a single point of failure: All authentication routes through the KDC, so everything depends on it. If it goes down, authentication stops across the whole network—no one can get a ticket. And if an attacker breaks in, they can issue valid tickets for anyone, including themselves. Most organizations run more than one KDC so a single outage or breach can't take everything down.
Clocks have to stay in sync: Kerberos checks the time on every ticket, so all machines must stay within about five minutes of each other. If one clock doesn’t match, user logins start to fail.
Every participant needs its own key: Each client and service must be registered with the KDC and given its own key. In clusters or virtual hosting, where one machine runs under several names, each needs its own Kerberos key—and every key is one more thing to create, protect, and rotate.
Setup isn't simple: It takes work to keep Kerberos running. IT teams have to register services, manage keys, and maintain the KDC. For a small team, that's a big job.
Cross-realm trust takes extra work: Each Kerberos realm has its own KDC. Connecting two realms so users under one KDC can reach services under another has to be configured by hand.
What are the security risks of Kerberos?
Kerberos is strong, but no protocol is bulletproof. Most Kerberos attacks go after its tickets or the KDC rather than trying to crack the encryption. Below are some common security vulnerabilities:
Pass-the-Ticket: A hacker can get inside a system and steal a ticket to impersonate a user—no password theft needed because Kerberos trusts the ticket.
Golden Ticket: If an attacker gets the key that signs all tickets—the KDC’s realm key—they can forge ticket-granting tickets at will, giving themselves access as anyone. It’s the worst case scenario, because a forged TGT is impossible to tell from a real one.
Silver Ticket: This is a smaller-scale version of the Golden Ticket. With one service's secret key, the attacker forges tickets for that single service—and because it never touches the KDC, it's harder to detect.
Password guessing: Hackers can go after the user’s initial password with password guessing—so a weak password is still a liability. They use techniques like brute-force, which tries every possible combination until one works, and dictionary attacks, which run through lists of common passwords—both aim to crack the password and grab the user’s first ticket.
Skeleton key malware: This is malware that infects the KDC and plants a master password that works for any account, letting an attacker log in as anyone. Everyone's real passwords keep working too, so nothing looks wrong. It only works if the attacker already controls the KDC, so it's a way to keep access after a breach—not a way in.
None of this makes Kerberos obsolete. Strong encryption and short ticket lifetimes keep it effective, and most modern single sign-on still runs Kerberos underneath.
How does Kerberos compare to other authentication protocols?
Kerberos authenticates—it proves who you are. The protocols it's most often mentioned alongside do different jobs: one's a legacy method Kerberos replaced, one stores identity, one handles authorization. Here's how they line up.
The protocols:
- NTLM (NT LAN Manager): Microsoft's older authentication protocol, replaced by Kerberos as the Windows default.
- LDAP (Lightweight Directory Access Protocol): A directory that stores and organizes identity information; often paired with Kerberos.
- OAuth (Open Authorization): An authorization standard that lets an app act on your behalf without sharing your password.
Does MongoDB support Kerberos authentication?
Yes, MongoDB Enterprise supports Kerberos authentication. A database is just another service Kerberos can protect, so a user reaches the database using the same corporate login that gets them into their email and file shares—no separate database password to create, rotate, or lose. Each MongoDB server registers with Kerberos as its own service principal.
Signing in is only half the story. Kerberos proves who you are; what you're allowed to do once you're connected is a separate question, which MongoDB handles with role-based access control. One proves your identity, the other sets your permissions.
How MongoDB implements Kerberos
Each MongoDB server registers with Kerberos as its own service principal. MongoDB connects to Kerberos through Generic Security Services Application Program Interface (GSSAPI), an SASL mechanism—the standard framework a database uses to plug in external authentication systems like Kerberos.
Kerberos users live in a special MongoDB database called $external, which holds accounts verified by an outside system rather than by MongoDB itself.
On Linux, each server reads its identity from a keytab file—a protected file that stores its credentials so it can authenticate without anyone typing a password.
On Windows, it reads the same information from the operating system's credential store instead.
To connect, a user gets a Kerberos ticket with kinit, then signs in with mongosh using GSSAPI to authenticate against the $external database.
For full command syntax and setup steps, see the Kerberos on Linux configuration guide.
Secure your database with Kerberos
Kerberos has lasted decades because it solved a hard problem cleanly: prove who you are across a network without ever sending your password across it. That's what makes it the quiet backbone of enterprise login—one sign-in, strong security, no passwords in transit. MongoDB Enterprise brings that same protection to your database.