We have a Sun Directory 5.x whose DIT has entry dn's in the format
"uid=xxxxxxx,ou=people,l=region,dc=example,dc=com"
with "region" being the name of each of 4 continents (north america, south america, asia, europe).
What I'd like to do is use the OpenLDAP meta backend to rewrite those dns so that searches against the OpenLDAP server return these dns in the format
"uid=xxxxxxx,ou=people,dc=example,dc=com"
The OpenLDAP server was built with --enable-overlays, as well as --enable-meta and --enable-ldap, in addition to the defaults.
I've looked over the doc for slapd-meta, slapd-ldap, slapo-rwm and slapo-glue, as well as the configs in the distribution test scripts, without coming up with a working slapd.conf to accomplish this.
Questions: (1) is this possible with any released version of OpenLDAP?; (2) If so, does anyone have a working example of a config that they could post here?
As always, many thanks.
-- Philip Lembo
PHILIP LEMBO wrote:
We have a Sun Directory 5.x whose DIT has entry dn's in the format
"uid=xxxxxxx,ou=people,l=region,dc=example,dc=com"
with "region" being the name of each of 4 continents (north america, south america, asia, europe).
What I'd like to do is use the OpenLDAP meta backend to rewrite those dns so that searches against the OpenLDAP server return these dns in the format
"uid=xxxxxxx,ou=people,dc=example,dc=com"
The OpenLDAP server was built with --enable-overlays, as well as --enable-meta and --enable-ldap, in addition to the defaults.
I've looked over the doc for slapd-meta, slapd-ldap, slapo-rwm and slapo-glue, as well as the configs in the distribution test scripts, without coming up with a working slapd.conf to accomplish this.
Questions: (1) is this possible with any released version of OpenLDAP?; (2) If so, does anyone have a working example of a config that they could post here?
It is possible if your sun directory allows you to search for "dc=example,dc=com". In that case, you should use something like
database ldap suffix "dc=example,dc=com" uri "ldap://remote/"
overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?l=[^,]+,dc=example,dc=com" "$1dc=example,dc=com" ":@" rwm-rewriteContext searchAttrDN alias searchEntryDN rwm-rewriteContext matchedDN alias searchEntryDN rwm-rewriteContext referralDN alias searchEntryDN
This configuration suffers from a number of problems:
1) you'll get 5 entries whose dn is "dc=example,dc=com", since those with dn "l=something,dc=example,dc=com" will have the "l=something" part stripped.
2) you'll get 4 entries whose dn is "ou=People,dc=example,dc=com" for the same reason above
3) you'll get other duplicate entries if entries with the same dn, except for the "l=something" part, exist
4) you won't be able to access entries directly, because any entry whose dn looks like "<whatever>,dc=example,dc=com" would need to be expanded to "<whatever>,l=something,dc=example,dc=com", which is obviously impossible.
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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
First, thanks for the quick reply.
I was able to set up a couple of test instances to try this config out, and as you predicted the results were not pretty -- although much further along than I'd been able to get on my own.
My assumption is that what we're facing here is a common problem -- when had to deal with integrating the various 3rd party apps that only support a flat DIT out-of-the-box (the strategy being to take a login ID and "construct" the rest of the dn around it, like "uid=[login id],ou=people,dc=example,dc=com"). The idea here was to try and create a flattened "view" of all our user entries so that we wouldn't have to constantly struggle with modifying some of these (poorly designed) packages.
I did do some variations on what you provided, without further success. Not willing to give up yet (what kind of directory admin would I be if I did?), but it looks like this is going to require some longer term effort than anticipated. The next avenue of attack will be to see if I can leverage an attribute we've got in each entry that identifies the geographic region it lives in (call it "destinationindicator" for purposes of discussion). This was implemented years ago to prevent our developers from relying on the structure of the DIT for that information. Anyway, thanks again for the insight.
-- Phil Lembo
PHILIP LEMBO wrote:
First, thanks for the quick reply.
I was able to set up a couple of test instances to try this config out, and as you predicted the results were not pretty -- although much further along than I'd been able to get on my own.
My assumption is that what we're facing here is a common problem -- when had to deal with integrating the various 3rd party apps that only support a flat DIT out-of-the-box (the strategy being to take a login ID and "construct" the rest of the dn around it, like "uid=[login id],ou=people,dc=example,dc=com"). The idea here was to try and create a flattened "view" of all our user entries so that we wouldn't have to constantly struggle with modifying some of these (poorly designed) packages.
I did do some variations on what you provided, without further success. Not willing to give up yet (what kind of directory admin would I be if I did?), but it looks like this is going to require some longer term effort than anticipated. The next avenue of attack will be to see if I can leverage an attribute we've got in each entry that identifies the geographic region it lives in (call it "destinationindicator" for purposes of discussion). This was implemented years ago to prevent our developers from relying on the structure of the DIT for that information. Anyway, thanks again for the insight.
Then try this:
database meta suffix "dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=north america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=south america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=asia,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=europe,dc=example,dc=com"
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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
Then try this:
database meta suffix "dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=north america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=south america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=asia,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=europe,dc=example,dc=com"
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 Fax: +39 0382 476497 Email: ando@sys-net.it
Fascinating results. An ldapsearch retrieves two entries for each query. One with the massaged dn, one with the "real" dn. The entry with the massaged dn is missing any attributes that are not in the meta server's schema. The "real" entry shows you everything (attributes not in the meta servers schema are in all caps, just like with a simple slapd-ldap backend pass-through proxy). You can bind with either the massaged or real dn, but the acis I have in place on the Sun DS server give me only anonymous rights to see attributes in the massaged entry (I can see everything I'd normally see in the entry returned with the real dn). Modifications going back up are successful, so long as the target attribute is in the meta server schema. Adds with a real dn are successful, but using the massaged dn gives you an "insufficient add privilege" error. Interestingly, the real target changes from attempt to attempt. On my first try adding a massaged dn, the target reported was from the last suffixmassage line in the config file. The next time I tried, it skipped to the first line. Of course none of the usual LDAP browsing tools works, because they can't display the tree in the way they're used to doing.
-- Phil Lembo
PHILIP LEMBO wrote:
Fascinating results. An ldapsearch retrieves two entries for each query. One with the massaged dn, one with the "real" dn. The entry with the massaged dn is missing any attributes that are not in the meta server's schema. The "real" entry shows you everything (attributes not in the meta servers schema are in all caps, just like with a simple slapd-ldap backend pass-through proxy). You can bind with either the massaged or real dn, but the acis I have in place on the Sun DS server give me only anonymous rights to see attributes in the massaged entry (I can see everything I'd normally see in the entry returned with the real dn). Modifications going back up are successful, so long as the target attribute is in the meta server schema. Adds with a real dn are successful, but using the massaged dn gives you an "insufficient add privilege" error. Interestingly, the real target changes from attempt to attempt. On my first try adding a massaged dn, the target reported was from the last suffixmassage line in the config file. The next time I tried, it skipped to the first line. Of course none of the usual LDAP browsing tools works, because they can't display the tree in the way they're used to doing.
It works fine in my test with a reasonable database designed according to your initial posting. Apparently, you're hiding an incredible amount of information, and guessing requires too much effort on my side to allow me to help you further.
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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
openldap-software@openldap.org
-
PHILIP LEMBO -
Pierangelo Masarati