issue with MIT KDC and LDAP DS

[Henry B. Hotz]

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

(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  
> not
> 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.
>
> Agreed.
>
> --
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/

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