Blocking anonymous LDAP operations and interaction with dsHeuristics

Andrew Bartlett abartlet at
Thu Nov 25 14:22:52 MST 2010

On Fri, 2010-11-26 at 08:18 +1100, Andrew Bartlett wrote:
> On Thu, 2010-11-25 at 13:10 +0200, Nadezhda Ivanova 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. 
> Except that you are missing one important point:  This isn't just about
> reads!  This needs to be about every LDAP operation, reads, writes,
> extended operations etc. 
> Currently (for better or worse) rootDSE blocks the use of unregistered
> LDAP operations, and using rootDSE allows us not to allow security
> bypass for @ records (even if LDAP clients are currently technically
> unable to read them, I feel a bit happier without the exception). 

BTW, an alternative would be an access checking module placed *above*

> > 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...
> I see you just changed the tests.  Thanks!
> Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the samba-technical mailing list