Kerberos is a network authentication system that is designed for client to server communication over a (potentially) insecure network, where data can be eavesdropped on, and addresses can be faked. It has several security and usability advantages over using password-based authentication over the network.
One major security advantage of using Kerberos is that if a ticket is stolen from a host, it will expire, so damage is minimized compared to being able to steal a password or long-lived ticket. Kerberos also assumes that the network that is being used for communication could be compromised and has malicious users who could be listening to network traffic and stealing any data sent from machine to machine. To combat this, Kerberos does not send any data like plaintext passwords or keys by themselves across the network that could be used for attacks. Instead, it uses tickets, and encrypts data sent to clients and servers with a key that only that machine can read.
Kerberos makes passwordless login easy, since after the first password is input, a ticket can be used for future logins instead of having to type the same password again and go through the whole authentication process a second time. Keep in mind that all of the authentication will have to be done every 10 hours, as tickets do expire, but passwords have to be typed far less with Kerberos in place. Tickets are invalidated on logout, so that makes sure that someone can't steal a ticket and use it after you have left, as a little added security.
There are two major free versions of Kerberos: MIT and Heimdal Kerberos. At the OCF, we use Heimdal Kerberos; if you look up documentation, it might instead be for the MIT version, so be careful to make sure the commands work. Kerberos also has 2 main versions that are still used: version 4 and version 5. Version 5 fixes a lot of the security and design flaws of version 4, so we use version 5 of the protocol.
Unfortunately, Kerberos is a complicated protocol that involves a lot of technical jargon. Here's a bunch of different terms that you might run into when reading about or working on Kerberos and an attempt to explain what they mean:
KDC (Key Distribution Center): The central server that issues tickets for Kerberos communication and stores all users' keys. If the KDC is compromised, you are going to have a very bad time and will not go to space today. Our current KDC is firestorm, but that could change in the future, as servers are moved around or rebuilt.
Realm: A kerberos domain, usually identified with the domain name in all
caps (e.g. OCF.BERKELEY.EDU). Two hosts are in the same realm if they share
some kind of secret (password or key). The default realm is specified in
/etc/krb5.conf, alongside the location of the KDC and admin server (kerberos.ocf.berkeley.edu in our case). Cross-realm
authentication is possible, but is thankfully not something we need to do, as
it significantly complicates things.
Principal: A Kerberos principal is essentially a name used to refer to an
entry in the Kerberos database. Each principal is associated with a user,
host, or service of a realm. All principals shown below are followed by
@OCF.BERKELEY.EDU since it is the realm the OCF uses.
User: [user] or [user]/[instance] e.g. jvperrin or
mattmcal/root. Used for user logins or for user privileges such as
editing LDAP or running commands with sudo.
Host: host/[hostname] e.g. host/supernova.ocf.berkeley.edu. Used by
Kerberos to allow clients to verify they are communicating with the correct
host. For instance, when using SSH to connect to a host, that hosts's
principal is looked up to make sure that you are connecting to the right
host and that the host is not actually some other malicious host.
Service: [service]/[hostname] e.g. ldap/firestorm.ocf.berkeley.edu.
Used to enable Kerberos authentication with a service running on a
particular host, such as http, which (for instance) enables logins to RT,
or smtp, which allows email authentication.
Ticket: Tickets are issued by the TGS (see below) to clients. Tickets have an expiration time, which is set to the default of 10 hours after being issued.
Keytab: A keytab is essentially the equivalent of a password, but one that can be used easily by a script. If someone has read access to a keytab, they can retrieve all the keys in it, so be very careful what permissions are set on keytabs.
TGT (Ticket Granting Ticket): A special ticket that is used for communication between the client machine and the KDC.
TGS (Ticket Granting Service): Usually the same as the KDC, the job of the TGS is to grant tickets (see above) for different network services.
GSS-API: The API used by different applications to be able to authenticate with Kerberos.
SASL: An authentication layer that many different applications can use.
All conveniently prefixed with the letter k.
kinit: Used to get a ticket, for instance to be able to edit LDAP, or run
commands that need sudo (using the [user]/root principal). For instance,
to edit your own LDAP entry, run kinit [user]/admin ldapvi uid=[user] to
authenticate using your admin Kerberos principal and then run ldapvi. The
default principal requested is your base user principal ([user]@[realm]).
Any commands put after kinit will be ran as usual with the requested
credentials.
klist: Shows all current tickets held with issued and expiration datetimes
and the principal that each ticket corresponds to.
kadmin: Administration utility for Kerberos to make changes to the Kerberos
database, either locally (with -l), or remotely by connecting to the KDC.
Can retrieve information about principals, modify principal attributes,
change principal passwords, show privileges allowed, etc.
kdestroy: Remove a principal or ticket file. This is essentially the
opposite of kinit, so it invalidates tickets you have, logging you out from
Kerberos. This is automatically run on logout to invalidate any lingering
tickets.
ktutil: Very useful command that has a variety of subcommands for managing
keytabs. Can be used to list credentials available in a keytab, add keys to a
keytab, remove keys, etc.
kpasswd: Used to change Kerberos passwords.
kimpersonate: Used for impersonating another user using their keytab.
There are more commands, but they aren't used so often, and can be searched if needed.
To add privileges for users, first create a new principal for them to use. As
part of this process, the user will have to give each principal a password. The
password can be the same or different from their main user principal, but they
will have to enter it every time they want to edit LDAP or run commands with
sudo. To create a new principal, run kadmin add [user]/[instance], where
[instance] is either root or admin. The [user]/root principal is used
when running sudo commands and for changing user passwords, whereas the
[user]/admin principal is used mainly for modifying LDAP.
Next, to give the principal actual privileges, add the principals and
privileges assigned to the kadmind.acl file used by Puppet. Notice that
the all privilege does not actually give all privileges, since the
get-keys privilege is separate. The get-keys privilege is used to fetch
principals' keys, which is equivalent to knowing the password hash in other
authentication systems, so it is not a privilege to be handed out lightly.
Kerberos is pretty complicated, so explaining exactly how it works gets messy very quickly, but here are the main steps that are taken by Kerberos when a user logs in to their machine. A great guide on these steps is Lynn Root's Explain it like I'm 5: Kerberos, and explains it better and in more depth than the rather cursory overview found here:
The user enters their username. Their login is sent to the KDC to receieve a ticket.
The KDC checks in its database for a principal that matches the one sent by the client. If one is found, it returns a TGT, which is encrypted with the user's key (originally generated from the user's password and stored on the KDC).
The client gets the encrypted TGT and decrypts it with the user's entered password. Note the user's password was never directly sent across the network at any stage in the process. Then the TGT is stored in the cache on the client machine until it expires, when it is requested again if needed.
The user can then use this TGT to make requests for service tickets from the KDC.
Kerberos makes sure that nobody can request a TGT for a user except the user
themselves by using preauthentication, which essentially means that the KDC
requests additional authentication than just a principal to give a TGT, since
otherwise the key in the TGT could just be cracked offline by an attacker using
a dictionary attack. This preauthentication typically takes the form of
something like the current time encrypted with the user's key. If an attacker
intercepts this communication, they do not have the exact timestamp or the
user's key to attempt to decrypt it. We require pre-authentication at the OCF
by specifying require-preauth = true in /var/lib/heimdal-kdc/kdc.conf.
Then, if the user wants to communicate with other services or hosts, like SSH or a HTTP Kerberos login, then they make more requests to the KDC:
The client will request a service or host principal from the TGS (Ticket Granting Service) using the TGT received before. The TGS in our case is the same as the KDC, but for some systems they could be different hosts. The TGS sends in response a service ticket, which the client then stores for use in contacting a service and authenticating until the service ticket expires.
The client can then use this service ticket to send with requests to Kerberos-enabled services, like SSH, as user authentication. The service will verify the ticket with the KDC when used, to make sure it is valid for the user issuing the request.