On 12.07.2010 16:14, Dan White wrote:
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?
The app in question does a straight LDAP bind, using the username and pw entered ...
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
It's a commercial app, no source available to do any changes to it ... anything done would need to be done behind the LDAP bind ...
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.
Will need to try that ...