Kerberos with LDAP Backend on Ubuntu 12.04 - Part Two

Last time we started to install MIT Kerberos planning to use our nice OpenLDAP server as a backend. We managed to add the kerberos-schema to the LDAP. Today we complete the server side install of MIT Kerberos V and we do some testing too.
(Ez a cikk magyarul is olvasható.)


Our first job is to have everything asked from us by the installer:

sudo dpkg-reconfigure debconf

Choose low priority. Next step is the instalation.

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

The answers (provided ur server is called ubuserver.itthon.cucc):

Kerberos servers for your realm: ubuserver.itthon.cucc
Administrative server for your Kerberos realm: ubuserver.itthon.cucc
Create the Kerberos KDC configuration automatically? Yes
Run the Kerberos V5 administration daemon (kadmind)? Yes
After answering all the questions the system comes up and suddenly we see the message:
krb5kdc: cannot initialize realm ITTHON.CUCC - see log file for details

Of course.

Edit the file /etc/krb5.conf :

[libdefaults]
        default_realm = ITTHON.CUCC

[realms]
        ITTHON.CUCC = {
                kdc = ubuserver.itthon.cucc
                admin_server = ubuserver.itthon.cucc
                default_domain = itthon.cucc
                database_module = openldap_itthon.cucc
        }

[domain_realm]
        .itthon.cucc = ITTHON.CUCC
        itthon.cucc = ITTHON.CUCC

[dbdefaults]
        ldap_kerberos_container_dn = cn=krbcontainer,dc=itthon,dc=cucc

[dbmodules]
        openldap_itthon.cucc = {
                db_library = kldap
                ldap_kdc_dn = "cn=admin,dc=itthon,dc=cucc"
                ldap_kadmind_dn = "cn=admin,dc=itthon,dc=cucc"
                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldap://ubuserver.itthon.cucc
                ldap_conns_per_server = 5
        }

[logging]
       kdc = SYSLOG:info:local1
       admin-server = SYSLOG:info:local2
       default = SYSLOG:err:auth

When ready, prepare the place in the LDAP for the new Kerberos-realm:

sudo kdb5_ldap_util -D cn=admin,dc=itthon,dc=cucc create -subtrees dc=itthon,dc=cucc -r ITTHON.CUCC -s

During the process you will see this:
Enter KDC database master key:

This is the time to provide the database Master Password It is a nice thing to have two names:) I myself happen to own two of them too. Anyway put the password into a secret place as most likely you will never need it and if you do you will not remember it for sure.

Check what we have done so far:

sudo ldapsearch -Y EXTERNAL -b cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc dn -Q -LLL

Next thing is to tell Kerberos the user name and tthe password to use when digging in the LDAP-tree (dig in a tree? not bad.). Where to put them? In the file /etc/krb5.conf you have an entry:

ldap_service_password_file = /etc/krb5kdc/service.keyfile

So maybe this is the place.

sudo kdb5_ldap_util -D cn=admin,dc=itthon,dc=cucc stashsrvpw -f /etc/krb5kdc/service.keyfile cn=admin,dc=itthon,dc=cucc

Three questions come:

Password for "cn=admin,dc=itthon,dc=cucc": 
Password for "cn=admin,dc=itthon,dc=cucc": 
Re-enter password for "cn=admin,dc=itthon,dc=cucc":

The first question asks for the password of the entity specified with the -D switch and the last two ask what to store in the file. They happen to be the same on my test system.

You can make changes in the file /etc/krb5kdc/kdc.conf but you do not need to. Maybe it is worth to take alook at it. Finally it is time to start the KDC and the admin server:

sudo service krb5-kdc restart
sudo service krb5-admin-server restart

UIn the syslog you will find lines like this:

<= bdb_equality_candidates: (krbPrincipalName) not indexed

If you have done the LDAP indexing a few days ago then this message is familiar to you and you will know what to do.

This is the first time to access your Kerberos system with a utility that can only run on our Kerberos server and only if you are root . Using this you can administer the server witjhout providing a password (bold lines tell you what to type in):

sudo kadmin.local 
Authenticating as principal root/admin@ITTHON.CUCC with password.
kadmin.local:  listprincs
K/M@ITTHON.CUCC
krbtgt/ITTHON.CUCC@ITTHON.CUCC
kadmin/admin@ITTHON.CUCC
kadmin/changepw@ITTHON.CUCC
kadmin/history@ITTHON.CUCC
kadmin/ubuserver.itthon.cucc@ITTHON.CUCC
kadmin.local:  quit

You realize the principal (kerberos user) we use to access the server (root/admin) does not even exist. You cannot see it in the list. That is why you have to use sudo and that is why you can issue it only locally.

Some tests to try the new toy: First we create a principal:

kadmin.local:  addprinc doggie
WARNING: no policy specified for doggie@ITTHON.CUCC; defaulting to no policy
Enter password for principal "doggie@ITTHON.CUCC": 
Re-enter password for principal "doggie@ITTHON.CUCC": 
Principal "doggie@ITTHON.CUCC" created.
kadmin.local:  quit

Do not have a heart attack seeing the WARNING. This is meant to be so. You can read about policies here.

With the currently logged on user issue the command:

kinit 
kinit: Client not found in Kerberos database while getting initial credentials

The above lines tell that you are trying to logon into the Kerberos system (too) and there is "no such user". (If you happen to use the username doggie when doing these tests you wil not get this error message.) Now issue the command:

kinit doggie
Password for doggie@ITTHON.CUCC: 
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: doggie@ITTHON.CUCC

Valid starting       Expires              Service principal
2012-04-25 13.58.14  2012-04-25 23.58.14  krbtgt/ITTHON.CUCC@ITTHON.CUCC
 renew until 2012-04-26 13.58.12

Now we use the principal doggie . This principal does exist and that is why we are being asked for the password. The command klist shows who we are and the lifetime of the TGT.
Now issue these commands:

kdestroy 
klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)

The fisrt command drops our Kerberos-identity. The second shows Kerberos does not know who we are.

Let us remove doggie as we cannot bear the barking:)

sudo kadmin.local
kadmin.local:  delprinc doggie
Are you sure you want to delete the principal "doggie@ITTHON.CUCC"? (yes/no): yes
Principal "doggie@ITTHON.CUCC" deleted.
Make sure that you have removed this principal from all ACLs before reusing.

If you restart the server machine at this point you will run into trouble as right before starting the LDAP server the Kerberos server will complain about not being able to connect to LDAP. I can kind of accept its reasons. Let us change the order of executing the startup scripts. Systems based on Debian tend to use runlevel 2 as default. Listing the directory /etc/rc2.d :

S18krb5-admin-server
S18krb5-kdc
S19slapd
S20libnss-ldap

Change it:

sudo mv /etc/rc2.d/S18krb5-admin-server /etc/rc2.d/S21krb5-admin-server
sudo mv /etc/rc2.d/S18krb5-kdc /etc/rc2.d/S21krb5-kdc

So we have an MIT Kerberos V running and it puts its stuff into the LDAP-tree. Next time we will be able to use our Kerberos password when logging in to our Kerberos-server.