Linux Server Hacks, Volume Two

Hack #7. Secure Your System with Kerberos

You can heighten the security of any network by using Kerberos for secure network authentication and encrypted communications.

Kerberos is a distributed authentication and communication service originally developed at the Massachusetts Institute of Technology (MIT). Kerberos provides secure authentication and communication for client/server applications by using strong cryptography to enable clients to prove their identities to servers over the network.

Kerberos works by exchanging encrypted security information between clients (which can be users or machines), the Kerberos authentication server, and the resource you are trying to access. The information that is initially exchanged when attempting to prove one's identity is known as a ticket. The information used to encrypt tickets and subsequent communications is known as a key. Once the identity of a client is verified, that client is granted a Kerberos token that can be used to verify its identity to any Kerberos-aware service. For security reasons, Kerberos tokens are time-stamped so that they automatically expire unless renewed by a user or service. The primary system for granting tickets (which houses the master copy of the Kerberos database) is known as the Kerberos Key Distribution Center (KDC).

The timestamps contained within Kerberos tokens (and tickets) can be verified only if the time and date are synchronized across Kerberos clients and servers. Kerberos authentication will fail if client and server clocks become skewed by more than five minutes. You should always run NTP (Network Time Protocol) daemons on all Kerberos clients and servers to guarantee that their clocks remain in sync [Hack #22] .

Kerberos uses the term realm to differentiate between authentication and Internet domains. A Kerberos realm is a set of machines that rely on a specific Kerberos server for authentication and therefore trust that server. In Kerberos configuration files, your realm is typically identified in uppercase characters in order to differentiate it from any similar DNS domain with which it is associated.

Tip

MIT's Kerberos implementation is only one of several. Many alternate Kerberos implementations have been created over the years, usually to get around United States export restrictions that have since been lifted. For example, SUSE systems use an alternate Kerberos client/server implementation known as Heimdal (http://www.pdc.kth.se/heimdal/). This hack focuses on vanilla Kerberos from MIT, which I prefer to use because I find it to be the best supported and most easily used on a variety of Unix and Linux systems.

Installing Kerberos

Using Kerberos requires that you have a few basic packages installed on your systems, or that you build and install it yourself from scratch. If you need to build it yourself, you can download the latest version from MIT at http://web.mit.edu/kerberos/www/. If your Linux systems use a package management system and you want to use a vanilla Kerberos, you'll need to install:

• krb5-workstation on all client systems. This contains basic Kerberos programs (kinit, klist, kdestroy, kpasswd) as well as Kerberized versions of the telnet and ftp applications.

• krb5-server on all server and slave server systems. This provides the programs that must be installed on a Kerberos 5 server or server replica.

• krb5-libs on all client and server systems. This contains the shared libraries used by Kerberos clients and servers.

• pam_krb5 on all client systems. This provides a PAM that enables Kerberos authentication.

Installing and Configuring a Kerberos Server

After building and installing Kerberos or installing the krb5-workstation, krb5-server, and krb5-libs packages on your the host that will serve as your master KDC, the first step in configuring your Kerberos environment is to set up your master KDC. The process for doing this is the following:

1. Edit the general Kerberos configuration file for your environment (/etc/krb5.conf). This file identifies the KDCs and admin servers in your Kerberos realm and provides default values for your realm and Kerberos applications and for how your existing hostnames map into your Kerberos realm. Here's a sample /etc/krb5.conf file for the realm VONHAGEN.ORG (replace the italicized items with the correct values for your system):

   	[logging]
   		default = FILE:/var/log/krb5libs.log
   		kdc = FILE:/var/log/krb5kdc.log
   		admin_server = FILE:/var/log/kadmind.log
   	[libdefaults]
   		default_realm = VONHAGEN.ORG
   		dns_lookup_realm = false
   		dns_lookup_kdc = false
   		ticket_lifetime = 24h
   		forwardable = yes
   	[realms]
   		VONHAGEN.ORG = {
   		kdc = kerberos.vonhagen.org:88
   		admin_server = kerberos.vonhagen.org:749
   		default_domain = vonhagen.org
   	}
   	[domain_realm]
   		.vonhagen.org = VONHAGEN.ORG
   		vonhagen.org =	 VONHAGEN.ORG
   	[kdc]
   		profile = /var/kerberos/krb5kdc/kdc.conf
   	[appdefaults]
   		pam = {
   			debug = false
   			ticket_lifetime = 36000
   			renew_lifetime = 36000
   			forwardable = true
   			krb4_convert = false
   		}

   The defaults provided in the generic /etc/krb5.conf file are reasonable, except that you must change all instances of EXAMPLE.COM to the name of your realm and all instances of example.com to the name of your domain (VONHAGEN.ORG and vonhagen.org, respectively, in the previous example). You must also make sure that DNS or /etc/hosts entries exist on all clients for the systems that you identify as your default KDC and admin_server systems in the [realms] section.

2. Edit the KDC configuration file (/var/kerberos/krb5kdc/kdc.conf). The location of this file is provided in the [kdc] section of the /etc/krb5.conf file. As with the /etc/krb5.conf file, the primary change that you must make to this file is to change the instance of EXAMPLE.COM to the name of your realm, which is VONHAGEN.ORG in the following example:

   	[kdcdefaults]
   		acl_file = /var/kerberos/krb5kdc/kadm5.acl
   		dict_file = /usr/share/dict/words
   		admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
   		v4_mode = nopreauth
   	[realms]
   		VONHAGEN.ORG = { 
   		 master_key_type = des-cbc-crc 
   		 supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal \ 
   		 des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal \ 
   		 des-cbc-crc:v4 des-cbc-crc:afs3
   		}

3. Next, use the kdb5_util utility on the master KDC to create the Kerberos database and your stash file. You will have to enter the master database password twice, for verification purposes. The stash file is a local, encrypted copy of the master key that is used to automatically authenticate the KDC as part of your system's startup sequence. For example:

   	# /usr/kerberos/sbin/kdb5_util create -r VONHAGEN.ORG -s
   	Loading random data
   	Initializing database '/var/kerberos/krb5kdc/principal' for realm
   	'vonhagen.org',
   	master key name 'K/[e-mail]'
   	You will be prompted for the database Master Password.
   	It is important that you NOT FORGET this password.
   	Enter KDC database master key:
   	Re-enter KDC database master key to verify:

   This command creates various files in the directory specified in the kdcdefaults section of your kdc.conf file: two Kerberos database files (principal.db and principal.ok), the Kerberos administrative database file (principal.kadm5), the database lock file (principal.kadm5.lock), and the stash file (.k5stash).

4. Next, edit the ACL definition file (/var/kerberos/krb5kdc/kadm5.acl), changing the default realm (EXAMPLE.COM) to the name of the realm that you are creating (VONHAGEN.ORG, in this example). The default entry in this file, which begins with */admin, gives any user with an admin instance (such as wvh/admin, which we'll create in the next step) complete access to and control over the realm's Kerberos database. After we update this file for our example realm, it will look like this:

   	*/[e-mail] *

5. Next, use the kadmin.local utility to add each of your system administrators to the Kerberos database. kadmin.local is a Kerberos-aware version of the standard kadmin utility that does not first authenticate to a Kerberos database and is therefore used for bootstrapping Kerberos on a KDC. Entries in the Kerberos database are known as principals. The following example adds an admin instance for the user wvh:

   	# /usr/kerberos/sbin/kadmin.local
   	kadmin.local: addprinc wvh/admin
   	WARNING: no policy specified for wvh/[e-mail]; defaulting to
   	no policy
   	Enter password for principal "wvh/[e-mail]":
   	Re-enter password for principal "wvh/[e-mail]":
   	Principal "wvh/[e-mail]" created

6. Next, add a standard user entry for the non-admin version of the principal that you just created and then exit the kadmin.local utility, as in the following example:

   kadmin.local: addprinc wvh
   	WARNING: no policy specified for [e-mail]; defaulting to no
   	policy
   	Enter password for principal "[e-mail]":
   	Re-enter password for principal "[e-mail]":
   	Principal "[e-mail]" created.
   	kadmin.local: quit

   Adding a standard principal enables default authentication by the associated entity. You will eventually need to create a principal for each user that you want to be able to authenticate using Kerberos. (Most sites do this by writing a script that also creates Kerberos principals when creating standard user accounts.)

7. Now, the fun begins! Start the various Kerberos-related services using the following commands:

   	# /sbin/service krb5kdc start
   	# /sbin/service kadmin start
   	# /sbin/service krb524 start

At this point, you're ready to install and start a Kerberos client. However, before doing anything else, you should verify that your server can hand out tickets by using the kinit command to explicitly request one for the administrative principal that you created earlier. You can then use the klist command to verify its contents, and then destroy the ticket (just to clean up) using the kdestroy command. The following example shows this sequence:

	$ kinit wvh
	Password for [e-mail]:
	$ klist
	Ticket cache: FILE:/tmp/krb5cc_0
	Default principal: [e-mail]
	Valid starting		Expires		Service principal
	05/03/05 22:09:04 05/04/05 22:09:04 krbtgt/VONHAGEN.ORG/VONHAGEN.ORG
	Kerberos 4 ticket cache: /tmp/tkt0
	klist: You have no tickets cached
	$ kdestroy

Installing and Configuring Kerberos Clients and Applications

Many Linux distributions provide graphical utilities for configuring Kerberos clients, such as Red Hat's authconfig application and the Kerberos client configuration applets in SUSE's YaST tool. This hack explains how to do everything from the command line, in case you don't have access to such utilities. If you're using either of these systems, the graphical utilities simplify the installation and configuration processes, but it's always nice to know what's really required under the covers. You will still have to migrate your user, password, and group data into your Kerberos server manually, in any case.

To install and test the Kerberos client software, do the following:

1. Build and install Kerberos on the system, or install the krb5-libs and krb5-workstation packages on all client systems.

2. Copy the /etc/krb5.conf file from your KDC to the client's /etc directory.

3. Enable a sample application. I tend to use krb-telnet, a Kerberos-aware version of the classic telnet application, as a test application. The krb-telnet server is managed by your system's xinet daemon. To enable krb-telnet, modify the file /etc/xinetd.d, changing the disable entry from yes to no, as in the following example:

   	# default: off
   	# description: The Kerberized telnet server accepts normal telnet,
   	#			   but can also use Kerberos 5 authentication.
   	service telnet
   	{
   		flags = REUSE
   		socket_type = stream
   		wait = no
   		user = root
   		server = /usr/kerberos/sbin/telnetd
   		log_on_failure += USERID
   		disable = no
   	}

4. Restart your system's xinet daemon using the following command:

   	# /etc/init.d/xinetd.d restart

5. Telnet to your system and make sure that you can log in successfully. Once you have logged in, you can use the klist command to verify that you've automatically been granted the appropriate Kerberos tokens, as in the following example:

   	$ klist
   	Ticket cache: FILE:/tmp/krb5cc_p4979
   	Default principal: [e-mail]
   	 Valid starting		Expires		Service principal
   	05/07/05 10:00:46 05/08/05 10:00:46 krbtgt/[e-mail]
   	 Kerberos 4 ticket cache: /tmp/tkt500
   	klist: You have no tickets cached

Congratulations—Kerberos is working! The next step in this hack is to integrate Kerberos into your system's login authentication process.

Using Kerberos for Login Authentication

To enable Kerberos authentication on a client system, do the following:

1. Make sure you've built or installed the pam_krb5.so PAM module on all your client systems. If you are not using a package management system, you can obtain the latest version of the pam_krb5.so PAM at http://sourceforge.net/projects/pam-krb5/.

2. Verify that the /etc/krb5.conf file contains valid settings for PAM authentication, in the [appdefaults] section's pam subsection. Valid settings for Kerberos authentication via PAMs that match the examples used throughout this section are:

   	[appdefaults]
   		pam = {
   			debug = false
   			ticket_lifetime = 36000
   			renew_lifetime = 36000
   			forwardable = true
   			hosts = kerberos.vonhagen.org
   			max_timeout = 30
   			timeout_shift = 2
   			initial_timeout = 1
   		}

3. Add entries for krb5 authentication to the appropriate PAM configuration files on your system. As explained in [Hack #4] , some Linux systems use individual files to configure authentication for specific services, while others (such as Red Hat/Fedora) create a centralized file for system authentication called /etc/pam.d/system-auth. If you are using individual files, you must add the appropriate entries for LDAP authentication to login-related services such as login and Kerberized services such as rlogin and telnet. You should insert auth and account entries for the pam_krb5.so module before your system's generic Linux authentication checks, which are usually handled by pam_unix2.so (SUSE) or pam_pwdb.so (most other Linuxes). An example PAM file for the telnet service would look something like the following:

   	auth		required		/lib/security/pam_nologin.so
   	auth		sufficient		/lib/security/pam_krb5.so
   	auth		required		/lib/security/pam_pwdb.so shadow nodelay
   	account		sufficient		/lib/security/pam_krb5.so
   	account		required		/lib/security/pam_pwdb.so
   	password	required		/lib/security/pam_cracklib.so
   	password	required		/lib/security/pam_pwdb.so shadow nullok
   					use_authtok
   	session		required		/lib/security/pam_mkhomedir.so skel=/etc/skel/
   					umask=0022
   	session		required		/lib/security/pam_pwdb.so

4. If you are using a Red Hat or Fedora system, modify /etc/pam.d/system-auth to look like the following:

   	auth		required	/lib/security/pam_env.so
   	auth		sufficient  /lib/security/pam_unix.so likeauth nullok
   	auth		sufficient  /lib/security/pam_krb5.so use_first_pass
   	auth		required    /lib/security/pam_deny.so
   	account		required    /lib/security/pam_unix.so broken_shadow
   	account		sufficient  /lib/security/pam_succeed_if.so uid < 100 quiet
   	account		[default=bad success=ok user_unknown=ignore] /lib/security/
   				pam_krb5.so
   	account		required   /lib/security/pam_permit.so
   	password	requisite  /lib/security/pam_cracklib.so retry=3
   	password	sufficient /lib/security/pam_unix.so nullok use_authtok
   				md5 shadow
   	password	sufficient /lib/security/pam_krb5.so use_authtok
   	password	required   /lib/security/pam_deny.so
   	session		required   /lib/security/pam_limits.so
   	session		required   /lib/security/pam_unix.so
   	session		optional  /lib/security/pam_krb5.so

That's all you should have to do. Before logging out of the client, telnet or SSH to it and attempt to log in. If you have any problems with Kerberos login authentication, you can enable PAM debugging in your /etc/krb5.conf file so that you can quickly identify and resolve authentication-related problems with login and other system applications that use PAMs. To do this, simply set the debug entry to true in the PAM section of the [appdefaults] stanza and restart your Kerberos server.

Unfortunately, there is no automated mechanism for migrating existing user and password information to a Kerberos database. You will have to manually add principals for all of your groups and users to the Kerberos database on your KDC, and assign them default passwords. Users can subsequently change their passwords using the kpasswd command found in /usr/kerberos/bin.

See Also

• Kerberos: The Definitive Guide, by Jason Garman (O'Reilly)

• "Customize Authentication with PAMs" [Hack #4]