Centralized Authentication with Kerberos 5, Part I

Kerberos can solve your account administration woes.
Interoperation with Non-Linux Clients

If you already have a working Windows Active Directory (AD) KDC installation, you can use it as the master KDC for your Linux/UNIX machines. In this case, you can skip the entire server installation and do only the above described setup of your clients. Your /etc/krb5.conf file needs to define the Windows KDC instead of a UNIX KDC. For more information on how to create and copy a keytab file and this scenario in general, see Resources.

If you have a number of Windows machines in your group, you can use your UNIX KDC for them as well. This works, however, only if your Windows clients don't belong to a Windows AD domain with Kerberos already and the account names are the same in Kerberos and Windows. See Resources for details.

Using Mac OS X clients in your Kerberos 5 realm is as easy as configuring the names of your UNIX KDCs on your Macs. Again, account names have to match.

Migration from Local Passwords or NIS/LDAP to Kerberos

Now that you have a working Kerberos 5 realm and your clients configured, you have to convert all your user accounts. So far, the passwords for your accounts are stored either in the machine's local /etc/shadow files or in a NIS/LDAP password map. These passwords are encrypted with a one-way hash function that makes it impossible, or at least impractical for people without a supercomputer, to crack them or to convert everything into Kerberos 5 format. A good way to migrate from your current situation to Kerberos is to use pam_krb5_migrate (see Resources). This stackable PAM module can be installed on a few computers; every time someone logs on, it creates a new principal for this account in your Kerberos 5 KDC reusing the account's current password.

After everybody has logged on to these special machines, all your users have a corresponding Kerberos 5 principal. You then can replace the passwords in your local files or your NIS/LDAP password map with a placeholder, such as krb5. The Kerberos PAM module authenticates your users from now on. At this point, you also can remove pam_krb5_migrate from the migration systems.

Kerberized Applications

Now that you have Kerberos up and running, you can use services that make use of it. You could install Kerberized telnet and FTP, but you really should use SSH. You could Kerberize your Apache Web server and your Mozilla Web browser. Before Kerberos, you would have to type your password when using these services. With Kerberos, all these applications are using your stored Kerberos credentials and use them internally to authenticate you for the respective service. This is what many mean by single-sign-on.

Resources for this article: www.linuxjournal.com/article/7706.

Alf Wachsmann, PhD, has been at the Stanford Linear Accelerator Center (SLAC) since 1999. He is responsible for all areas of automated Linux installation, including farm nodes, servers and desktops. His work focuses on AFS support, migration to Kerberos 5, a user registry project and user consultants.



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.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot