Blocking anonymous LDAP operations and interaction with dsHeuristics

Nadezhda Ivanova nivanova at
Thu Nov 25 04:44:16 MST 2010

On Thu, Nov 25, 2010 at 1:10 PM, Nadezhda Ivanova <nivanova at>wrote:

> 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
> that.
> 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 the other hand, most management tool seem to-rebind quite often, and
chances are very slim that dsHeuristics will be updated while someone else
is searching with anonymous and expecting a change of behavior. We could
leave that as a known issue, that these changes require reconnect.

> Regards,
> Nadya
> 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