[Date Prev][Date Next]
Re: Problems with SASL, TLS, etc.
- To: openldap-software@OpenLDAP.org
- Subject: Re: Problems with SASL, TLS, etc.
- From: "Nels Lindquist" <firstname.lastname@example.org>
- Date: Thu, 30 Aug 2001 08:33:30 -0600
- Content-description: Mail message body
- Organization: Morningstar Air Express Inc.
On 29 Aug 2001 at 12:12, Kurt D. Zeilenga wrote:
> That's to use the Cyrus SASL secret store (sasldb) for simple
Okay... that seems to imply that slapd *will* use SASL for simple auth. Is this only
true for the
> 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
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
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.
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
> 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
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
> Archives, howtos, and faq. Submissions to the admin guide are
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.