We have a scenario that I’m hoping OpenLDAP can offer a solution to.
We are in the process of transitioning from one ldap authentication source to another for several of our applications. During the transition we need to be able to authenticate users against one of two different ldap services. Unfortunately our applications do not support the capability to try authentication against multiple services.
Would an OpenLDAP setup be able to take the authentication request and attempt to validate it against 2 different backends?
I should note that each of the ldap backends would have different OU structures and that a given userID would not exist in both backends. Based on the slapd-meta man page SCENARIOS section it looks as though this may be possible. The examples don't illustrate whether or not the OU structures need to be the same between the backends.
Any help would be greatly appreciated!
Regards, Dan
Hi,
danz@wustl.edu a écrit :
We have a scenario that I’m hoping OpenLDAP can offer a solution to.
We are in the process of transitioning from one ldap authentication source to another for several of our applications. During the transition we need to be able to authenticate users against one of two different ldap services. Unfortunately our applications do not support the capability to try authentication against multiple services.
Would an OpenLDAP setup be able to take the authentication request and attempt to validate it against 2 different backends?
I should note that each of the ldap backends would have different OU structures and that a given userID would not exist in both backends. Based on the slapd-meta man page SCENARIOS section it looks as though this may be possible. The examples don't illustrate whether or not the OU structures need to be the same between the backends.
Assuming your authentication process starts by searching for a "userID" in some LDAP tree to find a user's DN, and then attemps a bind operation on that DN, I think you'll find the following setup useful.
Consider two backends, let's say ou=A,o=example and ou=B,o=example. Whether these are local bdb backends or remote LDAP backends is of little importance. By configuring A and B as "subordinate" to the higher level database o=example you can set your authentication clients to perform a search based on "o=example" for their userID, and OpenLDAP will propagate the search to both backends. A sub-scoped search will search the whole trees, regardless of OU structures.
In more detail, your slapd.conf could contain the following:
database ldap suffix "ou=A,o=example" subordinate uri ldap://a.example.com:389
database ldap suffix "ou=B,o=example" subordinate uri ldap://b.example.com:389
database null suffix "o=example" overlay glue
(The null database just serves as a placeholder, really. You could also use a BDB database.)
Hope this helps, Jonathan
Thanks for the feedback.
Is it correct to state that with your example there must be a common element in the suffix in order for this to work? database ldap suffix "ou=A,o=example" subordinate uri ldap://a.example.com:389
database ldap suffix "ou=B,o=example" subordinate uri ldap://b.example.com:389
database null suffix "o=example" overlay glue
Pierangelo provided the following example which would seem to indicate that there need not be any commonality in the suffix although this example does not make use of the "null" database entry: database ldap suffix "ou=Old" uri "ldap://old.server"
database ldap suffix "dc=new" uri "ldap://new.server"
In our case the suffixes would be: New server ou=Persons,dc=subdomainA,dc=domain,dc=edu Old server ou=users,ou=ais
As you can see there is no commonality between the 2.
Thanks again for the help.
Regards, Dan
Jonathan Clarke jclarke@linagora.com 06/03/2008 12:46 AM
To danz@wustl.edu cc openldap-technical@openldap.org Subject Re: slapd-meta question
Hi,
danz@wustl.edu a écrit :
We have a scenario that I’m hoping OpenLDAP can offer a solution to.
We are in the process of transitioning from one ldap authentication source to another for several of our applications. During the transition we need to be able to authenticate users against one of two different ldap services. Unfortunately our applications do not support the capability to try authentication against multiple services.
Would an OpenLDAP setup be able to take the authentication request and attempt to validate it against 2 different backends?
I should note that each of the ldap backends would have different OU structures and that a given userID would not exist in both backends. Based on the slapd-meta man page SCENARIOS section it looks as though this may be possible. The examples don't illustrate whether or not the OU structures need to be the same between the backends.
Assuming your authentication process starts by searching for a "userID" in some LDAP tree to find a user's DN, and then attemps a bind operation on that DN, I think you'll find the following setup useful.
Consider two backends, let's say ou=A,o=example and ou=B,o=example. Whether these are local bdb backends or remote LDAP backends is of little importance. By configuring A and B as "subordinate" to the higher level database o=example you can set your authentication clients to perform a search based on "o=example" for their userID, and OpenLDAP will propagate the search to both backends. A sub-scoped search will search the whole trees, regardless of OU structures.
In more detail, your slapd.conf could contain the following:
database ldap suffix "ou=A,o=example" subordinate uri ldap://a.example.com:389
database ldap suffix "ou=B,o=example" subordinate uri ldap://b.example.com:389
database null suffix "o=example" overlay glue
(The null database just serves as a placeholder, really. You could also use a BDB database.)
Hope this helps, Jonathan
danz@wustl.edu wrote:
Thanks for the feedback.
Is it correct to state that with your example there must be a common element in the suffix in order for this to work? database ldap suffix "ou=A,o=example" subordinate uri ldap://a.example.com:389
database ldap suffix "ou=B,o=example" subordinate uri ldap://b.example.com:389
database null suffix "o=example" overlay glue
Pierangelo provided the following example which would seem to indicate that there need not be any commonality in the suffix although this example does not make use of the "null" database entry: database ldap suffix "ou=Old" uri "ldap://old.server"
database ldap suffix "dc=new" uri "ldap://new.server"
In our case the suffixes would be: New server ou=Persons,dc=subdomainA,dc=domain,dc=edu Old server ou=users,ou=ais
As you can see there is no commonality between the 2.
Thanks again for the help.
Regards, Dan
I can't see Ando's example in this thread?
Gavin Henry wrote:
I can't see Ando's example in this thread?
My fault: during a mail migration, my address got automatically rewritten from ando@sys-net.it to the canonical pierangelo.masarati@sys-net.it, which is not the address I used when subscribing to the mailing list. I think the problem is now fixed (hopefully :)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Hi,
danz@wustl.edu a écrit :
Thanks for the feedback.
Is it correct to state that with your example there must be a common element in the suffix in order for this to work? database ldap suffix "ou=A,o=example" subordinate uri ldap://a.example.com:389
database ldap suffix "ou=B,o=example" subordinate uri ldap://b.example.com:389
database null suffix "o=example" overlay glue
Pierangelo provided the following example which would seem to indicate that there need not be any commonality in the suffix although this example does not make use of the "null" database entry: database ldap suffix "ou=Old" uri "ldap://old.server"
database ldap suffix "dc=new" uri "ldap://new.server"
In our case the suffixes would be: New server ou=Persons,dc=subdomainA,dc=domain,dc=edu Old server ou=users,ou=ais
As you can see there is no commonality between the 2.
I may have misunderstood your problem. I understood that during your transition period between "old" and "new", you wished all LDAP clients to perform the same search but find users that are in either tree, transparently.
Thus, if your search is something like : ldapsearch -h the.ldap.server -b "ou=the-common-search-base" uid=someone
...you can use the same search on all clients, and yes, you would need a common suffix. If your current LDAP services don't share a suffix, you can use slapo-rwm to rewrite this, for example : rwm-suffixmassage ou=new,ou=the-common-search-base o=new
If you don't need to perform exactly the same search on all clients, why don't you just configure them all the same?
Regards,
openldap-technical@openldap.org