issue with MIT KDC and LDAP DS

[Jeffrey Hutzelman]

--On Wednesday, May 27, 2009 01:19:11 PM -0500 Will Fiveash 
<William.Fiveash at Sun.COM> wrote:

> On Tue, May 26, 2009 at 07:17:19PM -0400, Ken Raeburn wrote:
>> BTW, getting back on track with Will's idea:
>>
>> As originally stated, I think it's a good idea and an improvement over
>> the current status, and should be implemented.  Minor points: We might
>> want the option for the KDC to be silent instead of returning an
>> error.  And, as I mentioned in a paragraph buried in the middle of my
>> Saturday ramblings^H^H^H^H^H^H^H^H^Hemail, LDAP server unavailability
>> might be a "tempfail" situation, but I think we still want hard
>> failures (i.e., KDC errors out) for cases like the DB2 database not
>> existing, or the LDAP server being available but the KDB data not
>> being there.
>
> A question regarding fundamental krb5kdc behavior; which of the
> following do people consider preferable behavior?
>
> 1. The krb5kdc exits when it encounters an error accessing the KDB thus
>    clients that send it krb requests via UDP then rely on timeouts to
>    indicate it should fall back to trying other KDCs.
>
> 2. The krb5kdc stays up when it encounters an error accessing the KDB
>    and sends clients KDC_ERR_SVC_UNAVAILABLE immediately when receiving
>    krb requests.  If the client handles KDC_ERR_SVC_UNAVAILABLE it
>    can immediately try other KDCs.
>
> I think consensus on this will influence the fundamental approach to
> modifying the KDC daemons to deal with KDB access errors.

If the KDB is unavailable, but might become available, for example because 
it is stored in some database service that is currently down or 
unreachable, then the KDC should report failures to clients so they can try 
other KDC's.  Similarly if the KDC is temporarily unable to provide service 
for other reasons, such as the master key living on a hardware token that 
is currently unavailable (as a variation on that, my KDC's require someone 
to show up with a hardware token to decrypt the master key, which is then 
kept in memory).  In fact, in general this approach should apply to 
temporary conditions that may appear and disappear after the KDC has 
started.

If the KDC is misconfigured and cannot possibly function correctly without 
the intervention of an administrator, then it should simply fail to start. 
This is consistent with what administrators expect of other services, and 
allows startup scripts to report failure of the KDC to start, instead of 
reporting that it started successfully when in fact it cannot possibly 
provide service.

-- Jeff