36

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?

  • 4
    for that: for each user on each server. Imagine the maintenance, and the nightmare for the users – njzk2 Jul 21 '16 at 14:38
  • 1
    How would you keep those passwords synchronized? – el.pescado Jul 21 '16 at 19:40
  • 1
    Kerberos serves the same purpose for corporate networks that OpenID does for web sites -- just like you can use your Google or Facebook login session to access Stack Exchange, you can log in to your network once and then use all of the services on it. – Jules Jul 21 '16 at 19:57
  • 1
    From @LuisCasillas answer: Imagine you have 50 users.... I ran into a server with 300,000+ defined users, and many of us can imagine far more. Creating accounts is not trivial if you want secure servers. – user2338816 Jul 22 '16 at 14:47
41

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.

  • 5
    Adding a new server: You can mirror /etc/passwd and /etc/shadow (i.e. hashes of password+salt) to the new server. It doesn't give you single-sign-on, but it solves most of the other problems. I wrote a script that did that (for UID 500 and higher only), and it worked well across a couple small compute clusters. Most users only used one cluster at a time, so lack of SSO wasn't a problem. This ghetto solution avoided any cluster becoming unusable just because some other machine was down, so there was no point of failure without needing replicated authentication or LDAP servers. – Peter Cordes Jul 21 '16 at 7:17
  • This was in a University setting where most users managed their own desktops, and their desktop user accounts weren't connected to their accounts on the research group clusters. Like I said, small scale and hack-ish solution, but highly reliable and never caused a problem. :) Minor downside: people could only change their password on the master cluster. – Peter Cordes Jul 21 '16 at 7:19
  • 5
    A centralised password database is highly vulnerable to lateral escalation. If an attacker compromises one server, they can sniff passwords, then use these to compromise others servers. Kerberos at least tries to stop this. – paj28 Jul 21 '16 at 17:48
  • 1
    @paj28: I mostly agree, but I've seen Kerberos environments where users ssh into individual servers directly and send their passwords through SSH; the individual servers then procure the Kerberos tokens. If somebody compromises one of those servers you have the same risks. So while Kerberos indeed tries to stop this, "tries" is a key word there. – Luis Casillas Jul 21 '16 at 22:36
  • 1
    @LuisCasillas At least in theory you should forward a ticket. Having a ticket on my local machine I can log through GSSAPI to ssh server (authenticating myself by Kerberos ticket I have locally) and get a ticket on the remote. Sure, there is nothing preventing TLS_NULL_WITH_NULL_NULL from existing but server configured to TLS_NULL_WITH_NULL_NULL is no less a fault of TLS then forcing users to log through password by SSH of Kerberos. – Maciej Piechotka Jul 21 '16 at 23:32
27

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.

  • 1
    So, you are basically saying that through Kerberos, users only maintain credentials to one server? Then this server authenticates itself to the different services? – Minaj Jul 20 '16 at 19:34
  • 5
    @Minaj with Kerberos, users maintain credentials to a domain and not a server. The Kerberos authentication server then tells various resources throughout the domain what resources that user has access to (ie files on a file share, printers, etc). This is what's called Single Sign On (or SSO for short) – DKNUCKLES Jul 20 '16 at 19:36
  • 1
    @Minaj Because in your case, you'd need to store passwords in all those places - and storing passwords (or more properly, password hashes) is difficult. You'd also have to deal with password changes - replicating any password change to each server, dealing with various server changes. What if one server rejects the password change (due to strength requirements) but others accept it? SSO is a much cleaner, better answer with far less administration required. Kerberos is just one of a number of SSO standards, but it is a very old, respected one – crovers Jul 20 '16 at 20:27
  • 2
    @Minaj, The problem with forwarding requests is that Server B, the authentication server, would have all the requests to and from servers passing through it. This means the server would use more network bandwidth and need extra resources dedicated to processing the requests. The Kerberos protocol allows Servers A & C to simply check in with Server B without having to move any communications through B. – ztk Jul 20 '16 at 20:52
  • 3
    Also it'd require each and every server to hold a password(hash) for every user. Which increases the risk of them leaking by a lot. – CodesInChaos Jul 21 '16 at 7:31
12

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.

8

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.

  • As long as all servers have been set up to fully use Kerberos (i.e. with tickets), and not merely verify passwords against a KDC with pam_krb5 as some admins tend to do. – grawity Jul 22 '16 at 14:13
  • Whoever just down voted: I'd be interested to know what's wrong with my answer – paj28 Jan 24 at 13:09
0

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.

  • The "primary benefit" given here can be received from LDAP alone, so this doesn't really cover why one would want Krb5+LDAP over only LDAP (with hashed passwords in the directory). – Charles Duffy Jul 22 '16 at 14:16
  • @CharlesDuffy: I struggle to count a "benefit" that doesn't really work a benefit. – Joshua Jul 22 '16 at 15:09
  • Eh? There are certainly practical benefits over other (ie. LDAP-only) directory-service approaches; you get single-sign-on (users aren't reentering passwords, increasing convenience, reducing the amount of room for sniffers, and discouraging things like expect-based password entry scripting / stored literals). You get resistance against lateral escalation (if going through the effort to Do It Right). You get support for cached credentials in a manner that's specific to a single service and a configurable time period, allowing far better control than the usual means. You have central logging. – Charles Duffy Jul 22 '16 at 17:01
  • @CharlesDuffy: I got single sign-on w/o Krb5; Krb5 lateral escalation protection is mostly broken; timing out cached credentials is interesting, but it usually gets in my way (long-running processes can't be timed out or they break); central logging existed before LDAP, let alone Krb5. – Joshua Jul 22 '16 at 17:07
  • Sure, central logging can be done otherwise, but it's something you need to explicitly set up otherwise -- with kerberos, you get logging of auth attempts centrally for free. Re: "SSO w/o krb5", how precisely? Re: "lateral escalation protection is mostly broken", that's on the folks who are deploying it wrong. (Yes, adding GSSAPI support everywhere is work, but it's worthwhile work, damnit). – Charles Duffy Jul 22 '16 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.