masarati@aero.polimi.it wrote:
masarati@aero.polimi.it wrote:
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...
Slapo-rwm (and back-meta, which mimics it) by design only rewrite DN-valued attrs, and only rewrite them to DN values.
Bummer for me.
This is for two reasons:
- DN-rewriting makes sense in distributed directories, virtual views and
so on
Agreed; I saw a lot of other practical uses for it during my research.
- otherwise, people would abuse it, opening too many cans of worms, or
would use it, like in your case, to workaround broken clients, thus allowing those clients to live forever shifting to the DSA all the burden of working around their issues.
Agreed here as well. I can completely understand the justifications.
In any case, hacking slapo-rwm for your purpose shouldn't be very difficult: you should simply hack where, after rewriting, the syntax of the rewritten attrs is checked. In the case of searchResult this occurs in rwm_dnattr_result_rewrite() by calling rwm_dn_massage_pretty_normalize(). You can replace that call simply by rwm_dn_massage() (with some memory bookkeeping, possibly).
I may give this a shot, thanks for the tip.
If you succeed, please do not submit patches, as they'll likely be rejected. The "right" way to solve the issue would be to design a "slapo-apple" overlay that hides all the hacks required by that client.
p.
I think this is a good idea, given the speed with which Apple usually addresses things like this. But it will probably have to wait until I've had a chance to resolve some other outstanding issues, such as ITS#6540, before I can take the time to write an overlay from scratch.
Again, many thanks for the advice.
Respectfully, Ryan