How to Build an Ubuntu 11.10 SBS (Small Business Server)

Part 4: Kerberos

It’s time to install and configure Kerberos.

sudo apt-get install krb5-kdc krb5-admin-server

The packages will automatically configure Kerberos for the correct realm from the information provided by Dnsmasq earlier in this guide. All we have to do is create the database for the realm using the following tool:

sudo krb5_newrealm

There will be a slight delay whilst the server gathers enough random data to continue, then you will be asked to enter a master key for Kerberos, make sure you use something secure and memorable.

To configure Kerberos for NFS later, we’ll need to create an admin user.

sudo kadmin.local

The following output should be observed:

Authenticating as principal root/admin@DANBISHOP.ORG with password.
kadmin.local: 

Enter the following:

addprinc dan/admin

Enter a password when prompted, then quit:

WARNING: no policy specified for dan/admin@DANBISHOP.ORG; defaulting to no policy
Enter password for principal "dan/admin@DANBISHOP.ORG": 
Re-enter password for principal "dan/admin@DANBISHOP.ORG": 
Principal "dan/admin@DANBISHOP.ORG" created.
kadmin.local: quit

We need to give dan/admin admin privileges by editing the access control list for Kerberos (/etc/krb5kdc/kadm5.acl) this file should contain the following:

# This file Is the access control list for krb5 administration.
# When this file is edited run /etc/init.d/krb5-admin-server restart to activate
# One common way to set up Kerberos administration is to allow any principal
# ending in /admin  is given full administrative rights.
# To enable this, uncomment the following line:
*/admin *

Note that the last line has been uncommented so that all /admin principals have admin rights. To get Kerberos to use the new ACL we need to restart it:

sudo service krb5-admin-server restart

Now we can test everything has worked with:

kinit dan/admin

Enter the password you set when requested then run klist:

klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: dan/admin@DANBISHOP.ORG

Valid starting     Expires            Service principal
02/05/11 19:57:24  02/06/11 05:57:24  krbtgt/DANBISHOP.ORG@DANBISHOP.ORG
	renew until 02/06/11 19:57:21

If you get output something like the above then congratulations, you have a fully functioning Kerberos Realm 🙂

To ensure that all services (samba for windows clients in particular) that might like to use your Kerberos realm in the future can do so, you should add your realm information to /etc/krb5.conf like so:

[libdefaults]
	default_realm = DANBISHOP.ORG

# The following krb5.conf variables are only for MIT Kerberos.
	krb4_config = /etc/krb.conf
	krb4_realms = /etc/krb.realms
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	allow_weak_crypto = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#	default_tgs_enctypes = des3-hmac-sha1
#	default_tkt_enctypes = des3-hmac-sha1
#	permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true

[realms]
        DANBISHOP.ORG = {
                kdc = neo.danbishop.org
                admin_server = neo.danbishop.org
                master_kdc = neo.danbishop.org
                default_domain = danbishop.org
        }

Finally, we can enable kerberos authentication to login to the server.

sudo apt-get install libpam-krb5
sudo pam-auth-update

Check that Kerberos and LDAP are selected as authentication methods to allow users to login/ssh into the server.