|Main Archive Page > Month Archives > openldap-software archives|
>> email@example.com 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):
>> 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.
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.