issue with MIT KDC and LDAP DS

[Simo Sorce]

On Fri, 2009-05-22 at 18:04 -0400, Jeffrey Hutzelman wrote:
> --On Friday, May 22, 2009 03:57:58 PM -0500 Will Fiveash 
> <William.Fiveash at Sun.COM> wrote:
> 
> > I'm looking for input regarding my changing the following behavior of
> > the krb5kdc and kadmind.  Currently, when a KDC is configured to use the
> > LDAP KDB plugin and krbr5kdc is started prior to the DS being on-line,
> > the krb5kdc exits immediately with an error.  I want to change this
> > behavior so krb5kdc (and kadmind) stays up even when the DS is off-line.
> > The idea is that LDAP bind errors such as LDAP_SERVER_DOWN and
> > LDAP_CONNECT_ERROR would be treated as non-fatal in
> > krb5_ldap_initialize().  krb5kdc would daemonize itself as it normally
> > does but if there were no DS server connections up would try to bind
> > with a DS when it receives krb requests.  If it is unable to bind it
> > would send an error response to the *_REQ requester and wait for the
> > next request whereupon it would try to bind again.
> >
> > The kadmind would behave similarly, sending back errors until it was
> > able to bind to the DS.
> >
> > Thoughts?
> 
> This sounds good in general, but I'd make a couple of changes...
> 
> - Instead of attempting a bind when the KDC receives a request and
>   doesn't currently have a connection, it should periodically try
>   in the background, and simply fail immediately if it gets a request
>   and there is no connection.  Otherwise, the KDC may take a long
>   time to process each request, causing it to take much longer to
>   process requests than clients are willing to wait, and falling
>   behind (i.e starting to process a request when it is already very
>   old).
> 
> - Instead of returning an error when there is no connection, the KDC
>   should probably just drop the request on the floor.  This doesn't
>   sound very friendly, but there is no other way to signal to clients
>   that they should try another KDC.

Totally agree on both comments, and I'd love to see this implemented.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York