Ticket 5338: Race conditions in key rotation

[Jeffrey Altman]

Ken Raeburn wrote:
> Certainly we're going to need to address the fact that talking to an 
> LDAP server or other database back end may not be instantaneous.  And 
> other possible extensions being discussed at the IETF will also 
> require the KDC to wait for some external service.
To give you some idea of the types of delays you should be prepared for.
When I was working on the KCA code we found that Active Directory
could take as long as 60 seconds to respond to an LDAP query requesting
the display name associated with a Kerberos principal under certain load
conditions. 

Not only did the KCA have to become threaded but it had to become
stateful in order to permit threads to queue up requests, send queries
to the LDAP server, and then be re-purposed until such time as the
query results were available.  Blocking threads on the LDAP query
simply will not scale.

To ensure reasonable performance caused by multiple requests for the
same user logging into multiple machines at the beginning of the day,
LDAP responses were cached for five minutes.  This was necessary
in order to avoid overwhelming the LDAP servers.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080624/43cfd02a/attachment.bin