Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database

[masarati@aero.polimi.it]

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