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


Respectfully,
Ryan