[Date Prev][Date Next] [Chronological] [Thread] [Top]

back_relay difficulties



Greetings,

I am quite skilled with OpenLDAP in general, but am having difficulties with one aspect of a popular set of Overlays (modules) used with OpenLDAP: the "back_relay" backend module, and the rwm.la module (basically mod-rewrite for slapd).

First, let me get the scenario out of the way:

We have configured a nice LDAP server for a set of network hosts to use for authentication, posix accounts, etc. However, these hosts are spread amongst various subdomains of our network. I want "fake" backends to be used to each respective domain. Clients in these zones have LDAP client files that point to an LDAP DIT (database) that does not exist in reality =).

Some generic examples, but you get the idea:

dc=real,dc=example,dc=com <- the REAL HDB backend, an actual DB
dc=corp,dc=example,dc=com <- fake "relay" that rewrites dc=real
dc=eng,dc=example,dc=com <- another fake "relay" that rewrites dc=real
dc=pub,dc=example,dc=com <- another fake "relay" that rewrites dc=real

For those of you unfamiliar with "back_relay" and "rwm.la", the above is accomplished by doing the following:

1. Build your normal LDAP DIT, get it perfect. Use a name you do not intend the "public" or untrusted clients to see.

2. Load the modules in slapd.conf:
moduleload back_relay
moduleload rwm.la

3. right after your REAL database section in slapd.conf, start another backend (might look something like this in your config):

########## Relay Instance for "CORP" (NOT a REAL DB)

database relay
suffix dc=corp,dc=example,dc=com
relay dc=real,dc=example,dc=com
overlay rwm
rwm-suffixmassage dc=real,dc=example,dc=com
rwm-rewriteEngine on
rwm-normalize-mapped-attrs yes

access to dn.subtree="dc=corp,dc=example,dc=com"
by users read

4. Restart slapd

Of course, your real DIT has to have ACLs permitting access for this to work.

Now I must stress WE HAVE THIS WORKING. For example, if one of our engineers executes an LDAP search, his results returned have the DNs rewritten according to their zones' configuration.

What DOES NOT work is the 'ldapwhoami' operation. When user Joe executes the ldapwhoami cmd:

joe@host~:/$ ldapwhoami -xw password -D uid=joe,cn=users,dc=corp,dc=example,dc=com

The returned data is NOT what we want:

dn:uid=joe,cn=users,dc=real,dc=example,dc=com

I have tried the following, before you start making suggestions:

1. Reading the man page for days, trying examples
2. Googling other peoples' configs. Frankly no one does what I do with LDAP ;-)
3. Using authz-regexp in both the global and per-relay config-space to rewrite a returned DN to the desired one.

I KNOW the relay DB IS working with our REAL db because of the following:

1. We can auth to the relay base (dc=corp,dc=example,dc=com)
2. Data returned in normal LDAP searches has every DN rewritten, as desired.

We are using:

HP Proliant DL140 / 4GB RAM on amd64 Kernel
Debian Lenny + OpenLDAP 2.4.11
libpam-ldap and libnss-ldap for client-side auth
ldap-utils on client-side for arbitrary ldap commands


#############

Again, received no replies worth even reading.  Please help!

Thank you

Jeff Doyle