Hello.
I need to integrate local OpenLDAP and remote Active directory DS wereas the result is expected to work like this:
User wants to authenticate --> Client (Gerrit 2.9.1) connects to the local OpenLDAP server --> The OpenLDAP server searches its local database for a relevant entry
* Entry found --> Inform the client
* Entry not found --> Delegate the request to the remote Active directory server
o Entry found --> Inform the OpenLDAP server --> Inform the client
o Entry not found --> Inform the OpenLDAP server --> Inform the client
I came across this article [1], but my server uses the slapd.d configuration schema and I can't make it work as there's too little helpful documentation to it.
I'll be thankful for every help. Jan
[1] http://ltb-project.org/wiki/documentation/general/sasl_delegation
On 11/11/14 09:50 +0000, Šmucr Jan wrote:
User wants to authenticate --> Client (Gerrit 2.9.1) connects to the local OpenLDAP server --> The OpenLDAP server searches its local database for a relevant entry
Entry found --> Inform the clientEntry not found --> Delegate the request to the remote Active directory servero Entry found --> Inform the OpenLDAP server --> Inform the client
o Entry not found --> Inform the OpenLDAP server --> Inform the client
[1] http://ltb-project.org/wiki/documentation/general/sasl_delegation
To work with pass-through authentication, all users will need a valid entry within your OpenLDAP tree. Those you wish to authenticate against active directory will need a userPassword attribute of:
userPassword: {SASL}user@domain
And those you wish to authenticate locally should have a standard hashed password string. All authentication (or at least pass-through authentication) will need to use simple binds (-x command line option).
If that requirement does not meet your needs, use ldap SASL binds instead of pass-through authentication, which do not require your authenticated users to exist within the local tree.
To trouble shoot pass-through authentication, run saslauthd in debug mode (-d), and use testsaslauthd to validate your saslauthd.conf configuration prior to troubleshooting your slapd config. Verify your slapd process has permissions to communicate with the saslauthd mux, which is a common mistake.
For project documentation, see:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication http://www.openldap.org/doc/admin24/sasl.html saslauthd(8) testsaslauthd(8) 'saslauthd/LDAP_SASLAUTHD' in the cyrus sasl source code
Dan White wrote:
On 11/11/14 09:50 +0000, Šmucr Jan wrote:
User wants to authenticate --> Client (Gerrit 2.9.1) connects to the local OpenLDAP server --> The OpenLDAP server searches its local database for a relevant entry
Entry found --> Inform the clientEntry not found --> Delegate the request to the remoteActive directory server
o Entry found --> Inform the OpenLDAP server --> Inform the client
o Entry not found --> Inform the OpenLDAP server --> Inform the client
[1] http://ltb-project.org/wiki/documentation/general/sasl_delegation
To work with pass-through authentication, all users will need a valid entry within your OpenLDAP tree. Those you wish to authenticate against active directory will need a userPassword attribute of:
userPassword: {SASL}user@domain
Why do people keep trying to use "pass-through authentication" when the question clearly is about *proxying*. back-ldap and back-meta exist for proxying. This was just answered a few weeks ago.
http://www.openldap.org/lists/openldap-technical/201410/msg00078.html
The obvious solution here is a local database with back-meta in front of it. The back-meta instance can be pointed at both the remote AD server and the local server and will automatically search both DBs to find a user's account (when performing a search request) and then the following Bind request will just do the right thing.
Use the right tool for the job. pass-through authentication is not the solution for a proxying task.
So... I tried to achieve the objective with using the meta backend with two targets -- local and remote. Now -- how can I configure the server so the request is delegated to the remote server after it fails on the local?
By the way, I gave up my attempts to configure the server using slap.d, as there's simply not enough documentation to it and I don't need to deal with any additional pain at the moment.
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, November 11, 2014 4:28 PM To: Dan White; Šmucr Jan Cc: openldap-technical@openldap.org Subject: Re: OpenLDAP Proxy for Active Directory Authentication (slapd.d)
Dan White wrote:
On 11/11/14 09:50 +0000, Šmucr Jan wrote:
User wants to authenticate --> Client (Gerrit 2.9.1) connects to the local OpenLDAP server --> The OpenLDAP server searches its local database for a relevant entry
Entry found --> Inform the clientEntry not found --> Delegate the request to the remoteActive directory server
o Entry found --> Inform the OpenLDAP server --> Inform the client
o Entry not found --> Inform the OpenLDAP server --> Inform the client
[1] http://ltb-project.org/wiki/documentation/general/sasl_delegation
To work with pass-through authentication, all users will need a valid entry within your OpenLDAP tree. Those you wish to authenticate against active directory will need a userPassword attribute of:
userPassword: {SASL}user@domain
Why do people keep trying to use "pass-through authentication" when the question clearly is about *proxying*. back-ldap and back-meta exist for proxying. This was just answered a few weeks ago.
http://www.openldap.org/lists/openldap-technical/201410/msg00078.html
The obvious solution here is a local database with back-meta in front of it. The back-meta instance can be pointed at both the remote AD server and the local server and will automatically search both DBs to find a user's account (when performing a search request) and then the following Bind request will just do the right thing.
Use the right tool for the job. pass-through authentication is not the solution for a proxying task.
openldap-technical@openldap.org
-
Dan White -
Howard Chu -
Šmucr Jan