MIT Kerberos V client on Debian lenny

In this example, MIT Kerberos V client software is installed on two hosts running Debian 5.0 (lenny). If followed properly, this step-by-step process should produce two new clients that will authenticate to either of two previously installed Kerberos servers: a master KDC, kdc1.example.com, or a slave KDC, kdc2.example.com. At least the master KDC will be required for the installation process. The system also relies heavily on timestamps, so reasonably accurate time synchronization among all participating hosts is essential.

To be sure, Kerberos only provides a method for secure storage of, and access to, pairs of names and passwords, referred to as principals. It does not include any way to store other critical Unix-style account information, such as user ID numbers, group ID numbers, or group memberships. Kerberos is only there to authenticate users based on their name/password combinations and, ideally, to allow further access to network resources with a single sign-on. Using this method, local accounts still have to be created to match the Kerberos user names, or else they will not have home directories or group memberships. A more efficient solution would be to use another system, OpenLDAP, for centralised storage of further account information to compliment Kerberos, but that will be the subject of another article.

Before the actual Kerberos installation process can begin, it will first be necessary to install Debian lenny on two new client hosts, called krbc1.example.com and krbc2.example.com. A DNS server must also be available on the network with a zone file to which forward and reverse mappings can be added for both of these hosts. After the initial installation of the operating system has been completed for each host, make sure these packages are installed as well:

~# apt-get install ssh ntp ntpdate xinetd nmap

After that, on both systems, edit /etc/ntp.conf so that the client synchronizes to a common NTP server (preferably a local one) and edit /etc/default/ntpdate to use the same NTP server also. Now the installation process for the MIT Kerberos V clients can begin:

On both of the new client machines, start by installing these three packages:

~# apt-get install krb5-{config,user} libpam-krb5

A total of four packages are installed as a result, including one dependency:

krb5-config             1.22                             Configuration files for Kerberos Version 5
krb5-user               1.6.dfsg.4~beta1-5lenny2         Basic programs to authenticate using MIT Kerberos
libkadm55               1.6.dfsg.4~beta1-5lenny2         MIT Kerberos administration runtime libraries
libpam-krb5             3.11-4                           PAM module for MIT Kerberos

During the installation, the krb5-config package will automatically have the default realm set to EXAMPLE.COM, but a few questions have to be answered for it as well:

Kerberos servers for your realm: kdc1.example.com kdc2.example.com 
Administrative server for your Kerberos realm: krb.example.com

These settings, along with the default realm, are saved in /etc/krb5.conf.

Regarding the set of servers used for the realm, it is recommended that a predefined set of DNS hostname aliases (CNAME records) be used to refer to the realm's various KDCs (not just for the administration server). In this manner, if a KDC has to be replaced, only its DNS entry will need to be changed. This is preferable to modifying the list of KDCs in /etc/krb5.conf on every client on the network every time a KDC entry is added or changed in the DNS.

Edit the Kerberos realm configuration file, /etc/krb5.conf. This file is initially created by the Debian installer and contains information about the realms of a number of famous institutions, but none of that is necessary in this case. Instead, replace its contents with this:

[libdefaults]
        default_realm = EXAMPLE.COM
        forwardable = true
        proxiable = true

[realms]
        EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = krb.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
        example.com = EXAMPLE.COM

See this section for a more detailed explanation of this file.

Regarding the list of KDCs that are specified here, it is often recommended to use a predetermined set of DNS hostname aliases (CNAME records) to refer to the Kerberos servers on a network. However, it is also possible to omit the KDC entries in /etc/krb5.conf and instead rely on SRV DNS resource records to do the same job. See DNS discovery for MIT Kerberos V for information on how to do that.

On both krbc1 and krbc2, use kadmin (password Lampropeltis) to create a host principal and a local keytab file by issuing a few commands. These are for krbc1:

~# kadmin -p admin
Authenticating as principal admin with password.
Password for admin@EXAMPLE.COM: Lampropeltis
kadmin:  addprinc -randkey host/krbc1.example.com
WARNING: no policy specified for host/krbc1.example.com@EXAMPLE.COM; 
defaulting to no policy
Principal "host/krbc1.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/krbc1.example.com
Entry for principal host/krbc1.example.com with kvno 3, encryption type 
AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/krbc1.example.com with kvno 3, encryption type 
ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/krbc1.example.com with kvno 3, encryption type 
Triple DES cbc mode with HMAC/sha1 added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/krbc1.example.com with kvno 3, encryption type 
DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:  q
~# _

The -randkey switch is used because a machine cannot enter a password. By default, Kerberos saves its keys in /etc/krb5.keytab. To list the keys in this file, use the klist -ke command. A host principal and keytab file should be created for and saved on all of the various client machines that are part of a Kerberos realm.

Altering the client machine's Linux-PAM configuration will make it possible for users to authenticate using either a Unix or a Kerberos password. However, as PAM is both a relatively complex subject and a recurring theme, it was decided to create a dedicated page for it. Those unfamiliar with its workings are advised to read it. Otherwise, make the modifications described below, which are followed by a few explanations.

Edit /etc/pam.d/common-auth and change it to:

auth        sufficient    pam_unix.so        nullok_secure
auth        sufficient    pam_krb5.so        use_first_pass
auth        required      pam_deny.so

Edit /etc/pam.d/common-account and change it to:

account     sufficient    pam_unix.so
account     sufficient    pam_krb5.so
account     required      pam_deny.so

Edit /etc/pam.d/common-password and change it to:

password    sufficient    pam_unix.so        nullok obscure md5
password    sufficient    pam_krb5.so        use_first_pass
password    required      pam_deny.so

Edit /etc/pam.d/common-session and change it to:

session     required      pam_unix.so
session     optional      pam_krb5.so

In this modified PAM configuration, two new modules are introduced:

In /etc/pam.d/common-auth, an argument is used for the pam_krb5.so module: use_first_pass. This forces it to use a password that was used for the previous module in the stack so that it does not prompt the user. The module will fail only if the password is absent or invalid.

Using sufficient instead of required for pam_krb5.so and pam_unix.so in the first three of these configuration files creates a situation where success is possible if only one of the two modules succeeds. However, it also means that the stack is no longer capable of producing a return status to indicate failure. To remedy this, the pam_deny.so module is added with required to the end of the stack to ensure that the entire process will still return a failure in case neither of the previous modules returns a success.

Before any further tests are conducted, create a normal Unix user account on both client machines and as a Kerberos principal. First create this Unix account ccolumbus with password SantaMaria on both krbc1 and krbc2.example.com:

~# adduser ccolumbus
Adding user `ccolumbus' ...
Adding new group `ccolumbus' (1001) ...
Adding new user `ccolumbus' (1001) with group `ccolumbus' ...
Creating home directory `/home/ccolumbus' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: SantaMaria
Retype new UNIX password: SantaMaria
passwd: password updated successfully
Changing the user information for ccolumbus
Enter the new value, or press ENTER for the default
	Full Name []: Christopher Columbus
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] 
~# _

Now use kadmin to create a matching principal for this new user. Normally, the same password would be used for both Unix and Kerberos, but for the sake of illustration a different password will be used in this case: NewWorld. Of course, the Kerberos principal only needs to be created once:

~# kadmin -p admin
Authenticating as principal admin with password.
Password for admin@EXAMPLE.COM: Lampropeltis
kadmin:  addprinc ccolumbus
WARNING: no policy specified for ccolumbus@EXAMPLE.COM; \
defaulting to no policy
Enter password for principal "ccolumbus@EXAMPLE.COM": NewWorld
Re-enter password for principal "ccolumbus@EXAMPLE.COM": NewWorld
Principal "ccolumbus@EXAMPLE.COM" created.
kadmin:  q
~# _

With these accounts it is possible to log in (at the console, or with ssh) as ccolumbus using either of the two passwords. If the SantaMaria password is used, shell access to the host will be granted, but a quick test using klist will show that a Kerberos ticket is lacking. This can be remedied by running kinit and submitting the NewWorld password, but it would not be a single sign-on solution.

On the other hand, if the NewWorld password is used to log in instead, not only will shell access to the host be granted, but thanks to the PAM configuration a Kerberos ticket will be acquired with which to gain access to other services.

On both client machines, install a client-server application that will help to test Kerberos authentication. It is a Kerberized version of rsh and requires only two packages:

~# apt-get install krb5-{clients,rsh-server}

These are the only two packages that are installed:

krb5-clients        1.6.dfsg.4~beta1-5lenny2     Secure replacements for ftp, telnet and rsh using MIT Kerberos
krb5-rsh-server     1.6.dfsg.4~beta1-5lenny2     Secure replacements for rshd and rlogind using MIT Kerberos

At the end of the install process, two important notices are displayed for xinetd users regarding the krb5-rsh-server package. It informs us that manual conversion to xinetd format is necessary for two hashed-out entries that have been added to /etc/inetd.conf: one for the kshell service and the other for eklogin. Fix it by creating the two files necessary. First, /etc/xinetd.d/kshell:

service kshell
{
        flags       = REUSE
        socket_type = stream
        wait        = no
        user        = root
        server      = /usr/sbin/kshd
        server_args = -5 -c -A
        disable     = no
}

The second of these two files to create is /etc/xinetd.d/eklogin:

service eklogin
{
        flags       = REUSE
        socket_type = stream
        wait        = no
        user        = root
        server      = /usr/sbin/klogind
        server_args = -5 -c -e
        disable     = no
}

Restart xinetd:

~# /etc/init.d/xinetd restart

Now, on krbc1.example.com, request a Kerberos ticket for user ccolumbus, with password NewWorld, and then use krb5-rsh to start a shell session on krbc2:

root@krbc1:~# klist -5
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
root@krbc1:~# kinit ccolumbus
Password for ccolumbus@EXAMPLE.COM: NewWorld
root@krbc1:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ccolumbus@EXAMPLE.COM

Valid starting     Expires            Service principal
11/22/09 20:31:46  11/23/09 20:31:35  krbtgt/EXAMPLE.COM@EXAMPLE.COM
root@krbc1:~# krb5-rsh -l ccolumbus -x -PN krbc2.example.com
This rlogin session is encrypting all data transmissions.
Linux krbc2 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ccolumbus@krbc2:~$ _

• MIT Kerberos V master on Debian lenny
• MIT Kerberos V slave on Debian lenny
• MIT Kerberos V client on Debian squeeze
• PAM configuration guide for Debian
• DNS discovery for MIT Kerberos V

• Eastlake D, Panitz A. 1999. RFC2606 − Reserved Top Level DNS Names. The Internet Society. HTML at the Internet FAQ Archives.
• Kohl J, Neuman C. 1993. RFC1510 − The Kerberos Network Authentication Service (V5). HTML at the Internet FAQ Archives.
• Samar V, Schemers R. 1995. RFC 86.0 − Unified Login with Pluggable Authentication Modules (PAM). Open Software Foundation. Text at The Open Group.

• Garman J. 2003. Kerberos, The Definitive Guide. O'Reilly & Associates, Inc. ISBN-13 978-0-596-00403-3. 253 pp. See pages 80-83.
• Massachusetts Institute of Technology. 1985-2007. Kerberos V5 System Administrator's Guide. HTML at the Massachusetts Institute of Technology (MIT).
• Milicchio F, Gehrke WA. 2007. Distributed Services with OpenAFS. Springer-Verlag. ISBN-13 978-3-540-36633-1. 395 pp. See pages 53-56.
• Morgan AG. 2001. Pluggable Authentication Modules (PAM). Open-PAM working group. Text at The Kernel Archives.
• Morgan AG, Kukuk T. 2010. The Linux-PAM System Administrator's Guide. HTML at The Kernel Archives..
• Ocelic D. 2006-2010. Debian GNU: Setting up MIT Kerberos 5. HTML at Spinlock Solutions. See sections Installing kerberized clients and PAM configuration.