OpenLDAP client with MIT Kerberos V on Debian squeeze

This article builds on at least two previous ones in which an OpenLDAP provider server, ldapks1.example.com, and an MIT Kerberos V KDC, kdc1.example.com, were set up containing a user account, called ccolumbus (password NewWorld). The aim here is to set up a client machine that will use Kerberos for authentication and OpenLDAP for authorization and meta information (UID, GID, etc.) when this user logs into it, creating a new home directory in the process. The system also relies heavily on timestamps, so reasonably accurate time synchronization among all participating hosts is essential.

In this example, client software for OpenLDAP and MIT Kerberos V is installed on a host running Debian 6.0 (squeeze). If followed properly, the step-by-step process should produce a new client machine.

Before the relevant installation procedures can begin, it will first be necessary to install Debian lenny on a new host called ldapkc1.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 this host. After the initial installation of the operating system, make sure these packages are installed on the system as well:

~# apt-get install ssh ntp ntpdate nmap

After installing them, edit /etc/ntp.conf so that the new host synchronizes to a common NTP server (preferably a local one) and edit /etc/default/ntpdate to do the same. Now the installation process for the new OpenLDAP client with support for MIT Kerberos V can begin:

First, run the following command to test if the MIT Kerberos V server installed previously is available on the network:

~# nmap -sU -sT -p U:88,464,T:464,749 kdc1.example.com

Starting Nmap 5.00 ( http://nmap.org ) at 2010-12-27 21:46 CET
Interesting ports on kdc1.example.com (192.168.2.36):
PORT    STATE         SERVICE
464/tcp open          kpasswd5
749/tcp open          kerberos-adm
88/udp  open|filtered kerberos-sec
464/udp open|filtered kpasswd5
MAC Address: 08:00:27:AB:13:C1 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 1.44 seconds
~# _

If the above port numbers are not open as shown above, address that problem first. If they are open, continue by installing these three packages:

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

These are the only three packages that will installed as a result, with no dependencies:

krb5-config            2.2                              Configuration files for Kerberos Version 5
krb5-user              1.8.3+dfsg-4                     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.

Use kadmin (password Lampropeltis) to create a host principal and a local keytab file by issuing a few commands:

~# kadmin -p admin
Authenticating as principal admin with password.
Password for admin@EXAMPLE.COM: Lampropeltis
kadmin:  addprinc -randkey host/ldapkc1.example.com
WARNING: no policy specified for host/ldapkc1.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/ldapkc1.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/ldapkc1.example.com
Entry for principal host/ldapkc1.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/ldapkc1.example.com with kvno 2, encryption type ArcFour with HMAC/md5 added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/ldapkc1.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/ldapkc1.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 to avoid having to use a password. To list the keys in /etc/krb5.keytab, use the klist -ke command. A host (or service) principal and a keytab file should be created for and saved on all of the various client machines that are part of a Kerberos realm.

From this point on, a more detailed level of questioning will be required from debconf. To achieve this, run the following command:

~# dpkg-reconfigure debconf

Answer the questions as follows:

Interface to use: Dialog
Ignore questions with a priority less than: low

Run the following command to test if the previously installed OpenLDAP server is actually available on the network:

~# nmap -p 389 ldapks1.example.com

Starting Nmap 5.00 ( http://nmap.org ) at 2010-12-27 21:21 CET
Interesting ports on ldapks1.example.com (192.168.2.53):
PORT    STATE SERVICE
389/tcp open  ldap
MAC Address: 08:00:27:43:43:4A (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
~# _

If port 389 is not open, as it is shown above, fix that problem first. Otherwise, continue by installing these five packages:

~# apt-get install ldap-utils libnss-ldap libpam-ldap nscd \
libsasl2-modules-gssapi-mit

As a result, five packages are installed, including no dependencies:

ldap-utils                       2.4.23-7                    OpenLDAP utilities
libnss-ldap                      264-2.2                     NSS module for using LDAP as a naming service
libpam-ldap                      184-8.5                     Pluggable Authentication Module for LDAP
libsasl2-modules-gssapi-mit      2.1.23.dfsg1-6              Cyrus SASL - pluggable authentication modules (GSSAPI)
nscd                             2.11.2-7                    GNU C Library: Name Service Cache Daemon

During the installation procedure, certain questions will be asked about two of these packages, first, about libnss-ldap. Answer them as follows:

LDAP server URI: ldap://ldapks1.example.com/ ldap://ldapks2.example.com/
Distinguished name of the search base: dc=example,dc=com
LDAP version to use: 3
Does the LDAP database require login? No
Special LDAP privileges for root? No
Make the configuration file readable/writeable by its owner only? No

NB: Regarding the question of which LDAP server to use, this field supports mutiple server URIs.

These six questions are immediately followed by four more regarding libpam-ldap. Answer them as follows:

Allow LDAP admin account to behave like local root? No
Does the LDAP database require login?: No
Local encryption algorithm to use for passwords: crypt

At this point, man-db also has a question that needs answering:

Should man and mandb be installed 'setuid man'? No

Finally, libpam-runtime asks a general PAM configuration question:

PAM profiles to enable: (select only Kerberos and Unix authentication)

It is one thing to set up a host that requires users to authenticate with Kerberos, but it is another to arrange for the host itself to use LDAP to search for information about new users in order to set up home directories for them as they log in. This lookup is performed by libnss-ldap; a package that will be installed shortly. However, libnss-ldap will only be able to do this if the host first authenticates automatically, using its Kerberos host key, and subsequently creates a ticket cache file (with a TGT) that libnss-ldap can use. The question is then how to achieve this. One way to do it is to run kinit -k with a cron job, but a better solution is to use a modified version of kinit, called k5start. Install it with:

~# apt-get install kstart

This is the only package that gets installed as a result:

kstart             3.16-3              Kerberos kinit supporting AFS and ticket refreshing

To configure it, just add this line to the end of the /etc/inittab file to start running k5start in the background soon after the system boots up:

KS:2345:respawn:/usr/bin/k5start -U -f /etc/krb5.keytab -K 10 -l 24h

Four options have been used for this command:

After saving this modification to /etc/inittab, start k5start for the first time by forcing init to reload its configuration file:

~# kill -HUP 1

Immediately afterwards, the Kerberos ticket cache file for root, /tmp/krb5cc_0, should appear.

NB: If the client is configured to authenticate to a Kerberos slave KDC only, then it may be necessary to force replication of the Kerberos database from the master to the slave before k5start can receive an initial Kerberos ticket (TGT).

To kerberize libnss-ldap, edit /etc/libnss-ldap.conf and add these three lines to the end of the file:

use_sasl        on
sasl_mech       gssapi
krb5_ccname	FILE:/tmp/krb5cc_0

This will instruct libnss-ldap (and thus nscd) to use SASL and GSSAPI, as well where to find the Kerberos ticket cache for the ldapkc1 host principal. The ticket cache file is only accessible by root, but this is not a problem, since nscd runs as root anyway.

Edit /etc/ldap/ldap.conf and add these three lines to the end of the file:

BASE	dc=example,dc=com
URI	ldap://ldapks1.example.com/ ldap://ldapks2.example.com/

SASL_MECH GSSAPI

This configuration file is used to set system-wide defaults for LDAP clients.

As is mentioned in the dialog during the install procedure for libnss-ldap, the /etc/nsswitch.conf configuration file needs to be edited before LDAP will be ready to support the login process. These are the changes that must be made to it:

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

Then, restart the Name Service Cache Daemon:

~# /etc/init.d/nscd restart
Restarting Name Service Cache Daemon: nscd.
~# _

Only one of the five files below will be modified − the rest is informational. PAM plays an important role in the local authentication process and since its configuration is modified when libpam-ldap is installed, it is good to know 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-ldap is as follows (the format has been simplified for the sake of clarity):

/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

Edit /etc/pam.d/common-session and add one line to the very end of the file:

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

session  required                                         pam_mkhomedir.so

The module, pam_mkhomedir.so, creates a user's home directory if it does not yet exist. This is done using the location of the home directory given in the user's LDAP entry.

/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

See this section for more information.

At this point it should be possible to authenticate to the new client using the previously created Kerberos account and its matching LDAP account: ccolumbus with password NewWorld. If all goes well, a new home directory will be created for it automatically upon login. Even if, later on, someone with a Unix-only account is the first to log in after a reboot, the UID and GID of the new ccolumbus home directory will still be resolved despite a lack of any related Unix account information in /etc/passwd or /etc/group. This is thanks to libnss-ldap and nsdc working in the background, retrieving the necessary information from the LDAP servers when they are available and caching it for when they are not.

• OpenLDAP provider with MIT Kerberos V on Debian squeeze
• OpenLDAP consumer with MIT Kerberos V on Debian squeeze
• OpenLDAP client with MIT Kerberos V on Debian lenny
• PAM configuration guide for Debian
• DNS discovery for MIT Kerberos V
• DNS discovery for OpenLDAP

• Eastlake D, Panitz A. 1999. RFC2606 − Reserved Top Level DNS Names. The Internet Society. HTML at the Internet FAQ Archives.
• Hodges J, Morgan R. 2002. RFC3377 − Lightweight Directory Access Protocol (v3): Technical Specification. 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.
• Linn J. 2000. RFC2743 − Generic Security Service Application Program Interface Version 2, Update 1. The Internet Society. HTML at the Internet FAQ Archives.
• Myers J. 1997. RFC2222 − Simple Authentication and Security Layer (SASL). The Internet Society. 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.
• Wahl M, Howes T, Kille S. 1997. RFC2251 − Lightweight Directory Access Protocol (v3). The Internet Society. HTML at the Internet FAQ Archives.
• Wray J. 2000. RFC2744 − Generic Security Service API Version 2 : C-bindings. The Internet Society. HTML at the Internet FAQ Archives.
• Yeong W, Howes T, Kille S. 1993. RFC1487 − X.500 Lightweight Directory Access Protocol. The Internet Society. HTML at the Internet FAQ Archives.

• Carter G. 2003. LDAP System Administration. O'Reilly & Associates, Inc. ISBN 1-56592-491-6. 294 pp.
• Massachusetts Institute of Technology. 1985-2010. Kerberos V5 System Administrator's Guide. HTML at the Massachusetts Institute of Technology (MIT).
• 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 OpenLDAP. HTML at Spinlock Solutions.