[Date Prev][Date Next]
Re: Antwort: Re: SASL/GSSAPI auth stops working after slapd restart [Virus checked]
--On Thursday, March 11, 2004 1:39 PM +0100 email@example.com 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
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
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)
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.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html