s4:dcesrv_samr_EnumDomainUsers - make this call look more similar to "EnumDomainGroups" and "EnumDomainAliases"

[Andrew Bartlett]

On Sun, 2010-06-13 at 21:40 +1000, Andrew Bartlett wrote:
> On Sun, 2010-06-13 at 09:43 +0200, Matthias Dieter Wallnöfer wrote: 
> > Andrew,
> > 
> > the original intention was to fix another bug which I didn't find in the 
> > SAMR RPC code since it is located/or not handled in the DSDB code. But 
> > so I cleaned up each function to be more consistent to their siblings 
> > (makes them easier to understand and maintain).
> > 
> > Back to my real bug: The problem is with linked attributes: if you 
> > remove one, it is marked as "removed" on the repl_meta_data 
> > (replication) level - but it does still exist. So the problem is, when 
> > you do a search eg (member=xxx) and there are entries with removed 
> > "member: xxx" attributes they are still returned! That shouldn't happen 
> > and confuses SAMR.
> > 
> > It would be really nice if you or someone else could fix this! I'm 
> > really not an expert in the "repl_meta_data" code.
> 
> Very interesting!
> 
> So, what needs to be done is to fix the syntax handler that is applied
> to these values (forward links), so that it is never possible to match
> on member= when it is actually a deleted value.  It would be good if
> this could be done for the indexes too, but this is not required, as we
> always filter with a full ldb_match anyway. 
> 
> To change the matching rules, we need to change the schema code to
> distinguish the link cases, and to handle them properly.  I've started
> to look into it, and I hope to get patch for you in the next few days.

Do you have a testsuite for this bug?  I've pushed my attempted fixes
for this to my drs-links-wip branch - if you could look at that I would
appreciate it.

Thanks,

Andrew Bartlett