Error messages

Greg Hudson ghudson at MIT.EDU
Sun Oct 13 14:00:46 EDT 2013


On 10/13/2013 07:53 AM, Rick van Rein (OpenFortress) wrote:
> 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?

We could use better documentation and error reporting for the LDAP back 
end, certainly.

>> 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.

kdb5_util displays this message before reading from /dev/random when 
creating a KDB, to try to increase the likelihood that the random data 
used for the initial keys is sufficient (although it's questionable how 
much we really improve the likelihood by doing so).  This can be very 
fast or very slow depending on the kernel state.  We don't have our own 
"random pool" object in the KDC architecture.  (We do have our own PRNG 
between the operating system and the Kerberos code--again, the utility 
of having this is questionable--but it's not user-visible in any way.)

> "krb5kdc: Invalid credentials - while initializing database for realm" error

> At loglevel 135, slapd tells me that "slap_access_allowed: auth access denied".

"Invalid credentials" is a string from the OpenLDAP library 
(corresponding to LDAP_INVALID_CREDENTIALS), not from our source code. 
We probably need to provide more context when presenting errors returned 
by ldap_sasl_bind_s(), instead of directly blatting the OpenLDAP message 
into the extended message.

> Still the same error from the KDC though.  Back to strace.

If you're seeing the same error message, then I believe you're still 
getting a failure binding to the LDAP server, although I don't know why 
you wouldn't see a corresponding message in the LDAP server logs.

> Thanks for confirming that suspicion.  Once per realm, I presume, as K/M is stored underneath the realm's LDAP node.

Each realm has a potentially different master key, yes.

The master key is stored in a stash file in the KDC directory.  The K/M 
entry in the database some information related to the master key, but 
does not contain the master key itself in a form that you could get at 
it without knowing the master password.



More information about the Kerberos mailing list