Ubuntu 12.04 Ultimate Server Guide

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
  • Christian Oswald

    Hello,
    it’s a very useful tutorial and I learned a lot from it.
    I had also the problem with “Error adding group domainusers to LDAP” and in my case I solved it with switches TLS off in the LDAP-Server. I made it with webmin because I can’t find the correct place for it in the configuration files. I think it depends from the defaults of the ubuntu installation (in my case 14.04).
    But I have also a problem with the kerberos authentification. It works nice on the server (kadmin.local runs, kinit brings a ticket …) but from a client I get all times the error “kadmin: Cannot contact any KDC for requested realm while initializing kadmin interface”.
    I have reinstalled all, checked the configuration file of dnsmasq, krb5 … nothing helps, no firewall runs …
    I have tested a lot – ping, nslookup works and give the correct server. But nmap said that only port 749 is open on the server but in the kdc.conf is written that port 750 and 88 is used. I don’t if it’s important.
    Has anyone any idea for the reason of this error?

    Thanks,
    Christian

  • Jezzirolk

    hey Dan, i have used your guides a few times and they are great. Still work with 14.04 i dont think there was any tweaking i really had to do. i have a question though, is there a reason you disabled cache_credntials. Not saying there arent possible security reasons but i was more curious if there were other technical reasons becasue when connecting a laptop it is providing to make this a bit harder.

    –jezzirolk

    • danbishop88

      Hi Jezzirolk,

      I believe my reason for this was to do with: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1039151

      Basically, without it SSSD tends to come up before your network connection. This forces it into “offline” mode and it won’t even try to reconnect to your ldap/kerberos server until two minutes have elapsed. This prevents anyone from logging in for the full two minutes.

      A better workaround is listed in that thread, which is forcing the login screen to wait for the network to come up before appearing. I intend to move to that if I ever get round to finishing my 14.04 guide.

      Hope that helps…

      Dan

      • Jezzirolk

        Hey Dan,
        this still doesn’t really solve the issues i think, waiting for the network doesn’t do much for my case of a laptop. if i am off site it still wont connect properly unless you try to use cached credentials. Are we saying use cached credentials and then wait for network as to prevent the false negative of can not connect to ldap server? if that’s the case that might work.

        i guess the better question is if i log in off line. how does reconnecting once we end up back on a network with access to the server?

        Any thoughts on this and how to deal with the NFS mounts with laptop or systems that end up off site.

        –jezzirolk