Simon Maier wrote:
I have a question about a special LDAP setup, we want to implement
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.
# 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"
# rewrite bind requests
# don't rewrite the rest
# trap requests rewritten for the central server; do not allow
# direct read/write
restrict read write
# handle requests for the local database
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
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
Via Dossi, 8 - 27100 Pavia - ITALIA