Why do I need Kerberos when I could just use a username and password to access services?

Question

I have read that Kerberos is used for authenticating users who wish to access services on various servers in an enterprise network, but I still do not understand the purpose of Kerberos. Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access? Why is such an elaborate authentication protocol necessary?

Answer 1

Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access?

Imagine you have 50 users and 50 servers. For the sake of simplicity, suppose that all 50 users are supposed to have access to all 50 servers, they all have the same privileges on all servers, and we never have to change these privileges. This is 2,500 password entries in total that need to be created.

Adding a new user

When you add a new user, the admin has to go to all 50 servers and add that one user to all of them. This would need the admin to run the create user command in all 50 servers. That bit can be automated, but the part that cannot be safely automated is that the user would need to enter their password 50 times, once per server.

Why this latter problem? Because password authentication systems are designed so that they do not retain a copy of the password, not even an encrypted copy. So when the user enters their new password on server #1, that server forgets the password right away, so they'd have to enter it yet again for server #2, and #3, etc.

Adding a new server

Maybe now you're thinking that you could write a script that:

1. Runs on server X;
2. Asks the new user to enter their new password;
3. Asks the administrator for their password;
4. Logs in to servers #1 through #50, and creates the user account on each of them with the same password.

That's a bit dodgy, but even if you go for it, you're still left with another, bigger problem. Suppose your company buys a new server, and we now need our 50 users to have access on this server. Well, since none of the servers contains a copy of the users' passwords, the administrator would have to go to each user and have them enter a password for their account in the new server. And there's no getting around this unless you kept copies of users' passwords—which again, is an insecure practice.

Centralized password database

To solve these problems you really need your user/password database to be centralized in one place, and to have all the servers consult that database to authenticate usernames and passwords. This is really the bare minimum you need for a manageable multiuser/multiserver environment. Now:

1. When you add a new user, all the servers automatically pick it up from the central database.
2. When you add a new server, it automatically picks up all the users from the central database.

There's a variety of mechanisms for doing this, albeit they're still short of what Kerberos offers.

Kerberos

Once you have such a centralized database it makes sense to buff it up with more features, both for ease of management and for convenience. Kerberos adds the ability that, when an user has successfully logged in to one service, that service "remembers" the fact and is able to "prove" to other services that this user logged in successfully. So those other services, presented with such proof, will let the user in without asking them for a password.

This offers a mix of convenience and safety:

1. Users don't get asked for their password over and over when they've already entered it successfully once that day.
2. When you have programmers who write programs that access multiple servers, and those servers require authentication, the programs can now authenticate to those servers without having to present a password, by reusing the credentials of the server account they run under.

The latter is important because it minimizes or kills an insecure but all too common practice: automated programs that require you to put copies of usernames and passwords in configuration files. Again, a key idea of secure password management is do not store copies of passwords, not even encrypted copies.

Answer 2

Simply put, that would be an administrative nightmare.

Kerberos allows administrators to have any number of employees use the same credentials to log into resources throughout their domain.

Let's say that this didn't exist in a simple network.

1. User enters password to unlock their computer.
2. User wants to map a network drive. They must now need to re-enter their password
3. User then wants to get email. They open Outlook and then need to enter yet another password.
4. User then needs to log onto the company intranet. That's another password.

You get the idea. Not using Kerberos means that the user needs to maintain passwords to all servers that host services they need to access. This would be a headache for users and administrators alike. Most corporate policies state that users need to change their password every X days. Can you imagine being an end user and needing to change your password on 5 servers every time you need to do it?

From a security perspective the administrator gets all of their login attempts (both successful and failed) in a single spot as opposed to being logged on 5 different servers. This aids in both troubleshooting login issues (ie lockouts) and makes auditing logs much easier.

Answer 3

Kerberos isn't there as a convenience, it's an enhanced security measure. Convenience is a secondary benefit.

A great explanation is Designing an Authentication System: A Dialog in Four Scenes

Basically, instead of just passing a magic token around (ie. your password), you obtain a "ticket", which is signed by a trusted source of truth (ie. Kerberos KDC, Microsoft AD, etc). Your ticket tells services who who are and what entitlement groups you belong to. Think of it like buying an admission ticket to an amusement park vs. giving an attendant money at each ride in a park.

Answer 4

To prevent lateral escalation.

The administrative complexity of password management can be reduced by using a centralised password database, such as LDAP. However, doing so creates the risk of lateral escalation. If an attacker takes control of one server, they can remain silently present, sniffing passwords. These passwords can then be used to compromise other servers - lateral escalation.

Kerberos attempts to solve this: users don't send their password to each server; they only send it to the authentication server, and present a ticket to other servers. In recent times, some flaws have been identified that are exploited by tools like mimikatz. However, at least Kerberos is designed to prevent lateral escalation; LDAP does nothing to stop it.

Answer 5

The primary benefit of Kerberos is to enable account change and password change to synchronize immediately.

I have solutions on hand for centralized administration of distributed accounts, and client-side password agents that respond to 99% of password prompts after login, but all of them assume that user changes password is rare and that we can wait until the nightly batch job for password change to actually take effect. Same goes with permission changes in most cases; if we need permission change to take effect now, the lesser tools can't do it.

Kerberos lists in its abilities the ability to securely authenticate connections without encrypting them. This proves less-than-desirable in practice and that ability should not be relied on. Stealing Kerberos tickets was the essence of an attack on SMB a year ago that would provide all access as a user provided the user was using any network share anywhere.