MIT Kerberos V client on Debian squeeze

In this example, MIT Kerberos V client software is installed on two hosts running Debian 6.0 (squeeze). 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 other articles cover that subject.

Before the actual Kerberos installation process can begin, it will first be necessary to install Debian on one, but preferably two new client hosts, called krbc1.example.com and krbc2.example.com. A DNS server must also be available on the network with zone files 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

These are also the only three packages that are installed:

krb5-config             2.2                         Configuration files for Kerberos Version 5
krb5-user               1.8.3+dfsg-1                Basic programs to authenticate using MIT Kerberos
libpam-krb5             4.3-1                       PAM module for MIT Kerberos

During the installation, krb5-config will require that a few questions be answered:

Default Kerberos version 5 realm: EXAMPLE.COM
Kerberos servers for your realm: kdc1.example.com kdc2.example.com
Administrative server for your Kerberos realm: krb.example.com

These settings are saved in the Kerberos realm configuration file /etc/krb5.conf. Mostly, it contains information about the realms of a number of other organizations and options regarding Kerberos 4, all of which is unnecessary in this case. The entire contents could be replaced with:

[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
        }

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 DNS SRV 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 2, 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 2, encryption type 
ArcFour with HMAC/md5 added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/krbc1.example.com with kvno 2, 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 2, 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.

Nothing needs to be altered here − this section is purly informational. PAM plays an important role in the local authentication process and since its configuration is modified when libpam-krb5 is installed, it was thought best to show what is going on. PAM is both a relatively complex subject and a recurring theme, so a dedicated page (PAM configuration guide for Debian) was created for it. Those unfamiliar with its workings are advised to read it. Otherwise, the default PAM configuration for Debian squeeze with libpam-krb5 is as follows:

/etc/pam.d/common-auth:

auth	 [success=2 default=ignore]			  pam_krb5.so minimum_uid=1000
auth	 [success=1 default=ignore]			  pam_unix.so nullok_secure try_first_pass
auth	 requisite					  pam_deny.so
auth	 required					  pam_permit.so

/etc/pam.d/common-account:

account	 [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account	 requisite					  pam_deny.so
account	 required					  pam_permit.so
account	 required					  pam_krb5.so minimum_uid=1000

/etc/pam.d/common-password:

password requisite					  pam_krb5.so minimum_uid=1000
password [success=1 default=ignore]			  pam_unix.so obscure use_authtok try_first_pass sha512
password requisite					  pam_deny.so
password required					  pam_permit.so

/etc/pam.d/common-session:

session	 [default=1]					  pam_permit.so
session	 requisite					  pam_deny.so
session	 required					  pam_permit.so
session	 optional					  pam_krb5.so minimum_uid=1000
session	 required					  pam_unix.so

/etc/pam.d/common-session-noninteractive:

session	 [default=1]					  pam_permit.so
session	 requisite					  pam_deny.so
session	 required					  pam_permit.so
session	 optional					  pam_krb5.so minimum_uid=1000
session	 required					  pam_unix.so

Beyond the default Debian PAM configuration, one new module is used: pam_krb5.so. This module provides authentication, as well as account, session and password management against Kerberos servers. The minimum_uid=1000 setting instructs the module to not do anything if an account name corresponds to a local account with a UID lower than 1000.

In /etc/pam.d/common-password, two new setting have been added to the pam_unix.so module: use_authtok, which forces it to set the new password to the one used for the previous module, and try_first_pass, which forces it to use the password that was used for the previous module so as to avoid prompting the user.

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 also the only two packages that are installed:

krb5-clients        1:1.0.1-1                   Secure replacements for ftp, telnet and rsh using MIT Kerberos
krb5-rsh-server     1:1.0.1-1                   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
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
10/11/10 00:49:15  10/12/10 00:49:14  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.32-5-686 #1 SMP Sat Sep 18 02:14:45 UTC 2010 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 squeeze
• MIT Kerberos V slave on Debian squeeze
• MIT Kerberos V client on Debian lenny
• 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-2010. 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.