Centralized Authentication with Kerberos 5, Part I

Kerberos can solve your account administration woes.
Adding New Accounts

New accounts still need to be added to your shadow file or password map. However, instead of putting the encrypted password into these places, you have to create a new Kerberos principal and store the password in the KDC.

Using the kadmin tool:

% /usr/local/sbin/kadmin

add a principal for a regular users with:

kadmin:  addprinc john
NOTICE: no policy specified for john@EXAMPLE.COM; assigning "default"
Enter password for principal "john@EXAMPLE.COM":
Re-enter password for principal "john@EXAMPLE.COM":
Principal "john@EXAMPLE.COM" created.

The password you have entered during this principal creation process is the one john needs to enter in order to obtain a Kerberos TGT or to log in to a computer configured to use your Kerberos 5 realm.

You now either can create principals for all your accounts by hand or use the technique described in the migration section below.

Adding Slave KDCs

If you plan to use Kerberos in production at your site, you should plan on using additional slave KDCs to make your installation more fault tolerant. For this, the master KDC needs to have an additional propagation service installed that sends updated versions of the KDC database to all slave servers. The slave servers need to have a receiving end for the propagation service installed. See the MIT documentation for how to set this up.

Configuring the Clients

The easiest way to enable a computer for Kerberos authentication is to use a pluggable authentication module (PAM). Because it uses Kerberos API calls, it needs a working /etc/krb5.conf file. So, the first step is to copy the /etc/krb5.conf file from your KDC (see above) to each client machine.

Kerberos is used not only to authenticate users, it also is used to authenticate computers, to prevent you from logging in to a machine with a hijacked IP address. For this to work, each computer needs its own Kerberos principal with the key (the password) stored in a file (a keytab file). Principals for computers have the special form:


The first step is to create a new principal for each of your client machines. The following commands use the computer name client1 as an example. Replace the string client1 with the hostname of the client computer. Log in to every one of your client computers and execute:

% sudo /usr/local/sbin/kadmin
kadmin: addprinc -randkey host/

which assigns a random password to the new principal. Then, extract the key into a keytab file with:

kadmin: ktadd host/client1.example.com@EXAMPLE.COM

which creates the file /etc/krb5.keytab. To have write permissions to the /etc/ directory, you need to run the kadmin command with sudo. Simply creating a new principal would not have required these special privileges. Watch out for the ownership and file permissions of /etc/krb5.keytab, however; it has to be readable only by root. Otherwise, the security of this machine is compromised.

Several PAM modules for Kerberos 5 are available and all are called pam_krb5. Most of these do not work any more due to some API changes in MIT Kerberos 5 version 1.3. Your best choice right now is to use the PAM module that comes with your Linux distribution. See the section above on how to build a PAM module for Kerberos 5 from source.

Now, add the new PAM module to your system's authentication stack by editing the file /etc/pam.d/system-auth (on Red Hat systems). The entries should look similar to these Red Hat 9 entries:

auth  required    /lib/security/$ISA/pam_env.so
auth  sufficient  /lib/security/$ISA/pam_unix.so likeauth nullok
auth  sufficient  /lib/security/$ISA/pam_krb5.so use_first_pass
auth  required    /lib/security/$ISA/pam_deny.so

account   required      /lib/security/$ISA/pam_unix.so
account   [default=bad success=ok user_unknown=ignore
↪service_err=ignore system_err=ignore]

password  required    /lib/security/$ISA/pam_cracklib.so
↪retry=3 type=
password  sufficient  /lib/security/$ISA/pam_unix.so
↪nullok use_authtok md5 shadow
password  sufficient  /lib/security/$ISA/pam_krb5.so
password  required    /lib/security/$ISA/pam_deny.so

session   required    /lib/security/$ISA/pam_limits.so
session   required    /lib/security/$ISA/pam_unix.so
session   optional    /lib/security/$ISA/pam_krb5.so

These changes make every program with the system-auth PAM stack in its PAM configuration file (see the other files in /etc/pam.d/) use Kerberos for its authentication.



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: " kdc.example.com") but with a real IP address available over the network (RIGHT: " 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 (, 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


shann's picture


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


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.


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.