issue with MIT KDC and LDAP DS
Henry B. Hotz
hotz at jpl.nasa.gov
Fri May 29 18:45:49 EDT 2009
On May 28, 2009, at 9:16 AM, krbdev-request at mit.edu wrote:
> Date: Wed, 27 May 2009 13:19:11 -0500
> From: Will Fiveash <William.Fiveash at Sun.COM>
> Subject: Re: issue with MIT KDC and LDAP DS
> To: Ken Raeburn <raeburn at mit.edu>
> Cc: MIT Kerberos Dev List <krbdev at mit.edu>
> Message-ID: <20090527181911.GC12597 at sun.com>
> Content-Type: text/plain; charset=us-ascii
> 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
>> the current status, and should be implemented. Minor points: We
>> 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
> 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 generally prefer 2), but . . .
I might change my mind if Solaris 10 clients don't support
KDC_ERR_SVC_UNAVAILABLE properly. Solaris 9 is finally drifting out
of usage here. I expect to have to live with Solaris 10 for a long
(Way off-topic: would you rather I put my efforts into getting JPL to
pay to fix this issue than the other one? ;-)
Don't know about Windows, but the other client platforms I care about
are likely to support that error properly soon enough.
> I think consensus on this will influence the fundamental approach to
> modifying the KDC daemons to deal with KDB access errors.
> And to your point about DAL errors, I was also thinking that the DAL
> open function could return fatal and non-fatal errors and the
> krb5kdc/kadmind code could be modified to deal with non-fatal errors
> (stay up, log the error, have state that indicates initialization is
> complete, etc...).
>> Improvements like the "background" reconnection Jeff suggests would
>> also be good but can wait for later, and possibly be examined in a
>> larger-scale redesign.
> Will Fiveash
> Sun Microsystems Inc.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev