[email protected] wrote: >> >> [email protected] wrote: >>>> [email protected] 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... Respectfully, Ryan
