[Date Prev][Date Next]
Re: LDAPv3 a nightmare
>>>>> "Eric" == Eric G Ortego <firstname.lastname@example.org> writes:
Eric> I think I would like to use openldap, but After a couple of
Eric> weeks of reading up on it and trying to get a directory
Eric> "working" I have come to the conclusion that cyrus-sasl
Eric> sucks. Even worse seems [its|my] attempt to use kerberosv5
Eric> and function. Mabe I am the fool and simply cannot get
Eric> these three to play together nicely but, holy shit how
Eric> convoluted is this whole LDAPv3?!
It's just a matter of 'compile/install order'. Once you understand
how it's SUPPOSED to work, it reasonably easy to figure out the compile
It's a little dated, but there's basically nothing in there that DOESN'T
work with OpenLDAP 2....
Eric> I don't see how it all ties together. <rant> kerberos has a
Eric> db, ldap has a db, sasl has a db, and they all seem to
Eric> interoperate in some twisted formula called LDAPv3.
He. Calm down, have a coffee and take a walk in the sun shine outside :)
It's "unfortunate" that there's TWO (not three, the SASL one isn't used),
but the rationale is that LDAP is good at it's thing and Kerberos is
good at it's... This helps SOMEWHAT to alleviate the pain to administrate
And when/if you start using AFS you get a third one, so don't complain! :)
Eric> I thought the idea of a directory was to consolidate
Eric> information in a central location not smear user:pw
Eric> databases all over!
Yes. If you take the M$ route (I'm talking about Active Directory here
of course) then you're right. But they TO uses two databases. You just
don't see it that way because of the Admin interface to it...
Eric> And if kerberosV5 is soo freakin badass then why the
Eric> hell don't many applications make use of it?
Probably because it's quite complicated to CODE for. There's a LOT of
security concerns to think about BEFORE starting a project that utilises