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

On Wed, 2023-11-22 at 17:33 +0000, Jonathan Hunter
wrote:
> On Wed, 22 Nov 2023 at 01:03, Andrew Bartlett <
> abartlet at samba.org
> > wrote:
> > Are you sure that the ACLs on all the items in the chain should
> > allow reading?
> 
> It's an excellent question, thank you - I'd like to just say
"Yes"
> but
> I will certainly check, as it's of course possible that my domain was
> misconfigured previously, and the change has in fact introduced
> correct behaviour..
> 
> Am I right in thinking that the objects I need to look at are
> - the group itself
> - all (some?) members of the group
> - any others?
The full chain.
> 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. 
>  And I believe I'm
> correct in thinking that a user can be a member of a group, even
> though that user might not have permission to read the group
> themselves...?
They can be members, when Samba assigns group memberships it does as
'system' via other code, but reading them via this mechanism for an
unprivileged user won't work. 

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead                https://catalyst.net.nz/services/samba
Catalyst.Net Ltd

Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company

Samba Development and Support: https://catalyst.net.nz/services/samba

Catalyst IT - Expert Open Source Solutions

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