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:
>>>
>>> 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?
>>
>> You seem to be confusing LDAP groups (groupOfNames objectClass, member
>> attribute) with POSIX groups (posixGroup objectClass, memberUid
>> attribute).  This has been sorted out long ago.  Use the right object
>> for
>> each application.  The rest of the discussion, at this point, seems
>> moot.
>>
>> p.
>>
>
>
> 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.