Blocking anonymous LDAP operations and interaction with dsHeuristics

Nadezhda Ivanova nivanova at
Thu Nov 25 02:40:56 MST 2010

Hi Andrew,
I don't think I like this patch very much - I deliberately moved this code
from rootDSE, because Windows behavior is that if you set the dsHeuristics
flag and give some access to Anonymous to some objects, you should be able
to see them with Anonymous connection. If we juts cut ia all off at rootDSE
this is not possible. We may of course choose not to support this
behavior...  What you could do is add the failing tests to knownfail,
actually I think they are already there as this module is disabled by
default. Instead of removing the code, could you make it dependent on
acl:search parameter in smb.conf, so that it is used if acl_read is not
enabled? It will make it easier for me to continue my work on the acl_read,
and revert your patch when the module is good enough.


On Thu, Nov 25, 2010 at 7:37 AM, Andrew Bartlett <abartlet at> wrote:

> Nadezhda,
> I've been working to create a 'half-way-house' solution, that can solve
> the issue of anonymous access to our directory, without invoking the
> full aclread solution, while we work on the performance of that code.
> I think it's really important for our users that we get a proper access
> control solution here, and I hope you agree that it's clearer to have
> this all done in one module, and with as little processing having
> already occurred as possible.
> Therefore, I attach a series of proposed patches, and pushed them to:
> The problem is, they fail 'make test', because expects that
> dhHeuristics is honoured live.  This implies that either we must somehow
> signal to every LDAP server instance whenever this value changes, or we
> must poll it for every operation.  Both seem inefficient.  Is this
> really the Windows behaviour?  Do you think we need to match it?  (I'm
> happy with a search per connection).

> Thanks,
> Andrew Bartlett
> --
> Andrew Bartlett                      <>
> Authentication Developer, Samba Team 
> Samba Developer, Cisco Inc.

More information about the samba-technical mailing list