[Samba] LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?

[Jonathan Hunter]

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