> Ok, fair warning - this is a little long-winded, but I'd rather give too > much detail than not enough. Also, all > examples are in slapd.conf format, since there is no documentation for > cn=config, and I'm using slapd with -f and -F to > make the conversion. > > > Anyways, I'm working on implementing some rewrite rules with slapo-rwm, > using back-relay (or possibly back-meta if that > doesn't work out) as the backend on top of which slapo-rwm will sit, to > make available some features that would be > otherwise not be present with back-ldap, or in the absence of a proxy > backend altogether. > > > In its most basic form, the slapo-rwm overlay can be used without a proxy > or relay backend, but the feature I'm after > appears to require either the slapd-meta backend or the slapd-relay > backend. For now, I've chosen to try with > slapd-relay, as my research has indicated it supports the feature I'm > after. For reference, this feature I desire is > the 'searchResult' rewriteContext, as I'm interested in rewriting dynamic > group membership DN's (i.e., the 'member' > attribute, as defined in rfc2307bis) as plain uid's, so clients that only > know about rfc2307 (and thus, look only for > entries of the same format as memberUid and fail to perform any mappings > to translate membership DN's to UID's) can make > use of the dynamic groups I've created in my directory. > > > Since my slapd-hdb database's rootDSE is dc=example,dc=com, I really > couldn't find any way to get around using a virtual > naming context; creating a back-meta database on the same host with the > same suffix as the back-hdb database seemed > ambiguous at best (in terms of how to ensure that clients would always > speak to the back-meta db first), and using the > suffix "dc=com" seemed inappropriate, as did creating several relay > databases, one for each of the entries below the > slapd-hdb database's rootDSE (e.g., ou=Users,dc=example,dc=com, > ou=Groups,dc=example,dc=com, etc.). Creating several > relay databases in that fashion presents other problems as well, and > wouldn't do me any good for clients which query for > entries using dc=example,dc=com as their search base. > > > Given that, and the fact that I'm only looking to remap/rewrite data going > to and from a single local database with a > single naming context, I decided it was a better idea to create a single > back-relay database with a bogus "proxy" naming > context and use a suffixmassage to rewrite it, e.g.: > > > database relay > suffix "dc=example-proxy,dc=com" > relay "dc=example,dc=com" > > overlay rwm > rwm-rewriteEngine on > rwm-suffixmassage "dc=example-proxy,dc=com" "dc=example,dc=com" > rwm-rewriteContext searchResult > rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" "$1"
The result of this mapping does not yield a valid DN; as such, this rewriting is incorrect. Also, I don't see how it could be useful, as LDAP clients usually expect DNs to be DN-valued. > For reference, here is the back-meta database configuration I was going to > use before I discovered that back-relay > supported the searchResult rewriteContext: > > database meta > suffix "dc=example-proxy,dc=com" > > overlay rwm > rwm-rewriteEngine on > uri "ldap://localhost/dc=example-proxy,dc=com"; > rwm-suffixmassage "dc=example-proxy,dc=com" "dc=example,dc=com" > rwm-rewriteContext searchResult > rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" "$1" > > > In either case, I have a few questions going forward from this point: > > 1. Is it legal to rewrite the search result DN's as described in the > example above? I'm hoping that since the data > being manipulated is going from server -> client and is not being stored > in the directory, the attributes I'm rewriting > would not be subjected to the syntax requirements of the entry that holds > them. > > 2. Are there any benefits or drawbacks to using a rewriteMap to accomplish > this task? In my mind, it just seems like > another means to the same end, at least based on the following > configuration I came up with: > > rwm-rewriteMap ldap dn2uid > "ldap://localhost/ou=Users,dc=example,dc=com?uid?sub"; > rwm-rewriteContext searchResult > rwm-rewriteRule "^uid=([^,]+?),ou=Users,dc=example,dc=com$" > "${dn2uid($1)}" Same as above. You're performing an internal search to obtain information you already have, and cast it in invalid form. > 3. Is there a better way to go about doing this that I've failed to see or > consider? Consider why you need it: broken client? Fix the client. Anything else? Perhaps LDAP is not what you need; in any case, move such mangling into the client. > 4. Considering the slapd-meta man page, which mentions that some of its > features could potentially result in excessive > overhead for some installations, are the features used in the > aforementioned configuration(s) efficient enough to scale > well in a very busy environment? I'm aware that's a pretty vague and > loaded question with lots of variables, so I'm > just looking for an educated opinion from a 10,000 foot view, assuming > excellent hardware, high network capacity, and > heavy - say, 5k, 10k, 15k queries per second - traffic. Performance will > obviously be tested before implementing this, > but it'd still be nice to have a rough idea of what to expect going in. Pure rewriting may not impact too much; rewriteMaps that rewuire further internal lookups may yield significant overhead. Of course, if you setup things like ACL checking that involves significant internal searches on a database that makes extensive use of rewriting, things can get even worse. > Lastly, on a somewhat tangential note, given that there's no documentation > with respect to cn=config for setting up > slapo-rwm (or doing it in conjunction with a proxy backend), is there any > way to discover the cn=config attributes and > objectclasses for those backend and overlays that's better or more > efficient than creating a standard slapd.conf > configuration and converting it with slapd using -f and -F? Perhaps an > official or unofficial bit of documentation > floating around out there other than a few miscellaneous postings on the > mailing lists and some ITS contents? On a > similar note in the same vein, as far as I can tell, none of the man > pages, admin guide sections, or FAQ-O-Matic entries > on slapd-relay mention which rewrite contexts are available with it, and I > didn't realize that slapd-relay accepted the > searchResult rewrite context until I read the > servers/slapd/back-relay/README file (while searching for code that might > reveal slapo-rwm's cn=config attribute equivalents). Would it be > objectionable to update these reference points with > said information? I'd be happy to file an ITS and submit patches and/or > content for updating the documentation, if > Gavin is too busy, unavailable, or would like some help. None that I'm aware of. The FAQ is interactive; if by extensive experimenting, or by looking at the code, you want to contribute, it'd be more than welcome. Please note that 2.4.22 contains some improvements to slapo-rwm cn=config handling; you may want to stick with that release. p.
