Re: Problem with ADS authentication - any alternatives?

[Dan White <dwhite@olp.net>]

On 12/07/10 14:43 +0200, Garry Glendown wrote:
> After a customer of ours migrated from using a local OpenLDAP server to
> using a central ADS, I've run into sort of a problem ...
>
> One of the apps that had been using LDAP to get certain information for
> a user has now got a problem as the formerly used bind with the user ID
> (which was present in multiple fields, like uid, cn etc.) now fails. The
> customer ADS now has the user name (in the format "First Last") in the
> cn field, and as the complete dn in the dn field (with ou=...)
> Now, while stuff like Cyrus works fine through looking up the correct DN
> for a specified uid first and then using that DN for binding to the
> database, this app still just hands over the input to ADS ... of course,
> bind fails, as the supplied user ID doesn't match either DN or CN.

Do you mean Cyrus SASL or IMAP here? How does your app bind to the LDAP
server? Is it a SASL bind with a username and password?

> Of course one could just change the user name input to the full CN
> contents, but as this is a customer with 600+ PCs, many of which have
> the old authentication information stored locally (with the user not
> necessarily being able to alter the information), this solution is only
> sub-optimal.
> Altering the CN field to contain the same info as the uid field is
> another option, which was rejected as it is uncertain to what extent
> this might cause some problems later on (in case M$ decides to do
> anything nasty with the cn field).
>
> I was thinking about creating some sort of proxy in between, that allows
> authentication with the uid contents, but this won't work as I'd need
> the password from the ADS entries, which I can't get ...
>
> So I'm wondering - is there some kind of proxy that would allow me to do
> something like this:
>
> - App connects to LDAP Proxy with uid and password, sending some query
> - Proxy queries ADS for the DN of the uid received
> - Proxy binds to ADS with the DN and the supplied user PW, sends the
> query and returns the information to the client
>
> And while I'm at it - if the proxy were able to use two backend ADS,
> this would be a definite plus ... ;)

If you can shoehorn your app into performing a SASL bind with a username
and password, then you could set up a proxy server, with a
/usr/lib/sasl2/slapd.conf of:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

And configure an /etc/saslauthd.conf with:

ldap_servers: ldap://192.0.2.1/
ldap_search_base: OU=Users,OU=EXM,DC=example,DC=com
ldap_bind_dn: Administrator@example.com
ldap_bind_pw: secret
ldap_use_sasl: no
ldap_auth_method: bind
ldap_filter: (sAMAccountName=%u)

Or:

ldap_servers: ldap://192.168.2.1/
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5


However, that's only going to get you authenticated to the OpenLDAP server.
That bind done by saslauthd is only for authentication purposes. I don't
know the configuration details of how subsequent proxy requests are
authenticated from OpenLDAP to a remote LDAP server.

Essentially this approach only gets you authenticated, and could
potentially get you an appropriate 'ldapwhoami' response with properly
configured authz-regexp statements in your configuration.

One possible way way to make use of two ADS servers (again, only for the
authentication step) is to do:

pwcheck_method: saslauthd authdaemond
authdaemond_path: /path/to/courier/authdaemond/mux
mech_list: PLAIN LOGIN

And then also configure an authldaprc file appropriate for the second
server.

--
Dan White