[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using back-meta or back-relay plus slapo-rwm as a proxy to a local database

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