Howard Chu <hyc(a)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.19
All 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 , 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.)
 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.
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>