Error messages

[Rick van Rein (OpenFortress)]

Hello Greg,

Thanks so much.  The documentation leaves me puzzled, but you surely compensate for it.  Even in the weekend!

I've progressed (and documented it, hopefully serving others) but I get stuck in the KDB/LDAP code.  Are there any requirements from my configuration or environment in krb5_ldap_db_init()?  Is the only way left to recompile and single-step with a debugger?

>> * I seem to need to run "kdb5_util create" to construct a principal file with a random pool, even when running on an LDAP backend
> 
> This should not be required.

I introduced it in response to the errors I got starting KRB5.  Reproduced below.

> A "principal file" sounds like a DB2 database (since the DB2 KDB module uses the default base name of "principal" inside the KDC directory), which you aren't using.

I thought so, but the tools made me add it, as stated above.

Having that soldily confirmed now, I dropped the principal file, and its mention as database_name in kdc.conf, I removed the principal file and the stash file for another iteration.

> A "random pool" doesn't sound like anything in our KDC architecture.

This was my suspicion based on kdb5_util_create's "Loading random data" which takes long.  I assumed to fill a PRNG's pool, but it could just as well be a salt to the following "Initializing database" and "master key name 'K/M".  What made me suspicious was that it also said "You will be prompted for the database Master Password." -- glad I at least understood that.

Now, all I have to do is "krb5_ldap_util -D … -s -r …".  No problem there, the LDAP structures are created.

Then, starting the KDC I get to the vague message that I mentioned before,
krb5kdc: No such file or directory - while initializing database for realm
but at least this one can be subjected to strace, and the last ENOENT is on "/etc/krb5kdc/principal" which I managed to bypass with the database_name setting and "db5_util create".

As you make clear, I am misguided in doing that.  Good to know.

So why is it trying to open the db2 file?  Looking further back in the strace, I find that it does indeed load ".../krb5/plugins/kdb/db2.so" which it shouldn't as you say.  So, my backend settings didn't arrive.

I removed "database_module = ldap_backend" from [dbdefaults] and moved it into the [realms] config for the realm at hand, in krb5.conf.  This stops it from trying to load db2, and uses ldap instead.  Cool :) but it still produces the same "krb5kdc: Invalid credentials - while initializing database for realm" error that may have stopped me from exploring this path before.  As I said when I started this thread, error messages are not always helpful in diagnosing problems.

Getting over that, I looked into the strace again, found an LDAP exchange preceeding this error, and figured out the LDAP logs are now going to be helpful.

At loglevel 135, slapd tells me that "slap_access_allowed: auth access denied".  Aha, now it is an ACL problem!  (Please note how more detailed error messages from the KDC would have sent me there right away.)  [split, splot] "auth access granted".  Cool.

Still the same error from the KDC though.  Back to strace.  No sign of trouble this time, almost immediately after authentication it decides it won't continue.  Desparate.  Source code.  Need to look into krb5_db_open: lib/kdb/kdb5.c.  Probably v->init_module.  plugins/kdb/ldap/ldap_exp.c: krb5_ldap_open -> plugins/kdb/ldap/libkdb_ldap/kdb_ldap.c. Probably krb5_ldap_db_init() or krb5_ldap_read_startup_information().  The first comes down to connect & bind, which is okay'd by LDAP, so it should be the second?  But here I'm lost.  The fact that there's no extra information in the error message might be a hint…?

>> * This asks for initialisation of the master database key /again/ which I fill with the same value as for "kdb5_util create"
> 
> You should only be prompted for the master key once, if you omit the unnecessary first command.  (kdb5_util create does not take an argument, so the filename you entered there isn't used.)

Thanks for confirming that suspicion.  Once per realm, I presume, as K/M is stored underneath the realm's LDAP node.  Which is good -- it means that a realm can probably be migrated elsewhere without leaking credentials to the rest of the realms.

>> * The KDC key is translated to 1008 bits (?), the Kadmin key is only mapped to hex (?!?)
> 
> Both the KDC and kadmin passwords should only be mapped to one line containing the DN and a hex password.  If you are seeing binary data ahead of that, then you accidentally appended the LDAP password line to the master key stash file (which is a common mistake, partly because "stashsrvpw" is an unfortunate command name).

I regenerated them and now the KDC has shrunk in size, indeed.  Thanks.

I'm documenting this in detail in the hope it can also help others (using a search engine like I have).  I also hope that my remarks (about error messages) can help to improve the usability of Kerberos a bit.

Thanks for your help Greg!

Cheers,
 -Rick