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

[masarati@aero.polimi.it]

> masarati@aero.polimi.it wrote:
>>>
>>> masarati@aero.polimi.it wrote:
>>>>> masarati@aero.polimi.it wrote:
>>>
>>> No, I know the difference.  What I'm saying is that the OS X clients
>>> aren't translating DN-valued LDAP group membership
>>> attributes to UID-valued POSIX group memberships.  On Linux, this is
>>> done
>>> with nss_ldap/nss_ldapd/nslcd by either:
>>>
>>> a) parsing the group membership attributes, which are listed as DN's,
>>> and
>>> returning just the portion between the 'uid='
>>> and the next comma (e.g., if the DN was
>>> 'uid=jdoe,ou=Users,dc=example,dc=org', nslcd would translate that to
>>> 'jdoe', for
>>> use as a POSIX group member), or
>>>
>>> b) issuing a second lookup to map the UID corresponding to that
>>> particular
>>> DN (kind of the way slapo-rwm can if
>>> configured to).
>>>
>>> In other words, I'm what I'm proposing to do is exactly what
>>> nss_ldapd/nslcd does, only in a proxy database on the
>>> server side in the server's response to the client, instead of on the
>>> client side of that response.
>>>
>>> The *only* reason I'm doing this is because it's not being done on OS X
>>> machines by Directory Service's LDAPv3 plugin
>>> (the equivalent to Linux's nss_ldap plugin for NSS), and I cannot
>>> change
>>> the way the LDAPv3 plugin works by hacking its
>>> code, as doing so could void the warranty and support and all that
>>> other
>>> proprietary nonsense.  So my only choice is to
>>> do it in the response on the server side, instead of in the response on
>>> the client side.
>>>
>>> And, since this is going to be done by means of a virtual naming
>>> context
>>> with slapd-meta and slapo-rwm, only the OS X
>>> clients will be using that virtual naming context.  Everybody else, who
>>> does it properly on the client side, will use
>>> the real naming context.  The main reason for the OP was to verify
>>> whether
>>> or not the implementation I proposed would
>>> actually *work*, regardless of whether or not it was advisable from a
>>> policy standpoint.  If by "invalid", you mean
>>> "will not work" (and not "it is not advisable to do so"), then that is
>>> fine and I'll find some other way around this
>>> problem (somehow...) - so if you wouldn't mind clarifying your
>>> response, I
>>> would be appreciative.
>>
>> Well, perhaps you should then have a look at slapo-nssov
>> (contrib/slapd-modules/nssov/); someone else on this list may give you
>> better support than I could in setting it up appropriately.
>>
>> p.
>>
>
>
> No; nssov is irrelevant here - that would only work for Linux clients, and
> they're the ones who perform the DN-to-UID
> translations appropriately.  I know that this isn't just an issue for me;
> O'Reilly have even made passing references in
> their books about the fact that Apple's LDAPv3 Directory Services plugin
> does not handle DN-valued group memberships
> appropriately (third paragraph from the bottom):
> http://macdevcenter.com/pub/a/mac/2003/08/26/active_directory.html?page=2
>
> That was 7 years ago, and they still haven't fixed it.  Wonder what the
> odds are that they'll have a change of heart?  :P
>
> Thanks anyways, though, for taking a gander at this.  I'm going to try and
> implement the workaround I mentioned above
> for those OS X hosts, as a stopgap (hopefully a stopgap and not permanent,
> anyways...) until and if Apple updates the
> plugin to allow DN-valued group memberships, as they do for Active
> Directory.  Hopefully it works.  I wish I could say
> that I find it ironic that they would get it right with AD and not with
> *nix, but I digress...

Slapo-rwm (and back-meta, which mimics it) by design only rewrite
DN-valued attrs, and only rewrite them to DN values.  This is for two
reasons:

1) DN-rewriting makes sense in distributed directories, virtual views and
so on

2) otherwise, people would abuse it, opening too many cans of worms, or
would use it, like in your case, to workaround broken clients, thus
allowing those clients to live forever shifting to the DSA all the burden
of working around their issues.

In any case, hacking slapo-rwm for your purpose shouldn't be very
difficult: you should simply hack where, after rewriting, the syntax of
the rewritten attrs is checked.  In the case of searchResult this occurs
in rwm_dnattr_result_rewrite() by calling
rwm_dn_massage_pretty_normalize().  You can replace that call simply by
rwm_dn_massage() (with some memory bookkeeping, possibly).

If you succeed, please do not submit patches, as they'll likely be
rejected.  The "right" way to solve the issue would be to design a
"slapo-apple" overlay that hides all the hacks required by that client.

p.