[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with ADS authentication - any alternatives?

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
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://
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)


ldap_servers: ldap://
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

Dan White