> On 05.05.2009 09:46, Cl?ment OUDOT wrote: >>> Hi Cl?ment :) >>> >> Hi Jon! >> >> Thanks for the quick reply. >> > > No problem :) > >>> Did you try using extensible filters? Like for example: >>> (&(objectclass=user)(!(ou:dn:=archives))) >>> >>> This is defined in the LDAP search filters RFC, and I think AD >>> implements it. >>> >> >> Oh, great idea! But my tests on AD are not successful... I found that: >> http://msdn.microsoft.com/en-us/library/cc223367(PROT.10).aspx >> >> It is written that AD only support 3 extensible match filters, and not >> the >> "dn:" trick. So I'm sad :( >> > > Hmmm. I tried it, and it seems to understand the filter, but only > matches the "ou" entry, not it's subentries... :(
Yes, if you run it on the branch, the "ou" attribute is in the entry, so extensible matching is not very interesting... >>>> What do you think of be able to put several values for >>>> lsc.tasks.inetOrgPerson.dstService.baseDn? LSC would do a search for >>>> each >>>> value, so we can manage several branches. >>>> >>>> >>> That's an interesting idea! Thanks for it. >>> >>> I considered the same problem a while ago, with a list of ~50 DNs. At >>> the time, I made a special source JNDI service that read an external >>> CSV >>> file containing the DNs. But I think your solution is neater. >>> >>> >> I'm happy that you like the idea. Do you think it is difficult to >> implement? >> > > No, it shouldn't be too hard. Would you create a feature request on > Redmine? Done: http://tools.lsc-project.org/issues/show/50 I had to reslove quickly my branches problem, so for now, I just duplicate my task and have so 2 tasks on 2 baseDn. It works well but my syncoptions rules are duplicated. Cl?ment.
