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


Respectfully,
Ryan