Centralized Authentication with Kerberos 5, Part I

Kerberos can solve your account administration woes.

Account administration in a distributed UNIX/Linux environment can become complicated and messy if done by hand. Large sites use special tools to deal with this problem. In this article, I describe how even small installations, such as your three-computer network at home, can take advantage of the same tools.

The problem in a distributed environment is that password and shadow files need to be changed individually on each machine if an account change occurs. Account changes include password changes, addition/removal of accounts, account name changes (UID/GID changes are a big problem in any case), addition/removal of login privileges to computers and so on. I also explain how the Kerberos distribution solves the authentication problem in a distributed computing environment. In Part II, I will describe a solution for the authorization problem.

The problem of authenticating users to a computer is solved mostly through passwords, although other methods, including smart cards and biometrics, are available. These passwords had been stored in /etc/passwd, but now with shadow passwords, they reside in /etc/shadow. Because these files are local to a computer, it is a big problem keeping them up to date. Directory services such as NIS, NIS+ and LDAP were invented to solve this problem. These services, however, introduce a new problem: they work over the network and expose passwords, which are encrypted only weakly.

The authentication protocol implemented by Kerberos combines the advantages of being a networked service and of eliminating the need to communicate passwords between computers altogether. To do so, Kerberos requires you to run two dæmons on a secure server. The Key Distribution Center (KDC) dæmon handles all password verification requests and the generation of Kerberos credentials, called Ticket Granting Tickets (TGTs). A second dæmon, the Kerberos Administration dæmon, allows you to add, delete and modify accounts remotely without logging in to the computer running the Kerberos dæmons. It also handles password change requests from users. With Kerberos, only a password change ever requires transmitting a strongly encrypted password over the network.

The Kerberos KDC grants a temporary credential, a TGT, to the account during the process of authenticating the user. Typically, these credentials have a lifetime of 10 or 24 hours. This lifetime can be configured and should be no longer than 24 hours, in case the TGT is stolen; a thief could use it only for the remaining TGT lifetime. The credential expiration causes no issues if you are using Kerberos only for authentication, as described in this article. However, if you are using Kerberized services, you need to train your users to obtain new credentials after their current ones expire, even though they still are logged in.

Kerberos was invented at MIT. The latest version is Kerberos 5, with its protocol defined in RFC 1510. Today, two Kerberos implementations are freely available (see the on-line Resources). MIT's Kerberos 5 is included in Red Hat Linux, whereas Heimdal is included in SuSE's and Debian's Linux distributions. Kerberos 5 implementations also are included in Microsoft Windows (2000 and later), in Sun's Solaris (SEAM, Solaris 2.6 and above) and Apple's Mac OS X. I use MIT's Kerberos distribution throughout this article because it offers simple password quality checking, password aging and password history out of the box.

Prerequisites

You have to meet two prerequisites before you can switch authentication over to Kerberos. First, the clocks on all computers to be included in your Kerberos installation need to be synchronized to the clock of the machine running the KDC. The simplest way of doing this is to use the Network Time Protocol (NTP) on all your machines.

The second requirement is harder to meet. All account names, UIDs and GIDs have to be the same on all your computers. This is necessary because each of these accounts becomes a new and independent Kerberos account, called a principal. You have to go through all your local /etc/passwd files and check whether this requirement is met. If not, you need to consolidate your accounts. If you want to add Windows or Mac OS X clients to your Kerberos installation, you need to look at all the accounts on those machines as well.

If you decide to use the Kerberos package that comes with your Linux distribution, simply install it. If you want to compile the Kerberos distribution yourself, follow the instructions below.

Building and Installing MIT Kerberos

1) Get the source from one of the URLs listed in the on-line Resources. Get the PGP signature of the source package and verify the integrity of the downloaded source with:

% gpg --verify krb5-1.3.4.targz.asc

2) Unpack the source with:

% tar zxvf krb5-1.3.4.tar.gz

3) Change into the source directory:

% cd krb5-1.3.4/src

4) Execute:

% ./configure --help

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SSO not working

satish patel's picture

I have read document and implement it but my SSH not working for SSO like one time auth its asking me passwd again and again any solution ?

/etc/hosts file

Joe_Hill's picture

Excellent guide.

Here's a tip that might save knuckleheads like me a few hours of stumbling around: None of this works if you don't have /etc/hosts set up properly. I kept getting this error:

kadmin: Cannot contact any KDC for requested realm while initializing kadmin interface

/etc/hosts MUST contain a line associating the KDC server not with a loopback address (WRONG: "127.0.0.1 kdc.example.com") but with a real IP address available over the network (RIGHT: "128.231.35.98 kdc.example.com"). Ports 88 and 749 must be unfirewalled.

(Since I'm currently out of town and can't fiddle with my router, I'm temporarily assigning KDC to the local address assigned by the router (192.168.2.3), although of course this means I can't access Kerberos over the Internet).

/etc/passwd & /etc/shadow account syncronisation

Aaron Tate's picture

The second requirement is harder to meet. All account names, UIDs and GIDs have to be the same on all your
computers. This is necessary because each of these accounts becomes a new and independent Kerberos account,
called a principal. You have to go through all your local /etc/passwd files and check whether this requirement is
met. If not, you need to consolidate your accounts. If you want to add Windows or Mac OS X clients to your
Kerberos installation, you need to look at all the accounts on those machines as well.

I assume this only applies to user accounts (ie uid > 1k), it would be an utter pain to have to synchronise system accounts across multiple machines.

Format or /etc/krb5.conf

Joe Knall's picture

Running "kdb5_util create -s" gave me the error "Improper format of Kerberos configuration file while initializing Kerberos code" with the example krb5.conf in the article.
Removing all leading whitespace from krb5.conf did the trick.
Thank you btw

Hi,

shann's picture

Hi,

I have read this article. I was wondering is there any second part(s) / continuation of this tutorial? if yes can you provide those tutorial links?

please note my eramil id : massoo@gmail.com , massoo@30gigs.com

regards
shann

pam-krb5 and gksudo

Jared's picture

I've been following the directions in this article and the the subsequent articles about centralized authentication and I was delighted to get my kerberos implementation working. But upon further investigation, I realized that although login and sudo works, applications that use gksudo, such as synaptic don't is there a solution for this. I found a few others with this promlem on the internet, but I couldn't find any solutions. Many thanks for your help on this issue, and all of your very informative articles.

gksudo

Donny's picture

I have since moved away from sudo and started using .k5user and .k5login in /root/ directory

.k5login allow users in that file access to become root
.k5user allow specified commands to be executed as root or as another user.

enjoy

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix