RE: openldap + DIGEST-MD5 + PAM

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of
> bulk@alfredsson.org

> Hello,
>
> After avoiding SASL for half a year and using -x instead, I gave it a
> shot. What I want;
>
> - use ldapsearch/other tools on one machine, and avoid sending the
>   password in plaintext to the server
> - the password should be stored in one place, ie the ldap directory
>
> I have a working setup with openldap, nss_ldap and pam_ldap.
>
> So, these steps were done to add SASL capabilities
>
> - in order to get DIGEST-MD5, i created /etc/sasldb by saslpasswd
> dummyuser
> - I do not want to set a password manually in sasldb, so I created
>   /usr/lib/sasl/slapd.conf containing pwcheck_method: pam
>
> If I issue ldapsearch -x -L -s "base" -b "" supportedSASLMechanisms
> I get the expected mechanisms as supported;
>
> dn:
> supportedSASLMechanisms: GSSAPI
> supportedSASLMechanisms: DIGEST-MD5
> supportedSASLMechanisms: CRAM-MD5
>
>
> However, since I specified it to use PAM, it needs a service defn in
> /etc/pam.d/slapd (?). So I simply used the servicedefition used
> by sudo, since
> it was quite generic, and works with my pam setup.
>
> Anyway, it does not work :) -- if I strace slapd, I can see that it (or
> rather sasl) is opening /var/lib/sasl/slapd.conf and reading the config.
> Then I would expect PAM stuff to be opened/read, but it is not
> happening. However if I add my user to sasldb, it works fine.
>
> Does someone have any idea of what could be wrong?
> Or, tips on howto debug sasl to see what it does. No PAM errors are
> shown in the logs, btw.
>
> The passwords are stored hashed (crypt) in the directory, does the
> DIGEST-MD5 mech work with this, or does the server need the password
> as plaintext (i.e. could explain why sasldb works) .. but I do not want
> to store it in plaintext.

As I recall, the pwcheck_method is only used for plaintext authentications.
None of the other mechanisms pay attention to it. To do what you want
requires storing the actual MD5 hashes in LDAP. Currently there is no
support for getting SASL secrets from the LDAP directory though.

I've spent quite a lot of time on the SASL code recently, and I see a few
problems with pursuing this route any further. The solution is complex, and
may be too complex to be worthwhile. For slapd itself the problem is not so
bad. But for some other SASL-based service, it requires establishing a
secure LDAP connection between the SASL server (e.g., imapd, sendmail,
whatever) and the LDAP server. Of course if these servers all live on the
same machine it's no problem, they can just use a Unix-domain socket, but
that tends to defeat the purpose of storing secrets in LDAP.

So, for any other SASL-enabled service, we need to store a secret that
allows it to connect to LDAP and retrieve the SASL secrets. Protecting
*that* secret becomes a new problem of its own...

I think the solution is going to look something like this:

Host1
sendmail -> SASL -> ldapi/back-ldap -> TLS -> to Host2 ...

Host2
... SASL/EXTERNAL -> slapd

That is, each remote host that wants to do SASL authentication via LDAP will
have an LDAP proxy server that forwards the authentication requests. The
proxy will listen on a local Unix Domain Socket, with permissions set to
only allow privileged services to connect. The Unix permissions will be the
only security control, the LDAP connections themselves will be anonymous.
The back-ldap proxy will forward the requests to the main LDAP server that
actually holds the SASL secrets. The proxy will have its own SSL
certificate, and will use SASL/EXTERNAL authentication to bind to the main
LDAP server. (Some secure login is required, but it doesn't need to be SSL
and SASL/EXTERNAL. It could be any secure SASL mechanism but I believe
certificate and SASL/EXTERNAL is the easiest to run.) Then the SASL secrets
are retrieved from the main LDAP server and returned to the requesting SASL
service, to be validated there.

It's really rather ugly. The other alternative is to use SASL's plaintext
authentication mechanism, with a custom pw_check mechanism. This is much
easier:

Host1                           Host2
sendmail -> SASL -> LDAP/TLS -> slapd

All you need is for the pw_check plugin to do a simple bind over an
encrypted connection. It's pretty much identical to what pam_ldap does.

Another solution that works for SASL/GSSAPI is to build your Kerberos KDC
with LDAP as its database. I personally use this setup as well, it's easy
enough to live with. The problem with supporting the other mechanisms like
DIGEST-MD5 and CRAM-MD5 is, as you can see, these systems were not designed
to be distributed over a network in the first place, and you have to bend
over backwards to retrofit distribution capabilities into them. On the other
hand, Kerberos was designed from the start as a distributed authentication
system, so Kerberos already addresses these issues.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support