Hello,
in the mailing list's archive is a lot of stuff about OpenLDAP as proxy for another LDAP-Server using the ldap/meta backend, but I didn't find an answere of my question (it's possible that I don't see the wood for the trees).
I've the following problem:
Our OpenLDAP get's an request which contained a User-ID and Password from a LDAP-Client. Our OpenLDAP propagate the authentification (User-ID, Password) of the request to another LDAP-Server using the ldap/meta backend. If the authentification is o.k. our OpenLDAP contributes the reamining attributes (tel. number, surname etc.) and gives they back to the requester.
I need as a response of a request an interaction of two LDAP-Server. From the other LDAP-Server the authentification and if successfull from our LDAP-Server the attributes.
Is there a fair chance to get a solution using the ldap/meta backend.
Thanks in advance for your efforts
Klaus
ems@sparkassen-informatik.de wrote:
I need as a response of a request an interaction of two LDAP-Server. From the other LDAP-Server the authentification and if successfull from our LDAP-Server the attributes.
Is there a fair chance to get a solution using the ldap/meta backend.
Just a hint without thoroughly thinking about it. Maybe you could use slapo-rwm for rewriting only the bind requests to another name space served by back-ldap. Or maybe have a look at slapo-translucent and combine it with back-ldap.
Ciao, Michael.
ems@sparkassen-informatik.de wrote:
I need as a response of a request an interaction of two LDAP-Server. From the other LDAP-Server the authentification and if successfull
from
our LDAP-Server the attributes.
Is there a fair chance to get a solution using the ldap/meta backend.
michael@stroeder.com wrote:
Just a hint without thoroughly thinking about it. Maybe you could use slapo-rwm for rewriting only the bind requests to another name space served by back-ldap. Or maybe have a look at slapo-translucent and combine it with back-ldap.
Ciao, Michael.
It's sounds a little bit complicated. I've found some stuff under the keyword "single sign on". Do you think it's a better way to manage the problem with OpenLDAP and Kerberos.
Cioa, Klaus
On 9:03:07 am 2008-05-14 ems@sparkassen-informatik.de wrote:
ems@sparkassen-informatik.de wrote:
I need as a response of a request an interaction of two LDAP-Server. From the other LDAP-Server the authentification and if successfull from our LDAP-Server the attributes.
Is there a fair chance to get a solution using the ldap/meta backend.
michael@stroeder.com wrote:
Just a hint without thoroughly thinking about it. Maybe you could use slapo-rwm for rewriting only the bind requests to another name space served by back-ldap. Or maybe have a look at slapo-translucent and combine it with back-ldap.
It's sounds a little bit complicated. I've found some stuff under the keyword "single sign on". Do you think it's a better way to manage the problem with OpenLDAP and Kerberos.
This all really depends on what you want to achieve: Your applications, security policy, etc.
Ciao, Michael.
Hello,
ems@sparkassen-informatik.de writes:
Hello,
in the mailing list's archive is a lot of stuff about OpenLDAP as proxy for another LDAP-Server using the ldap/meta backend, but I didn't find an answere of my question (it's possible that I don't see the wood for the trees).
I've the following problem:
Our OpenLDAP get's an request which contained a User-ID and Password from a LDAP-Client. Our OpenLDAP propagate the authentification (User-ID, Password) of the request to another LDAP-Server using the ldap/meta backend. If the authentification is o.k. our OpenLDAP contributes the reamining attributes (tel. number, surname etc.) and gives they back to the requester.
I need as a response of a request an interaction of two LDAP-Server. From the other LDAP-Server the authentification and if successfull from our LDAP-Server the attributes.
Is there a fair chance to get a solution using the ldap/meta backend.
Just to make sure, there are two directories, one that provides information on authentication and authorization, the second directory provides some additional iformation. If that is your request, than you may have a look at the translucent overlay.
-Dieter
On Wed, May 14, 2008 at 10:49:02AM +0200, Dieter Kluenter wrote:
Just to make sure, there are two directories, one that provides information on authentication and authorization, the second directory provides some additional iformation. If that is your request, than you may have a look at the translucent overlay.
That would depend on whether the two servers had identical namespaces (tree layout, choice of RDN etc).
I have a similar requirement at the moment except that I only want to use the second LDAP server to authenticate for a small proportion of the entries in the first one. The namespaces are very different. I think it can be done with a combination of rwm, back-ldap/back-meta and slapd-relay, but this seems rather complex when all I really need is 'pass-through authentication'.
I will report back to the list if I come up with a workable solution, but in the mean time does anyone have any pointers to a neat way of doing this?
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk writes:
On Wed, May 14, 2008 at 10:49:02AM +0200, Dieter Kluenter wrote:
Just to make sure, there are two directories, one that provides information on authentication and authorization, the second directory provides some additional iformation. If that is your request, than you may have a look at the translucent overlay.
That would depend on whether the two servers had identical namespaces (tree layout, choice of RDN etc).
I have a similar requirement at the moment except that I only want to use the second LDAP server to authenticate for a small proportion of the entries in the first one. The namespaces are very different. I think it can be done with a combination of rwm, back-ldap/back-meta and slapd-relay, but this seems rather complex when all I really need is 'pass-through authentication'.
I will report back to the list if I come up with a workable solution, but in the mean time does anyone have any pointers to a neat way of doing this?
I have done similar with back-sql
database sql suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" ...
database relay suffix "ou=sql-user,o=avci,c=de" relay dc=example,dc=com overlay rwm rwm-rewriteEngine on rwm-rewriteMap <rules> subordinate
database hdb suffix "o=avci,c=de" rootdn "cn=admin,o=avci,c=de" ...
-Dieter
On Thu, 15 May 2008, Andrew Findlay wrote: ...
I have a similar requirement at the moment except that I only want to use the second LDAP server to authenticate for a small proportion of the entries in the first one. The namespaces are very different. I think it can be done with a combination of rwm, back-ldap/back-meta and slapd-relay, but this seems rather complex when all I really need is 'pass-through authentication'.
I will report back to the list if I come up with a workable solution, but in the mean time does anyone have any pointers to a neat way of doing this?
How about by using saslauthd? Configure the users that need pass-through authentication with userPassword values in the form "{SASL}user@domain", put "pwcheck_method: saslauthd" in the sasl/slapd.conf file, and configure saslauthd to authenticate against the backend server. That gives you both complete control over who gets passed through (only those with the {SASL} format) and complete flexibility in the mapping of frontend users to backend users (by tweaking the "user@domain" in each user's userPassword attribute).
Philip Guenther
On Thu, May 15, 2008 at 11:58:28AM -0600, Philip Guenther wrote:
How about by using saslauthd? Configure the users that need pass-through authentication with userPassword values in the form "{SASL}user@domain", put "pwcheck_method: saslauthd" in the sasl/slapd.conf file, and configure saslauthd to authenticate against the backend server. That gives you both complete control over who gets passed through (only those with the {SASL} format) and complete flexibility in the mapping of frontend users to backend users (by tweaking the "user@domain" in each user's userPassword attribute).
That does look like the best solution so far, thank you.
Odd that such a useful feature is not mentioned in the docs at all. It is a bit tricky to set up due to the interactions with Cyrus SASL, but I now have it running so I will write a section for the Admin Guide explaining how to do it.
Andrew
On Fri, May 16, 2008 at 06:17:44PM +0100, Andrew Findlay wrote:
On Thu, May 15, 2008 at 11:58:28AM -0600, Philip Guenther wrote:
How about by using saslauthd? Configure the users that need pass-through authentication with userPassword values in the form "{SASL}user@domain",
I now have it running so I will write a section for the Admin Guide explaining how to do it.
Done, and submitted as ITS#5524:
http://www.openldap.org/its/index.cgi/Incoming?id=5524;selectid=5524
I attach the relevant chapter as an HTML file for anyone who is waiting to try pass-through authentication. Please let me know if you think of any improvements, or follow up to the thread on the openldap-its list.
Andrew
openldap-software@openldap.org
-
"Michael Ströder" -
Andrew Findlay -
Dieter Kluenter -
ems＠Sparkassen-Informatik.de -
Michael Ströder
-
Philip Guenther