[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antwort: Re: SASL/GSSAPI auth stops working after slapd restart [Virus checked]

--On Thursday, March 11, 2004 1:39 PM +0100 denis.havlik@t-mobile.at wrote:

I presume that "broken threading" means that problems occur if/when two
authorisation requests come at a same time?

No, problems come simply as long as you have multiple connections, regardless of whether or not they are simultaneous.

What are exactly the type problems that can be expected from this side?

- slapd dies?

Yes, or it locks up.

- kerberos dies?

No, the libraries slapd uses to do kerberos authentication have nothing to do with the KDC (another thing I'm finding I have to say often).

- false positive results? (someone binds with false credentials)


 - false negative results? (temporarly unable to bind with right


- LDAP DB corruption?

Yes, if slapd locks up

- Kerberos DB corruption?

No, see above comment on the libraries

- other?

Memory leak problems that cause slapd to grow over time. When we initially used MIT KRB5 in our testing, we could routinely lock the server up within 4 minutes.

will also note that OpenLDAP 2.1.22 is old and was rather problematic,
and  there have been a lot of bug fixes since then.

I suggest you
A) Upgrade to a recent server version

OK, will try this first

B) Compile your server against Heimdal

From your old mails I understood that only slapd needs to be compiled against Heimdal libraries, while all the rest can remain as it is (i.e. MIT-centric). Is this correct?

Mostly. All the pieces the OpenLDAP server uses must use Heimdal (like cyrus-sasl) as well.

My general build order is:

cyrus-sasl (compiled against heimdal)
Berkeley DB
OpenLDAP (compiled against cyrus-sasl & heimdal)

Somewhat related question: I read something about Heimdal being able to
use LDAP as backend DB, or such, but can't find any good documentation on
this thema. Is this something one should seriously consider if/when
building LDAP+Kerberos auth. server?

I know it can be done, and is being done, but Stanford is an MIT KRB5 shop, and they don't see that changing.

I can kind of imagine that having keytabs and such in LDAP tree could
help in assuring that every host in the network accesses the same data,
and that this might cut down the synchronisation problems but...

I don't see how/where this conclusion is reached. ;) All of our applications have their own keytabs, and they use those keytabs for different data views into the LDAP servers. Hosts themselves have no access into the DB, other than my testing of syncRepl, which allows the replica's to use their host keytab to bind to the master for that process.


Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html