[email protected] wrote: >> [email protected] 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: > > 1) 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. > 2) 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
