issue with MIT KDC and LDAP DS

[Will Fiveash]

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.

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/