[Date Prev][Date Next]
Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database
>> email@example.com wrote:
>>>> firstname.lastname@example.org 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.
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...