Errors Setting Up Kerberos

In this example the kerberos realm is EXAMPLE.COM. The master KDC is kdc1.example.com (10.10.11.20) and the slave KDC's are kdc2.example.com (10.10.11.21) and kdc3.example.com (10.10.11.22).

The operating system is RHEL. The kerberos packages were installed as rpm's.

Setting Up Master KDC Server

After the basic installation and configuration you can test the master KDC by doing a kinit from the command line on the master.

[root@kdc1 ~]# kinit lance

These are some of the errors you may get.

kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials

The application cannot find the kerberos server. Check firewall, DNS and /etc/hosts. I had this error when /etc/hosts had:

127.0.0.1	kdc1.example.com  localhost.localdomain   localhost

This was fixed by changing /etc/hosts to:

127.0.0.1	localhost.localdomain   localhost
10.10.11.20	kdc1.example.com 	kdc1

Propagating Database to Slave KDC Servers

Next you need to propagate the database from the master to the slaves. This is done by dumping the contents of the database to file then using a combination of kprop on the master and kpropd on the slave to build the slave's database.

[root@kdc1 ~]# kdb5_util dump /var/kerberos/krb5kdc/kdc.dump
[root@kdc1 ~]# kprop -f /var/kerberos/krb5kdc/kdc.dump kdc2.example.com

kprop: No route to host in call to connect while opening connection to kdc2.example.com

The kerberos server cannot find the slave KDC. Check firewall. kpropd on the slave uses port 754/tcp by default.

kprop: Connection refused in call to connect while opening connection to kdc2.example.com

kpropd on the slave is not running or you are trying to connect to the wrong port (default 754/tcp).

kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
Generic remote error: No such file or directory

No keytab file on the slave KDC. Create principals for master (host/kdc1.example.com) and slave (host/kdc2.example.com) KDC's and add to keytab file. *Securely* copy keytab file from the master to the slave.

kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
kprop: Ticket not yet valid signalled from server
Error text from server: Ticket not yet valid

Check that the time on the master and slave KDC's are synchronised.

kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
kprop: Generic remote error: Key version number for principal in key table is incorrect

This could be a little tricky. First check that the slave server does have the latest version of the pricipal in the keytab file.

[root@kdcslave ~]#  klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
...
   4 host/kdc2.example.com@EXAMPLE.COM
...

[root@kdcslave ~]# kadmin
Authenticating as principal kadmin/admin@EXAMPLE.COM with password.
Password for kadmin/admin@EXAMPLE.COM: 
kadmin: Password read interrupted while initializing kadmin interface
[root@kdc2 krb5kdc]# kinit lance
Password for lance@EXAMPLE.COM: 
[root@kdc2 krb5kdc]# kadmin
Authenticating as principal lance/admin@EXAMPLE.COM with password.
Password for lance/admin@EXAMPLE.COM: 
kadmin:  getprinc host/kdc2.example.com
Principal: host/kdc2.example.com@EXAMPLE.COM
Expiration date: [never]
Last password change: Tue May 14 15:29:49 EST 2013
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Tue May 14 15:29:49 EST 2013 (lance/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 4, aes256-cts-hmac-sha1-96, no salt
Key: vno 4, arcfour-hmac, no salt
Key: vno 4, des3-cbc-sha1, no salt
Key: vno 4, des-hmac-sha1, no salt
Key: vno 4, des-cbc-md5, no salt
Key: vno 4, aes128-cts-hmac-sha1-96, no salt
MKey: vno 1
Attributes:
Policy: [none]
kadmin:  q
[root@kdcslave ~]#

Notice that the KVNO's agree (they are both 4). So the error is not actually with the version number. On this occasion the problem was with the hostname. The host name of the slave server (currently kdcslave) must match the DNS and the reverse lookup (kdc2.example.com).

[root@kdcslave ~]# hostname
kdcslave.example.com
[root@kdc2 ~]# hostname kdc2.example.com
[root@kdc2 ~]# service kprop restart
Stopping Kerberos 5 Propagation Server:                    [  OK  ]
Starting Kerberos 5 Propagation Server:                    [  OK  ]

Database propagation to kdc2.example.com: SUCCEEDED

You did it. The database is now on kdc2.example.com.

Database propagation to kdc2.example.com and kdc3.example.com via cron job

Edit an save the following script as an executable.

#!/bin/sh
     
kdclist="kdc2.example.com kdc3.example.com"

/usr/kerberos/sbin/kdb5_util "dump /var/kerberos/krb5kdc/slave_datatrans"
     
for kdc in $kdclist
do
	/usr/kerberos/sbin/kprop -f /var/kerberos/krb5kdc/slave_datatrans $kdc
done

Edit your crontab and run it every hour/day.

[root@kdc2 ~]# crontab -e

# propagate KDC database to slaves every hour at 10 minutes to hour
50 * * * *      /var/kerberos/krb5kdc/propagate_kdb.sh

Setting up Slave KDC Server to Grant Tickets

krb5kdc: Cannot find/read stored master key - while fetching master key K/M for realm EXAMPLE.COM

[root@kdc2 ~]# service krb5kdc start
Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details
                                                           [FAILED]
[root@kdc2 ~]# tail /var/log/krb5kdc.log
krb5kdc: Cannot find/read stored master key - while fetching master key K/M for realm EXAMPLE.COM

The slave KDC does not have a stash file (.k5.EXAMPLE.COM). You need to create one:

[root@kdc2 ~]# kdb5_util stash
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key
Enter KDC database master key:
[root@kdc2 ~]# service krb5kdc start
Starting Kerberos 5 KDC:                                   [  OK  ]

krb5kdc: Can not fetch master key (error: Permission denied). - while fetching master key K/M for realm EXAMPLE.COM

[root@kdc2 krb5kdc]# service krb5kdc start
Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details
                                                           [FAILED]
[root@kdc2 krb5kdc]# tail /var/log/krb5kdc.log 
krb5kdc: Can not fetch master key (error: Permission denied). - while fetching master key K/M for realm EXAMPLE.COM

In this case the stash file existed and appeared to be accessible. Fixed in the same way as the previous example but a password was not required.

[root@kdc2 ~]# kdb5_util stash
Using existing stashed keys to update stash file.
[root@kdc2 ~]# service krb5kdc start
Starting Kerberos 5 KDC:                                   [  OK  ]

Miscellaneous

kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

[lance@client ~]$ kinit lance/admin
Password for lance/admin@EXAMPLE.COM:
[lance@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: lance/admin@EXAMPLE.COM

Valid starting     Expires            Service principal
01/08/08 14:22:07  01/09/08 13:47:58  krbtgt/EXAMPLE.COM@EXAMPLE.COM


Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[lance@client ~]$ kadmin
Authenticating as principal lance/admin@EXAMPLE.COM with password.
Password for lance/admin@EXAMPLE.COM:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

[root@kdc1 ~]# tail /var/log/kadmind.log
Jan 08 13:32:00 kdc1.example.com kadmind[17036](Notice): Authentication attempt failed: 130.102.113.139, GSS-API error strings are:
Jan 08 13:32:00 kdc1.example.com kadmind[17036](Notice):     Miscellaneous failure
Jan 08 13:32:00 kdc1.example.com kadmind[17036](Notice):     Clock skew too great
Jan 08 13:32:00 kdc1.example.com kadmind[17036](Notice):    GSS-API error strings complete.

In this case I received the error because ntpd on the kerberos server had crashed and slowly the time went out of synch with the other clients. Restarting ntpd fixed the issue.

Interestingly I could still kinit successfully.

I also got the same error when the server ran out of disk space.

Feb 04 09:30:54 leaf.imb.uq.edu.au kadmind[6035](Notice): Authentication attempt failed: 130.102.116.66, GSS-API error strings are:
Feb 04 09:30:54 leaf.imb.uq.edu.au kadmind[6035](Notice):     Unspecified GSS failure.  Minor code may provide more information
Feb 04 09:30:54 leaf.imb.uq.edu.au kadmind[6035](Notice):     Can't write to replay cache: No space left on device

kadmin: Permission denied while initializing kadmin interface

[fred@client ~]$ kadmin -k -t /etc/lance.keytab -p lance/building.example.com -q 'cpw -pw ********* l.rathbone'
Authenticating as principal lance/building.example.com with keytab /etc/lance.keytab.
kadmin: Permission denied while initializing kadmin interface

You don't have permission to read the keytab file /etc/lance.keytab. Either su to a different user (this was the problem in this case - "fred" did not have permission to read /etc/lance.keytab) or change the permissions on /etc/lance.keytab (NOT a good idea - this is equivalent to giving you password away. It is likely if "fred" can read it so can others).

This could also be a issue involving SELinux and the context type.

[root@client ~]# ls -lZ /var/www/lance.keytab 
-rw-------. apache apache unconfined_u:object_r:user_tmp_t:s0 /var/www/lance.keytab
[root@client ~]# restorecon /var/www/lance.keytab
[root@client ~]# ls -lZ /var/www/lance.keytab 
-rw-------. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/lance.keytab
or
[root@client ~] chcon -t httpd_sys_content_t /var/www/lance.keytab

Author: Lance Rathbone
Last modified: Thursday February 04, 2016

Home