Why is Kerberos Required ?

Why is Kerberos Required ?

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.