Re: Problem with ADS authentication - any alternatives?

[Garry Glendown <garry@glendown.de>]

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 ...