Centralized Authentication with Kerberos 5, Part I

Kerberos can solve your account administration woes.

creates an initial Kerberos database for the new realm. It asks you for the database master password for the new realm and stores it in a file (/usr/local/var/krb5kdc/.k5.EXAMPLE.COM). This command also creates a first set of principals in your Kerberos 5 account database. You can list them by using:

% sudo /usr/local/sbin/kadmin.local

and then typing listprincs at the kadmin.local: prompt. This prints the list:

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

At this time, we are not ready to use the remote version of the kadmin tool.

Before you start creating any principals in your new realm, you should define a policy that determines how passwords are handled:

kadmin.local:  add_policy -maxlife 180days -minlife
↪2days -minlength 8 -minclasses 3
↪-history 10 default

This input defines a default policy used for every principal we create from now on. It determines that the maximum lifetime for passwords is 180 days. The minimum lifetime is two days. The minimum password length is eight characters, and these characters have to come from three different classes out of these five available ones: lowercase, uppercase, numbers, punctuation and others. A history of the last ten passwords is kept to prevent reuse. If you want to have passwords checked against a dictionary, add a dict_file definition such as:

[realms]
    EXAMPLE.COM = {
        dict_file = /usr/share/dict/words
    }

to your kdc.conf file.

You now are ready to create an administration principal for yourself:

kadmin.local: addprinc john/admin

Adjust the name to your account name but keep the /admin. It then asks twice for a new password for this principal. You can look at the new account with:

kadmin.local:  getprinc john/admin

which prints something like:

Principal: john/admin@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Dec 24 09:55:17 PST 2003
Password expiration date: Mon Jun 21 10:55:17 PDT 2004
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Wed Dec 24 09:55:17 PST 2003 (root/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: default

Exit the kadmin.local program by typing quit and start the KDC dæmon with:

% sudo /usr/local/sbin/krb5kdc

Get a Kerberos 5 TGT by typing:

% /usr/local/bin/kinit john/admin@EXAMPLE.COM

and look at your TGT with:

% /usr/local/bin/klist
Ticket cache: FILE:/tmp/krb5cc_5828
Default principal: john/admin@EXAMPLE.COM

Valid starting     Expires            Service principal
12/23/03 14:15:39  12/24/03 14:15:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Congratulations! You just completed your first successful Kerberos authentication.

You now need to specify which privileges this administration account should have, which is determined by entries in the file /usr/local/var/krb5kdc/kadm5.acl. You can give john/admin permissions to administer all principals, indicated by the wildcard character *, by adding the line:

john/admin@EXAMPLE.COM  *

to this file.

Before you can start using the administration dæmon (kadmind) over the network, you have to create a keytab file containing the key for one of the kadmin principals created when we initialized our realm:

kadmin.local:  ktadd -k /usr/local/var/krb5kdc/
↪kadm5.keytab kadmin/changepw

Now everything is ready for the Kerberos administration dæmon. Start it with:

% sudo /usr/local/sbin/kadmind

This dæmon allows you to administer your Kerberos principals remotely, without logging in to your KDC, using the kadmin client tool. If you want your Kerberos dæmons to start up automatically at boot time, add them to your KDC's /etc/rc files.

With the Kerberos TGT obtained above, start the remote administration tool:

% /usr/local/sbin/kadmin
Authenticating as principal john/admin@EXAMPLE.COM
with password.
Password for john/admin@EXAMPLE.COM:

______________________

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