After commit 0776ce5caedf18aa8cc1d1dddb1a425f3d0c926c (bug 15270), one of my production LDAP queries using LDAP_MATCHING_RULE_IN_CHAIN has stopped working. The same query using ldbsearch against sam.ldb works OK, but when the search is carried out using LDAP (either with ldbsearch or ldapsearch) it returns no results. Example search that now returns nothing after my DC upgrades; this exact search used to work just fine: (& (objectCategory=Person) (sAMAccountName=*) (memberOf:1.2.840.113556.1.4.1941:=CN=somegroup,OU=someou,DC=mydomain,DC=org) ) But if I remove the matching rule specifier, it does return a number of results: (& (objectCategory=Person) (sAMAccountName=*) (memberOf=CN=somegroup,OU=someou,DC=mydomain,DC=org) )
Hi Jonathan, Thank you for your initial investigation. I had once this issue in the past an didn't dig into it much further (I could have a workaround). Could you please check if you have some GPO where "Authenticated Users" token has been removed from the ACE ? I have been able to reproduce the issue with the following scenario: * removes the "Authenticated Users" token on the ACE on a GPO entry (any GPO will do) on CN=<GPO_GUID>,CN=Policies,CN=System. You can remove it from gpmc.msc into delegation tab on the target GPO. * run ldbsearch -H ldap://$(hostname -s) '(&(ObjectClass=*)(memberof:1.2.840.113556.1.4.1941:=cn=group1,cn=users,dc=testad-9y3tb,dc=int))' dn -U user1%password1 I get the following error message : "search error - LDAP error 1 LDAP_OPERATIONS_ERROR - <00002020: Indexed and full searches both failed!" There is nothing in the logs below loglevel 10 on the server side, and it is not categorized (it falls in the "all" category), but when searching the needle in the haystack, one can find this error message: ldb_request SUB dn=dc=testad-9y3tb,dc=int filter=(&(ObjectClass=*)(memberof:1.2.840.113556.1.4.1941:=cn=group1,cn=users,dc=testad-9y3tb,dc=int)) Access on CN={81989F0C-7601-4C22-928D-82E60BE5DEEC},CN=Policies,CN=System,DC=testad-9y3tb,DC=int deniedSecurity context: : struct security_token Note : the error can be triggered only if one use the memberof:1.2.840.113556.1.4.1941 OID for nested group search, otherwise it works properly. I have not tried to check if it succeed when removing the commit you referenced in your message, but it looks like the same issue. Cheers, Yohannès, Simon, Denis
Created attachment 18211 [details] patch for testing I think this patch will tell you where in the chain the problem is. My suspicion is that the transitive search hits a point where permission is denied. What should happen at that point is the question -- should that branch be clipped off the results, or (as seems to happen now) the whole tree be hidden. If it reports no error, or the error is not related to access rights, then I'm completely wrong and/or something worse or more interesting is happening.
This bug was referenced in samba master: cebe12bc85a7f178e7ccaecd1c075f2e40478139