Kerberos with LDAP Backend on Ubuntu 12.04 - Part Four

Last time we walked through the things you need to have a running Kerberos server (using LDAP backend). Today we set up a client.
(Ez a cikk magyarul is olvasható.)
Log in to the client and do some installing:

sudo apt-get install libpam-krb5

Expect these two questions:
Default Kerberos version 5 realm: ITTHON.CUCC
Add locations of default Kerberos servers to /etc/krb5.conf? No

If you try to log in to the client you will see that you stay out. (Maybe LDAP will let you in when using the same passwords.) If your name server is logging the queries, you will see things like these:

query: _kerberos._udp.ITTHON.CUCC IN SRV + (192.168.56.101)
query: _kerberos._tcp.ITTHON.CUCC IN SRV + (192.168.56.101)

So let us set these things in our zone files paying special attention to the dots.

_kerberos._udp          SRV 0 0 88      ubuserver
_kerberos._tcp          SRV 0 0 88      ubuserver

Next step:

sudo service bind9 restart

(reload is not enough).
Try these commands on both the server and the client:

host -t srv _kerberos._udp.itthon.cucc
host -t srv _kerberos._tcp.itthon.cucc
host -t srv _kerberos._udp
host -t srv _kerberos._tcp

Is something is not working do not proceed.
Then go to the client and tail the file /var/log/auth.log . Log on as someone who has a Kerberos principal. Make sure that the file auth.log says you have been let in by Kerberos and not by LDAP:

ubuclient login[899]: pam_krb5(login:auth): user jdoe authenticated as jdoe@ITTHON.CUCC

If okay install the package krb5-user :

sudo apt-get install krb5-user

and try to do a klist with the user just logged in.
One more check: log in using a local account and issue kinit using a username with an existing principal.
Try and change the password using the command passwd . You will be asked for the Kerberos password, then the new password. Then you will get some cannot resolve servers for KDC in realm "ITTHON.CUCC"
Observing the name queries coming form our precious client in the bind logs you will see some new things to add to the zone:

ubuserver               A       192.168.56.101
_kerberos._udp          SRV     0 0 88 ubuserver
_kerberos._tcp          SRV     0 0 88 ubuserver
_kerberos-master._udp   SRV     0 0 88 ubuserver
_kerberos-master._tcp   SRV     0 0 88 ubuserver
_kpasswd._udp           SRV     0 0 88 ubuserver

Having done all this and issuing passwd you have a long pause then a different error message: Cannot contact for any KDC in requested domain. The long pause may give the hint that something timed out. A quick search on the net and you guess that _kpasswd._udp.itthon.cucc may not be listening on port 88. We do two portscans too (the point is in bold, no firewall on the server):

nmap ubuserver.itthon.cucc
Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-25 21:21 CEST
Nmap scan report for ubuserver.itthon.cucc (192.168.56.101)
Host is up (0.00096s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
53/tcp  open  domain
389/tcp open  ldap
464/tcp open  kpasswd5
749/tcp open  kerberos-adm

and:

sudo nmap -sU ubuserver.itthon.cucc
Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-25 21:22 CEST
Nmap scan report for ubuserver.itthon.cucc (192.168.56.101)
Host is up (0.000025s latency).
Not shown: 995 closed ports
PORT    STATE         SERVICE
53/udp  open          domain
67/udp  open|filtered dhcps
88/udp  open|filtered kerberos-sec
123/udp open          ntp
464/udp open|filtered kpasswd5

So let us rephrase the line of _kpasswd._udp in the zone file:

_kpasswd._udp           SRV     0 0 464 ubuserver

And lo and behold: you can change your password from the client.

Next step is to create and admin principal so you do not always have to use sudo kdamin.local. In a Kerberos system the admin principals by convention always end with /admin . Start kadmin.local and:

addprinc kerbadmin/admin

The principal we have just created has no special rights only its name is strange. The rights are stored in an ACL (Access Control List) file. But where is that file? This is the way to find out:

sudo cat /etc/krb5kdc/kdc.conf|grep acl_file

You we edit the file /etc/krb5kdc/kadm5.acl . We put just one line in:

*/admin *

This says that "all pricipals ending with /admin can do anything." Let us make this important change happen:

sudo service krb5-admin-server restart

Issue the command in bold. With kadmin it is pretty easy to see what I was writing about in my first Kerberos post when I warned everyone that Kerberos takes an awful lot of time to come really up. It can take long minutes after the (re)start of the admin server for this error message to disappear:

kadmin -p kerbadmin/admin
Authenticating as principal kerbadmin/admin with password.
Password for kerbadmin/admin@ITTHON.CUCC:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

Once it has started you will not have further troubles. Let us finally do some rampaging (on for testing of course:)):

kadmin -p kerbadmin/admin
Authenticating as principal kerbadmin/admin with password.
Password for kerbadmin/admin@ITTHON.CUCC:
kadmin:  change_password jdoe
Enter password for principal "jdoe@ITTHON.CUCC":
Re-enter password for principal "jdoe@ITTHON.CUCC":
Password for "jdoe@ITTHON.CUCC" changed.

So  kadmin is operational on the server.

On the client:

kadmin -p kerbadmin/admin
Authenticating as principal kerbadmin/admin with password.
kadmin: Missing parameters in krb5.conf required for kadmin client while initializing kadmin interface

So let us see what we need in the file /etc/krb5.conf :

• this is the whole file - for some reason you might get "kadmin: Improper format of Kerberos configuration file while initializing krb5 library", when copy-pasting but it works when typed
• do leave the editor open until you issued the first succesful kadmin as if the file appears to be incorrect sudo will give you segmentation faults and that is really bad

[libdefaults]
        default_realm = ITTHON.CUCC

[realms]
        ITTHON.CUCC = {
                admin_server = ubuserver.itthon.cucc
        }

Try the kadmin command we issued before. If it works we are happy.

Next time we ignite the overlay smbkrb5pwd .


Further reading:

http://www.opinsys.fi/en/setting-up-openldapkerberos-on-ubuntu-10-04-alpha-2-lucid-part-5-dns-settings
http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-install/Hostnames-for-the-Master-and-Slave-KDCs.html

http://www.linuxquestions.org/questions/linux-software-2/kerberos-mit-clients-cannot-find-administrative-server-through-dns-816684/