Re: LDAPv3 a nightmare

[Stephan Siano <stephan.siano@suse.de>]

Eric G Ortego schrieb:
> I think I would like to use openldap, but
> After a couple of weeks of reading up on it and trying to get a 
> directory "working" I have come to the conclusion that cyrus-sasl sucks.
> Even worse seems [its|my] attempt to use kerberosv5 and function.
> Mabe I am the fool and simply cannot get these three to play together 
> nicely but, holy shit how convoluted is this whole LDAPv3?!
>
> Do I need a ldap directory working to get sasl binds tested or working?  
> Do I also need a user in LDAP  and sasldb?
> Do I need plain passwords in the ldap directory (do I even have users in 
> the directory yet) to take advantage of "secure" authentication with 
> sasl and avoid doing "simple" binds to ldap or useing the sasldb?
> Do I need a kerberos kdc working to test if sasl [can|might] work with 
> ldap kerberos binds?
> How the hell am I suposed to get a client , say mozilla, to bind to ldap 
> with [kerberos tickets | sasldb username | a username] anyway?
> And why does sasl use pam?
>
> I don't see how it all ties together.

Well, most of your questions above may be ansewed by "this depends..." :-)

Maybe the following explanation may clear things up a little for you:

The whole issue you have is about authentication.

- LDAP V3 can do the authentication to the LDAP-Database itself (via a 
simple bind). In this case you need the userPassword attribute in your 
LDAP-Database and you should make sure that you use TLS for encryption 
(otherwise your password goes over the wire in the clear). A lot of 
applications that use LDAP are only capable of simple authentication 
(that was already ther with LDAP V2).
If this is what you want, you won't have to bother about SASL at all.

- LDAP V3 can also delegate the authentication to the SASL library.

SASL supports different authentication mechanisms:
+ a set of challenge/response and related mechanisms (CRAM-MD5, 
DIGEST-MD5 and others). If you want to use any of them, you need the 
username and the password on the server. The default storeage for this 
is the sasldb, but as far as I know, with newer OpenLDAP- and 
SASL-Versions it is also possible to store these passwords in the 
Directory itself (I haven't tried that).
+ GSSAPI is SASL authentication via Kerberos 5. You need a working 
Kerberos 5 infrastructure for this and the keytab for the 
"ldap/your.ldap.host@YOUR.REALM" principal readable for the LDAP server.
In this case your uid (called principal here) and password are stored by 
the KDC. You won't need a sasldb and you don't need a userPassword 
attribute if you don't also want to do simple authentication.
+ SASL has also cleartect authentication mechanisms. They also support 
PAM, but they are disabled for OpenLDAP, so you won't need this in this 
context (and ist doesn't make sense, if you want cleartext 
authentication use the simple bind).


> <rant>
> kerberos has a db, ldap has a db, sasl has a db, and they all seem to 
> interoperate in some twisted formula called LDAPv3.
> I thought the idea of a directory was to consolidate information in a 
> central location not smear user:pw databases all over!

Well, you can get along with a single db, if you want. Either use only
simple authentication (and ignore SASL completely) or use GSSAPI and
Heimdal as Kerberos implementation and store the kerberos db in the 
directory...

If you want to set the whole thing up, I would recommend to do the stack 
fromt the bottom to the top.

First set up the Kerberos stuff (if you want that).
When that runs, set up and test SASL (with the test clients and servers).
Finally you can set up the LDAP-server. That shouldn't make too much 
troble when everything else works...

Yours
Stephan Siano
--
----------------------------------------------------------------------
Dr. Stephan Siano, Consultant
SUSE LINUX AG, Mergenthalerallee 45-47, D-65760 Eschborn
T: +49 (0) 6196 5095131
F: +49 (0) 6196 409607    - stephan.siano@suse.com
----------------------------------------------------------------------