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

regards

Simon

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" names:

central: cn=user.account,ou=peopl,o=my organisation,c=acountry local:uid=user.account,ou=Users,ou=OxObjects,dc=my,dc=groupware,dc=server,dc=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:

<slapd.conf> # 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 # ... </slapd.conf>

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 too.

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).

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.n.c. 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

---

Matthew Hardin wrote, on 29. mar 2007 19:13:

[...]

Those are not your only two options. In fact, many Linux distributions are notorious about lagging many releases behind current OpenLDAP. Buchan Milne and one or two others keep relatively up-to-date SRPMs, and Symas offers professionally-supported binary packages for many different platforms.

It's worth pointing out that Buchan's srpms are specifically designed for Red Hat - and ES at that - and Mandriva, and most probably won't build on SuSE (I don't know for sure, I've never tried). The Symas way would seem to be the right one to go.

--Tonni