issue with MIT KDC and LDAP DS

[Jeffrey Hutzelman]

--On Friday, May 22, 2009 07:40:33 PM -0400 Ken Raeburn <raeburn at mit.edu> 
wrote:

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

True.  I don't know enough about the implementation to determine whether 
handling reconnection attempts without blocking request processing would be 
easy or hard, or whether it would require adding or modifying a plugin 
interface that you'd rather not deal with right now.

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

Unfortunately, that error wasn't defined in RFC1510, and there are still 
clients deployed which don't behave that way, and which treat _any_ error 
response from a KDC as that realm's final word on the request 
(particularly, any response at all from a KDC is enough to escape 
send_to_kdc).  For example, I don't know if current versions of Heimdal 
handle this correctly, but I know we have clients deployed that do not.

-- Jeff