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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState