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.