Howard Chu hyc@symas.com writes:
Wes Modes wrote:
Specifics of my configuration:
* OS: Red Hat Enterprise 4 v2.6.9* OpenLDAP v2.2.13 * Local MIT Kerberos5 v1.3.4 * KDC: MIT Kerberos5 v? * Cyrus SASL v2.1.19All of these versions are far outdated, and MIT Kerberos is known to be unsafe in a threaded environment (and yes, OpenLDAP slapd is threaded).
That is definitely true of that version of MIT Kerberos, which if I recall correctly made no attempt at thread safety whatsoever.
The MIT Kerberos team believes that they've fixed all the thread safety correctness bugs, within the thread safety guarantees that the library attempts to provide [1], in the current release (1.6.3) and would welcome bug reports for any remaining problems. I believe that OpenLDAP does meet the prerequisites for using MIT Kerberos safely.
You may still want to use Heimdal for *performance*, however, or disable the replay cache on MIT Kerberos (Heimdal doesn't, or at least didn't, implement one). The replay cache is known to have extremely poor performance in threaded environments and with lots of authentications.
(I'm not an MIT Kerberos developer apart from occasional minor fixes and Debian packaging, but I follow their development closely and Stanford is a Kerberos Consortium member.)
[1] MIT Kerberos only supports thread safety provided that no single krb5_context is used from multiple threads. Each thread needs to have its own krb5_context. In a GSSAPI context, this means that you must ensure that only one thread uses each GSSAPI security context.