s4:Disabling read access for anonymous

[Nadezhda Ivanova]

Hi list,
In connection to my effort to implement the search checks, I did a bit of
research on the SAMR, given that samr tests are among the failing ones, and
here is my conclusion.
What we already have implemented and I am still working on, are LDAP access
checks. It would be incorrect to apply them to the SAMR - or any other
protocol - for the following reasons:
1. The SAMR access lists have the same data format as the LDAP ones, but
different semantics - The flags in the access mask have different meanings
and are applied to different operations. For example, a flag of 0x00000040,
in LDAP is DELETE_TREE, in SAMR - create alias. The meaning is context
dependent and it would be impossible to map one to the other. In fact, it is
not even possible to use the same security descriptor for both protocols.
The relation between then is the same as between NT descriptors and DS
descriptors - format is the same, the check algorithm is the same, but the
meaning is different. If we want to have SAMR checks implemented, we need a
separate SD database for it, and/or a separate module in ldb if we decide to
go that way.
2. It is explicitly stated in MS-SAMR:
 Unless otherwise specified, the create, update, delete, and read access
checks enforced by the MS-ADTS data model (specified in [MS-ADTS] section
5.1.3) are not enforced during the message processing of this protocol.

This means that until we implement actual SAMR checks, the SAMR (and any
other protocols that may be related) must connect to ldb with system
session, or we should implement another mechanism to specify that the acl
module must not be applied to their operation. Your suggestions on how best
to handle this are welcome!

Best Regards,
Nadya

On Fri, Jul 16, 2010 at 4:03 AM, Nadezhda Ivanova <nivanova at samba.org>wrote:

> 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.
>>
>>
>