[Date Prev][Date Next]
Re: Redirect bind requests to another server
Thanks for your answer,
as you said it's not straightforward, but now i understand what to do.
Concerning the version of openldap I'd rather stick with the binaries
that are shipped with the linux distribution as you don't have to bother
about rebuilding everything everytime a new bugfix is released.
You wrote about design problems in slapo-rwm in the 2.3 branch of the
software. Is it anything that will affect using it the way you described
or do the problems arise in other scenarios?
Your suggestion to write an overlay is far beyond my knowledge of c and
openldap, so I guess i'll try with slapo-rwm
Pierangelo Masarati wrote:
> Simon Maier wrote:
>> I have a question about a special LDAP setup, we want to implement at
>> the university computing centre. The story as it's intended to be:
>> We're running a groupware application (openxchange), which uses a LDAP
>> server (openldap 2.2.23 on Suse 9.3) to authenticate its users (mainly
>> members of the computing centre) and to store contacts, group
>> memberships of the users and some of the user settings. This server
>> runs on the same machine as the groupware itself.
>> There is another LDAP server (i don't know the version used there), that
>> holds the centralized password and account name of all users at the
>> university for various authentication purposes. This server only
>> accepts bind requests.
>> The goal is to authenticate the users against the central LDAP server
>> but to store the settings etc. on the local server. There is one
>> additional problem, the naming contexts on the servers do not match
>> each other. To give you a basic idea I reproduced this with "generic"
>> central: cn=user.account,ou=peopl,o=my organisation,c=acountry
>> Is there a way to accomplish this?
>> If this is a RTFM question, please excuse me asking, but I'm not very
>> familiar with openldap
> There are different methods to obtain exactly what you need, or
> something similar. None of them is exactly straightforward, but perhaps
> the best one consists in using a global instance of the slapo-rwm(3)
> overlay that, by rewriting the bindDN, diverts bind requests to an
> instance of back-ldap that binds to the remote server. Other operations
> would be directed to a local storage without any DN rewriting.
> Something like:
> # before any "database" directive
> # to make things shorter, use
> # central: "cn=user.account,ou=peopl,o=central"
> # local: "uid=user.account,ou=Users,dc=local"
> overlay rwm
> rwm-rewriteEngine on
> # rewrite bind requests
> rwm-rewriteContext bind
> rwm-rewriteRule "^uid=([^,]+),ou=Users,dc=local"
> "cn=$1,ou=peopl,o=central" ":@"
> # don't rewrite the rest
> rwm-rewriteContext default
> database ldap
> # trap requests rewritten for the central server; do not allow
> # direct read/write
> suffix "o=central"
> uri "ldap://central/"
> restrict read write
> database bdb
> # handle requests for the local database
> suffix "dc=local"
> directory /dir
> # ...
> Make sure DNs like the rootdn of the local database don't get rewritten,
> otherwise you might be no longer able to bind with that identity. The
> "restrict" statement restricts read/write operations, so that the
> "o=central" database cannot be directly used other than for binds.
>> By the way, we're planing to upgrade the server to a later version of
>> the operating system, so answers for openldap 2.3.27 would be helpful
> This needs at least 2.3 because of the global overlay that rewrites
> things; actually, slapo-rwm(5) should be rather used with 2.4 because in
> 2.3 it suffers from some design problems, but in the above illustrated
> example it should just be fine.
> Another option would be to write your own overlay that diverts binds to
> the central server while lets anything else pass thru. We did something
> similar to proxy a remote server that needed special mucking that
> couldn't be accomplished with slapo-rwm(5).
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> Office: +39.02.23998309
> Mobile: +39.333.4963172
> Email: firstname.lastname@example.org