Blocking anonymous LDAP operations and interaction with dsHeuristics

Nadezhda Ivanova nivanova at
Thu Nov 25 04:10:56 MST 2010

Hi Andrew,
Sorry, wrong wording on my part, what I meant is that initially in the
process of implementation I added this code to rootDSE, but moved it in
acl_read later. Logically this seems like access list functionality, with
the dsHeuristics flag controlling whether the SD permissions are being taken
into account for anonymous or we always deny access. Whether to allow or
deny an action based on the security token is an access module
functionality. I also do not see the problem with the acl_read module being
that one clear spot that this is done. I guess there is no technical reason
not to put it in rootDSE, I just believe that logically it does not belong
there. If you feel strongly it should be there, I suppose I can live with

As for polling dsHeuristics - the tests in did pass against windows
when I wrote them, so I guess it is expected to poll it every time or
synchronize LDB in some way. If we decide to not support this behavior, we
have to rewrite them in a way that will not compromise the actual tests, e.g
re-establishing the connection after we modify dsHeuristics. You can push
your patch and I can fix the tests later, they are in knownfail anyway, but
is it correct to modify the tests to match a behavior rather than the
opposite? This will just hide a difference of behavior and goes against the
idea of interoperability...


On Thu, Nov 25, 2010 at 12:06 PM, Andrew Bartlett <abartlet at>wrote:

> On Thu, 2010-11-25 at 11:40 +0200, Nadezhda Ivanova wrote:
> > Hi Andrew,
> > I don't think I like this patch very much - I deliberately moved this
> code
> > from rootDSE
> What of this code was in the rootDSE to start with?  I've never seen any
> general prohibition on anonymous operations before.
> > , 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.
> How is that a problem with my patch?.  Aside from the fact that it reads
> dsHeuristics only at connection time, this patch should do the same.
> > 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.
> Should we really be mixing the general prohibition on anonymous
> operations with the concept of ACLs on individual records?
> Similarly, what other part of the code prohibits all other anonymous
> operations?  We really should do that general prohibition in one, clear
> spot (kludge_acl was previously that clear spot, but this is now much
> further down the stack than I would prefer).
> Does this make my patch and approach any clearer?
> Thanks,
> Andrew Bartlett
> --
> Andrew Bartlett                      <>
> Authentication Developer, Samba Team 
> Samba Developer, Cisco Inc.

More information about the samba-technical mailing list