3

I updated my master key for my Kerberos 5 server following the MIT Kerberos 5 instructions. I restarted the kdc and kadmind services and used krb5-prop to push the changes to the other servers.

Now I am unable to connect with kadmin from any server, including the admin server:

$kadmin
Authenticating as principal jacob/[email protected] with password.
Password for jacob/[email protected]:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

From my searching I've found that a common reason for this is time syncronization issues, but the machines are matching within a second and it fails even from the server running kadmind.

I'm not sure how to troubleshoot this. My version of kadmind doesn't have any kind of debug argument or verbose logging level that I've found. I've tried running it from the command line with -nofork and it's very quiet there.

The password is accepted. I can kinit as the target principle and if I type the password wrong it tells me.

kadmin: Incorrect password while initializing kadmin interface

If The kadmind service isn't running it also gives a different error.

kadmin: Communication failure with server while initializing kadmin interface

I didn't test kadmin just before updating the master password, but I've used it recently and no other configuration changes have been made. I've tried checking my key version numbers (kvno) and they appear to be correct.

What else could be causing this? Where else can I check? How can I debug kadmind?

Debian 8, krb5-admin-server 1.12.1.

6
  • 1
    The issue is more often than not time synchronization. 'Within a second' is not good enough. Set up NTP.
    – user143703
    Sep 17, 2016 at 1:20
  • 1
    @yoonix While NTP is definitely a good idea, "within a second" is usually good enough for mit Kerberos 5. clockskew defaults to 300 seconds.
    – 84104
    Sep 17, 2016 at 9:30
  • admin_server is kadmind, which is what kadmin interacts with. web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/…
    – 84104
    Sep 17, 2016 at 9:44
  • 1
    In a business / professional environment, a system using Kerberos should have NTP or some other method keeping them in sync. While it may work with 300 seconds, not setting it up is an incomplete configuration in my opinion. There's no reason not to. Eyeballs (manual verification) should not be a source of time sync. Eyeballs miss little inconsistencies like time zones.
    – user143703
    Sep 17, 2016 at 18:16
  • I cannot connect with kadmin from the admin server. I ssh to the server running kadmind, and try to run kadmin and get the same error. I expect no time drift between the kadmin client and the kadmind server running on the same system.
    – jla
    Sep 19, 2016 at 14:57

3 Answers 3

6

I've run into the same problem (same Debian and krb5-admin-server versions).

The same as you, it wasn't working when I ran kadmin from the kerberos admin server itself, which rules out time differences (I even installed NTP to make sure - it made no difference to the problem).

In my case the issue turned out to be that of entropy. Kadmin being very secure requires a lot of entropy to generate the session keys.

My setup (a test setup) is running on virtual machines. I would find that I couldn't kadmin at all, but after around half an hour kadmin would 'mysteriously' start working.

You can check the system entropy at:

/proc/sys/kernel/random/entropy_avail

To remedy the problem I made use of the host computer's entropy (/dev/random), and using rng-tools made this available to kadmin.

As an aside, for general kerberos troubleshooting you can look at:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/troubleshoot.html

Something such as the following will send trace logging to stdout allowing you to see what is going on in detail:

env KRB5_TRACE=/dev/stdout kadmin -p johndoe/[email protected]

1
  • I believe this is the most likely explanation. I had just rekeyed the database and that probably used up all the entropy and the kadmin server is running in a kvm virtual machine. Trying this morning it 'mysteriously' works everywhere it wasn't working last week. It might explain why a couple of times kadmind took forever and even a SIGKILL to terminate it, probably blocked waiting for entropy. Too bad it isn't a little verbose into the logs about this.
    – jla
    Sep 19, 2016 at 15:20
1

Check that you have opened kdc ports on the server (749 by default, both tcp and udp) and that the client can connect to it. This was the problem for me that resulted in kadmin: Communication failure with server while initializing kadmin interface error.

0

I encountered this error after upgrading from krb5 1.17 to 1.18, and for me the answer ended up being that I needed to comment out supported_enctypes in my kdc.conf, per: https://forum.ubuntuusers.de/topic/krb5-admin-server-startet-nicht-mehr/#post-9160670 (German).

I think this is related to removing single-DES in krb5 1.18. My config that came from previous default settings and had been working for 1.17 was:

supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3

https://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html

I'm betting I probably could've just removed the single-DES entries from that list, but in this case it's probably better to just use the newer defaults that use stronger AES crypto.

So in certain cases this error can actually mean excess kdc.conf parameters instead of missing parameters. It would be great if it could tell you which parameters are problematic instead of making you guess.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .