samba - Nov 2023 - LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?

Thank you Andrew and Rowland.

(Rowland - I tried 'samba-tool dsacl get', thank you! but found the
output hard to decipher so I used ldp.exe on Windows instead in the
end)

On Wed, 22 Nov 2023 at 20:22, Andrew Bartlett <abartlet at samba.org>
wrote:
>
> On Wed, 2023-11-22 at 17:33 +0000, Jonathan Hunter wrote:
> > Are permissions checked in a hiearchical fashion, i.e. if OU=myou
> > does
> > not allow a particular user to read it, then would
> > CN=somegroup,OU=myou still be denied regardless of the explicit
> > permissions on the CN=somegroup,OU=myou object?
>
> That is what I am getting at.  The full chain must be checked.
What I have found so far is

- For the object CN=mygroup,OU=myou,DC=mydomain,DC=org
  - The DACL has 32 ACEs - all Allow and no Deny; there seems to be no SACL
  - These include NT AUTHORITY\Authenticated Users with Read; Domain
Admins with Full Control; and others

- For the object OU=myou,DC=mydomain,DC=org
  - The DACL has 35 ACEs including one Deny (Everyone is not allowed
to 'Delete child, Delete, Delete tree') the rest are Allow; there
seems to be no SACL
  - These include NT AUTHORITY\Authenticated Users with Read; Domain
Admins with Full Control; and others

- For the object DC=mydomain,DC=org
  - The DACL is more complex with 41 ACEs
  - It does include NT AUTHORITY\Authenticated Users with Read;
Enterprise Admins with Full Control; Domain Admins with a few
specified rights; and others

I don't recall particularly restricting access to any of these (the
only change I've tried to make, and as far as I knew succeeded in
doing, was adding a group 'myou-admins' to be able to administer the
OU=myou in addition to 'Domain Admins').

But from the above DACLs, I think that there are sufficient
permissions that this CN=mygroup,OU=myou object should be OK to be
read and queried?

I haven't checked the DACL on each 'Person' member of the group -
there are 35+ members of this group from various OUs across the tree -
should I check the DACL on each member of the group (and the chain up
and down) also? I would have thought that a reduced search result
would be the response to my query, though, rather than just nothing,
if there was some permissions issue with some members?

The only restrictions I can remember adding were in a different part
of the tree, namely OU=restricted,OU=myou,DC=mydomain,DC=org (and also
a parallel OU=restricted,OU=myou2). These restricted OUs have only 4
ACEs in their DACL, and looking at these now I can see the workaround
I put in place for the other (possibly related) LDAP search issue I
had after upgrading. I'm thinking it would help if I drew a diagram to
illustrate the structure, as if the two search issues are linked, this
one might be easier to explain diagramatically - I'll get on with
that. (I had only emailed the list about this sample LDAP query as it
didn't involve any of my restricted OUs, or so I thought)

Reminder of my original LDAP query:
(&
    (objectCategory=Person)
    (sAMAccountName=*)
    (memberOf:1.2.840.113556.1.4.1941:=CN=mygroup,OU=myou,DC=mydomain,DC=org)
)

Thank you!

Jonathan

"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

Hi Jonathan and Andrew,
> Reminder of my original LDAP query:
> (&
>      (objectCategory=Person)
>      (sAMAccountName=*)
>     
(memberOf:1.2.840.113556.1.4.1941:=CN=mygroup,OU=myou,DC=mydomain,DC=org)
> )
I came across the same/similar issue yesterday and found the origin that 
triggered the issue (at least in my case). I've added a response to your 
bugzilla entry [1].

To make it short, if you have a GPO where "Authenticated Users"
security
token has been removed from the ACE, then the 
memberOf:1.2.840.113556.1.4.1941 OID does not works anymore for anyone 
but "Domain admins" members...

It look like a bug introduced when fixing the CVE-2023-0614. I didn't 
had time to investigated more as it was ok to re-introduce 
"Authenticated Users" to those GPO (the delegated admin was a bit too 
zealous when removing that security token).

Cheers,

Yohann?s, Simon and Denis



[1] https://bugzilla.samba.org/show_bug.cgi?id=15515
> 
> Thank you!
> 
> Jonathan
> 
> "If we knew what it was we were doing, it would not be called
> research, would it?"
>        - Albert Einstein
> 

*Yohann?s ALEMU*
*Team Leader Technique*
Tranquil IT
12 avenue Jules Verne (B?t. A)
44230 Saint S?bastien sur Loire (FRANCE)
tel: +33 (0) 240 975 755
------------------------------------------------------------------------
Signature de mail : D?monstrations
<https://www.tranquil.it/demonstrationsgroupees/>
<https://www.tranquil.it/demonstrationsgroupees/>