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

[Ryan Steele <ryans@aweber.com>]

masarati@aero.polimi.it wrote:
>> 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.
> 


In this case, dscl (Mac OS X's directory services client) expects a UID, not a DN, as is the POSIX standard for group
members, and doesn't know how to parse usernames in groups that use DN's to identify their members.  Instead, they
expect UID's, and since there appears to be no way to do this client side with dscl (believe me, I did try to find one
before resorting to this), I have constructed the above rewriteRule to do this for them.  This should not impact my
Linux clients either, as nslcd (a daemon created in a fork of nss_ldap  by Arthur de Jong) only performs DN-to-UID
translations if the group members are represented as DN-valued attribute values.  My question wasn't whether or not the
result is a valid DN - it's whether or not it would actually work, functionally speaking.  Is that the case, regardless
of how ugly or undesirable it might be?


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


If there was any other way at all to do this, I would, believe me.  But, OS X's LDAPv3 plugin for dscl simply does not
know how to utilize DN-valued group members, and provides no way to customize the way search results are parsed.  So
again, I understand that the information is not a valid DN, but again, if functionally speaking this works, then that's
what I'll have to do to leverage my rfc2307bis-style dynamic groups on OS X.


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


LDAP is what I need, and unfortunately, "fixing the client" (as in hacking and recompiling dscl's LDAPv3 plugin) would
potentially invalidate a warranty of service and support.


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


Great, thanks so much for that assessment, Pierangelo.


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


Duly noted, and thanks again for your advice here, and any future advice on this topic.


Respectfully,
Ryan