issue with MIT KDC and LDAP DS

[Ken Raeburn]

On May 22, 2009, at 18:04, Jeffrey Hutzelman wrote:
> - 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).

Doing things "in background" is a lot more complicated in a single- 
threaded process when the background task is defined entirely inside a  
plugin.  It may be a better way to do it in general, but Will's way is  
probably a lot simpler with the current code base.  And if the DS is  
on the same system, and running, the delay shouldn't be that large,  
and would only affect the very first request(s) received.

Longer term, the KDC does need work to allow more parallelism.  I'm  
not sure the database plugin API is a good place to add calls for  
doing processing of background tasks; I'd rather see it transparent to  
the main KDC code.  Several ideas that have been kicked around involve  
multiple threads or processes, and would allow, say, the LDAP database  
implementation to manage its own parallelism and background tasks  
without requiring hooks in the main KDC code.  If that sort of big  
restructuring project can be done, great!  I'd love to see it happen.

I'd add that it would be nice if a KDC connected to an LDAP server  
could detect that the server went down, too, and automatically try  
reconnecting, without needing to be prodded by Kerberos traffic to  
notice.  I'm not familiar enough with the LDAP APIs to know if that's  
practical.

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

Shouldn't KDC_ERR_SVC_UNAVAILABLE have that effect?  Sending that can  
let the client know to *immediately* try another KDC, instead of  
timing out.

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium