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

We had to do a few changes in this area (due to security issues) over
that large number of releases, it is entirely possible there was a
regression. 

If you have time and patience, could you back up your DC, restore into
a subdirectory (on your DC or on a test box) with 4.11.10 from git, and
then do a git bisect between that and 4.18.5.

You can run the query locally with bin/ldbsearch -H /path/to/sam.ldb
from the build tree.

You won't need to install Samba, nor start it, ldbsearch should be
enough.

If a local ldbsearch passes on 4.18.5 but it fails over LDAP, that is
also a useful data point.

Andrew Bartlett

On Sun, 2023-11-05 at 22:25 +0000, Jonathan Hunter via samba
wrote:
> I'm quite confused by this one, as I can't see how this would
> happen..
> but after upgrading my DCs from 4.11.10 to 4.18.5, LDAP searches
> don't
> seem to work if they use the :1.2.840.113556.1.4.1941: modifier, aka
> LDAP_MATCHING_RULE_IN_CHAIN. (Yes, it was a fairly big version jump..
> Yes, I should have upgraded much earlier.. Yes, I know 4.19.x is out
> now as well)
> 
> Here's a 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=mydo
> main,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)
> )
> 
> The data in my AD hasn't changed; I am guessing that
> LDAP_MATCHING_RULE_IN_CHAIN is still supported in 4.18 and most
> likely
> something didn't quite go perfectly to plan during the upgrade of my
> DCs.
> 
> Looking at a sample user object, I can see the group listed in the
> user's memberOf attribute (i.e. the user is a direct member of the
> group) - so I'm not sure why a search using
> LDAP_MATCHING_RULE_IN_CHAIN simply returns no results now.
> 
> Are there any indexes or internal values I could check, to see if I
> can debug this any further? A 'samba-tool dbcheck --cross-ncs'
didn't
> reveal anything, but I'm not sure of the best way to investigate this
> one further.
> 
> Thanks for any pointers,
> 
> Cheers
> 
> Jonathan
> 
> -- 
> "If we knew what it was we were doing, it would not be called
> research, would it?"
>       - Albert Einstein
> 
-- 
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 for the quick reply - much appreciated.

Yes, I'll get on to this - I am certainly motivated to find out what's
happening here. It is likely to take a few days but I'll post my
findings.

I'll look at setting up git bisect today, it should be possible for me
to script it so that it will run by itself as I understand it, as I
should be able to check the return value of ldapsearch in order to
tell git bisect whether the result is good or bad.

There is also a separate issue I have run into after the upgrade (i.e.
not this specific LDAP query) which instead relates to permissions on
an OU set via a security descriptor, and searches failing after the
upgrade. That one's more involved to set up an easy test environment
for, I think, but it may well be related. I'll look at that second; I
have a workaround for it in my environment at least.

Thank you,

Jonathan

On Sun, 5 Nov 2023 at 23:03, Andrew Bartlett <abartlet at samba.org>
wrote:
>
> We had to do a few changes in this area (due to security issues) over
> that large number of releases, it is entirely possible there was a
> regression.
>
> If you have time and patience, could you back up your DC, restore into
> a subdirectory (on your DC or on a test box) with 4.11.10 from git, and
> then do a git bisect between that and 4.18.5.
>
> You can run the query locally with bin/ldbsearch -H /path/to/sam.ldb
> from the build tree.
>
> You won't need to install Samba, nor start it, ldbsearch should be
> enough.
>
> If a local ldbsearch passes on 4.18.5 but it fails over LDAP, that is
> also a useful data point.
>
> Andrew Bartlett
>
> On Sun, 2023-11-05 at 22:25 +0000, Jonathan Hunter via samba wrote:
> > I'm quite confused by this one, as I can't see how this would
> > happen..
> > but after upgrading my DCs from 4.11.10 to 4.18.5, LDAP searches
> > don't
> > seem to work if they use the :1.2.840.113556.1.4.1941: modifier, aka
> > LDAP_MATCHING_RULE_IN_CHAIN. (Yes, it was a fairly big version jump..
> > Yes, I should have upgraded much earlier.. Yes, I know 4.19.x is out
> > now as well)
> >
> > Here's a 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=mydo
> > main,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)
> > )
> >
> > The data in my AD hasn't changed; I am guessing that
> > LDAP_MATCHING_RULE_IN_CHAIN is still supported in 4.18 and most
> > likely
> > something didn't quite go perfectly to plan during the upgrade of
my
> > DCs.
> >
> > Looking at a sample user object, I can see the group listed in the
> > user's memberOf attribute (i.e. the user is a direct member of the
> > group) - so I'm not sure why a search using
> > LDAP_MATCHING_RULE_IN_CHAIN simply returns no results now.
> >
> > Are there any indexes or internal values I could check, to see if I
> > can debug this any further? A 'samba-tool dbcheck --cross-ncs'
didn't
> > reveal anything, but I'm not sure of the best way to investigate
this
> > one further.
> >
> > Thanks for any pointers,
> >
> > Cheers
> >
> > Jonathan
> >
> > --
> > "If we knew what it was we were doing, it would not be called
> > research, would it?"
> >       - Albert Einstein
> >
> --
> 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
>
>
>

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