Re: Problems with SASL, TLS, etc.

["Nels Lindquist" <nlindq@maei.ca>]

On 29 Aug 2001 at 12:12, Kurt D. Zeilenga wrote:

> That's to use the Cyrus SASL secret store (sasldb) for simple
> authentication.

Okay... that seems to imply that slapd *will* use SASL for simple auth.  Is this only 
true for the 
rootpw?

> If you want to use SASL authentication, then
> you first need to get SASL working (start with Cyrus SASL
> sample client/server).  More details can be found in the archives
> (sorry, but that's the best docs we have right now) or various
> HOWTOs.  Note when using SASL authentication for the rootdn,
> one doesn't need to set rootpw.

So I can drop the "rootpw..." line entirely?

> >but it didn't seem to help.  I'd really like to implement ACLs for 
> >updating the LDAP server, etc. but I haven't been able to get any 
> >authentication past "rootpw    [plain secret]" to work at all.
> >
> >Where exactly is the SASL layer supposed to sit in the whole LDAP 
> >scheme?  Is it used for binding?
> 
> Yes.  It provides a framework for authentication.

Is it supposed to be involved at all when doing a simple bind?
 
> ldappassword uses a LDAP extended operation to change a password.
> In 2.0, it can only change simple authentication passwords (for
> hashed userPassword schemes only).

If there's some way of getting simple binds to be handled by SASL, I'd assume that 
lddappasswd becomes 
superfluous.  Is this correct?
 
> >How do I convince the server (and LDAP related utilities) to use SASL 
> >LOGIN or PLAIN methods?  I'd expect this to be necessary for (the 
> >majority of) clients which don't support SASL directly and are hence 
> >unable to use CRAM-MD5 or DIGEST-MD5.
> 
> If a client doesn't support SASL, then it doesn't support SASL/PLAIN
> or SASL/LOGIN.

It was my impression that applications utilizing SASL for authentication tend to 
handle plaintext 
authentication transparently (assuming SASL is compiled with plaintext methods at 
all).  Ie, the 
application's usual plaintext authentication method is still provided, but as a 
wrapper for SASL 
PLAIN/LOGIN.  For example, Cyrus IMAP, when acting as a POP3 server, doesn't require 
clients to know 
anything about SASL.  If all they can do is the usual POP3 USER/PASS dialogue, then 
that's what they get.  
The application then deals with the plaintext SASL authentication behind the scenes.  
Treating LDAP 
analogously, I'd assume that client applications which don't know about SASL would 
need to do a simple 
bind, but that slapd would then do the plaintext SASL interaction behind the scenes.  
That way, you'd 
still only need one place for password storage (ie, /etc/sasldb).

> >Perhaps I haven't configured the SASL plaintext logins properly for 
> >slapd.
> 
> Have you gotten the Cyrus SASL sample client/server to work?

I've never played with the sample client/server, but SASL is working just fine for 
IMAP/POP3 (CRAM-MD5, 
DIGEST-MD5, and LOGIN/PLAIN methods over SSL/TLS) and sendmail SMTP AUTH support.  
Additionally, with the 
ACLs on slapd set up for unrestricted access, the command-line utilities (ldapsearch, 
etc.) will still do 
SASL authentication (with CRAM or DIGEST MD5) by default and that's working just 
fine.  What more could I 
learn from the sample client/server?

> >What is the name of the slapd binary internally as far as 
> >SASL is concerned?  (Ie, what's the name of the [name].conf file 
> >which needs to be created in /usr/lib/sasl?
> 
> slapd... but SASL options can be configured via slapd.conf(5).

Okay... so where would the usual SASL settings such as pw_check_method and 
auto_transition go?

> Archives, howtos, and faq.  Submissions to the admin guide are
> welcomed.

Well, if I can figure out how this is supposed to work and actually get it working, 
I'd be happy to 
contribute something. :-)
----
Nels Lindquist <*>
Information Systems Manager
Morningstar Air Express Inc.