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

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.

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.

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.