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 (if you have a mouse connected to the server, you will dramatically speed up this process by moving it in circles now) 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

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

Congratulations, you have a fully functional Kerberos domain!

Authentication on the Server

Although we don’t have any domain users yet (that comes in step 6!) we can set the server up to accept them for login now that we have LDAP and Kerberos up and running.

This is done using SSSD.

sudo apt-get install sssd

SSSD is essentially magic. It will set it self up from everything else we’ve already configured at this point… the only thing to do is tell it that we’re not using TLS for LDAP. We do that by editing /etc/sssd/sssd.conf:

sudo nano /etc/sssd/sssd.conf

Change the line “ldap_tls_reqcert = demand” to:

ldap_tls_reqcert = never

Kerberised SSH

As kerberos logins now work on the server, you might want to enable kerberised ssh so that when users are logged into client machines, a simple “ssh neo” will have them logged straight in without requiring their password again.

First edit /etc/ssh/sshd_config and change GSSAPIAuthentication from no to yes. Leave all other Kerberos options as their defaults.

sudo nano /etc/ssh/sshd_config

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Now we need to create a kerberos principal for the SSH service to use:

sudo kadmin.local -q "addprinc -randkey host/neo.danbishop.org"
sudo kadmin.local -q "ktadd host/neo.danbishop.org"

Reload the SSH configuration and you’re done!

sudo service ssh reload