Hi,
sorry if this is slightly off topic, but I'm hoping this may be possible with OpenLDAP ..
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. 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 ... ;)
Thanks for any feedback!
-garry
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.
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 ...
On 15/07/10 19:06 +0200, Garry Glendown wrote:
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 ...
That suggests to me that it is indeed a SASL bind.
Le 15/07/2010 19:56, Dan White a écrit :
On 15/07/10 19:06 +0200, Garry Glendown wrote:
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 ...
That suggests to me that it is indeed a SASL bind.
AD does in fact accept plain LDAP binds with a username in place of a DN. Or at least username@domain.tld. It's one of those weird things...
openldap-technical@openldap.org
-
Dan White -
Garry Glendown -
Jonathan Clarke