In case a Domain Admin has adjusted DSACLs to restrict read access e.g. to the "member" attribute, the SAMR call QueryGroupInfo still reports the information. Thus, admins cannot restrict visibility of group memberships like they can in MS AD. In this aspect, Samba differs from the behavior of MS AD. Judging from the code, it looks like aclread_search skips checks for non-LDAP-calls: https://gitlab.com/samba-team/samba/-/blob/master/source4/dsdb/samdb/ldb_modules/acl_read.c?ref_type=heads#L891 Since source4/ldap_server/ldap_backend.c explicitly calls ldb_req_mark_untrusted(req) to trigger the ACL checks, maybe a similar thing should be done in source4/rpc_server/samr/dcesrv_samr.c.
Created attachment 18182 [details] dirty-hack.patch This kind of shows what would help to get the ACL check working, but I guess this is not very great and the exact behavior of AD would need to be checked.
Comment on attachment 18182 [details] dirty-hack.patch I think we should just remove the ldb_req_is_untrusted check in aclread_search() at least if there's a session info attached to the ldb_context. We can rely on LDB_MODULE_HOOK_CMDLINE_PRECONNECT to setup system_session() and just check dsdb_module_am_system() in aclread_search().
FYI I checked behavior of MS (2019 client joined to 2012 AD DC): * If I add a ACE to "Domain Admins" via ADUC to deny full access to some user, then the command 'net group "domain admins" /domain' directly returns "System error 5 has occurred" and "Access denied". * If I more specifically deny read access to "member" only, then the first RPC Call samr_QueryDomainInfo succeeds and group name and description are shown to the user but then the same error code and message are returned for the second RPC call samr_QueryGroupMember (instead of an empty list of members which my dirty hack would return).