s4:Disabling read access for anonymous

[Nadezhda Ivanova]

Hi Andrew,
The ideal case would be indeed to have a separate system connection for the
ldap server, but as I understand it, this actually means another ldb
context, does it not. as the session is associated with the ldb. Is this
possible?
As for your idea about the additional module, I am not sure it will work, I
have to think about if after I sleep for a few hours :). Besides, the
problems we face for anonymous could potentially exist for all other
non-privileged accounts. What happens if a user does not have access to NDTS
Settings or attributes of the defaultNamingContext for some reason? This
would mean that all acl search checks will only apply for the LDAP server.
It actually makes sense for it to be this way. I could certainly try it out.


Regards,
Nadya

On Fri, Jul 16, 2010 at 3:37 AM, Andrew Bartlett <abartlet at samba.org> wrote:

> On Fri, 2010-07-16 at 00:11 +0300, Nadezhda Ivanova wrote:
> > Hi all,
> > Today I experimentally made read access for unauthenticated users
> dependent
> > on dsHeuristics. By default, ANONYMOUS should have access only to
> rootDSE,
> > other searches are denied. I did the check in root dse, but I will
> probably
> > move it. So, just as I feared, the results in make test were
> catastrophic.
> > ldap.ldb tests failed, also a lot of the samr tests. The reason is that
> > these need access to some data in ldb, and they use anonymous connection.
> > For samr it was dcesrv_samr_QueryDomainInfo, for the ldap server
> > ldapsrv_load_limits kept complaining, and other tests. I am sure that we
> > might get lots of the same errors when regular search access checks are
> > implemented and we restrict access. So we will need some way to skip acl
> > checks when the database is accessed internally.
>
> Yes, it certainly seems as if the restriction on anonymous is not done
> at an ACL layer that applies to all protocols, but instead anonymous
> access is denied sporadically across the different protocols, then ACLs
> are subsequently applied.  On SAMR and LSA there has been the concept of
> 'restrict anonymous' for quite some time now.
>
> However, some of the cases you mention above should be easier to solve
> than that:  For example, the LDAP server's ldapsrv_load_limits should be
> done on a SYSTEM connection, that isn't then used for the user.
>
> Perhaps we could simply have an 'ldap server restrictions' module that
> we load in front of samba_dsdb (but only from the LDAP server)?  This
> would enforce that only published controls are permitted (so that, no
> matter what, we don't permit SYSTEM_ONLY over LDAP) and would restrict
> anonymous access to just the rootdse if the flag is set?
>
> > My current idea is the following:
> > Use the as_system control (which I hate) or some other, and modify the
> > gendb_search apis to always supply this control. Also add a separate
> > function for the ldap server that uses it, for the purposes of retrieving
> > these parameters. Add an acl_search module to handle the search checks,
> and
> > put it immediately under root dse, so the other modules of the stack
> don't
> > have to bother using the control.
>
> This would mean that information that was meant to be hidden would be
> exposed by the behaviour of the other modules.  Would that be safe?
>
> > I believe this will solve a lot of the
> > problems and still allow us to have the proper behavior, and given that
> its
> > reading and not writing, its not so risky.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/<http://samba.org/%7Eabartlet/>
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.
>
>