s4:Disabling read access for anonymous

Tue Aug 31 07:31:22 MDT 2010

Hi Lukasz,
Nope, not yet. Disabling the anonymous access caused problems to other
protocols usilg the LDB and we had to figure out a way to avoid that. I
expect I should be able to finish all that by the end of the week, will let
you know.

Regards,
Nadya

On Tue, Aug 31, 2010 at 3:25 PM, Lukasz Zalewski <lukas at dcs.qmul.ac.uk>wrote:

> On 07/20/2010 02:41 PM, Nadezhda Ivanova wrote:
>
>> 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/><
>>>> http://samba.org/%7Eabartlet/>
>>>>
>>>> Authentication Developer, Samba Team           http://samba.org
>>>> Samba Developer, Cisco Inc.
>>>>
>>>>
>>>>
>>>  Nadya, all
> Can i assume that the LDAP restrictions on the anonymous access (based on
> dsHeuristics) has not been added yet? My experiments suggest that it is the
> case but would like to double confirm :)
>
> Thx
>
> Luk
>
>
>
>