This bug was initially created as a copy of Bug #1958909

I am copying this bug because: 
RHEL 9 is also affected by this issue.


Description of problem:

On Rhel8 IPA server, there is a difference in ldapsearch behavior against “compat” tree with scope set as “base” compared to Rhel7 IPA server.

Version-Release number of selected component (if applicable):

Red Hat Enterprise Linux release 8.3
ipa-server-4.8.7-13.module+el8.3.0+8376+0bba7131.x86_64

How reproducible:

Always

Steps to Reproduce:
1. IPA server with AD trust
2. Run ldapsearch against compact tree with " -s base"
   # ldapsearch -h 127.0.0.1 -D "cn=Directory Manager" -W  -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL

Actual results:

Rhel7:
[root@ipareplica ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W  -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL
dn: cn=admins,cn=groups,cn=compat,dc=example,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
gidNumber: 1769000000
memberUid: admin
ipaAnchorUUID:: OklQQTpzdWIuaXBhZXhhbXBsZS5jb206ODE5MmRlZDAtYTBjZC0xMWVhLWI1MD
 ItMDAxYTRhMjIzYWEy
cn: admins

[root@ipareplica ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W  -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s sub -xLLL
dn: cn=admins,cn=groups,cn=compat,,dc=example,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
gidNumber: 1769000000
memberUid: admin
ipaAnchorUUID:: OklQQTpzdWIuaXBhZXhhbXBsZS5jb206ODE5MmRlZDAtYTBjZC0xMWVhLWI1MD
 ItMDAxYTRhMjIzYWEy
cn: admins

Rhel8:
[root@ipa1 ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s base -xLLL
Enter LDAP Password:
No such object (32)
Matched DN: dc=example,dc=com


[root@ipa1 ~]# ldapsearch -h localhost -D "cn=Directory Manager" -W -b "cn=admins,cn=groups,cn=compat,dc=example,dc=com" -s sub -xLLL
Enter LDAP Password:
dn: cn=admins,cn=groups,cn=compat,dc=example,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
gidNumber: 964400000
memberUid: admin
ipaAnchorUUID:: OklQQTphZGkuY29tOjA2ZWZhMGMwLTViZDMtMTFlYi04MDNmLTAwMWE0YTIyMz
 k5Mw==
cn: admins


Expected results:

ldapsearch with scope set as base should return correct information.

Additional info:

There are no code changes between RHEL 7 and RHEL 8 versions of slapi-nis with regards to this behavior. This is controlled by the function 'backend_should_descend()' which has
the following definition which didn't change since 2008:

static bool_t
backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope)
{
        switch (scope) {
        case LDAP_SCOPE_BASE:
                /* The target DN needs to be a subordinate of this entry, but
                 * not actually be the entry itself. */
                if ((slapi_sdn_issuffix(target_dn, this_dn) != 0) &&
                    (slapi_sdn_compare(target_dn, this_dn) != 0)) {
                        return TRUE;
                }
                break;
        case LDAP_SCOPE_ONELEVEL:
                /* The target DN needs to be a subordinate of this entry, or
                 * be the entry itself. */
                if (slapi_sdn_issuffix(target_dn, this_dn) != 0) {
                        return TRUE;
                }
                break;
        case LDAP_SCOPE_SUBTREE:
                /* The target DN needs to be a subordinate of this entry, or
                 * this entry needs to be a subordinate of the target. */
                if ((slapi_sdn_issuffix(target_dn, this_dn) != 0) ||
                    (slapi_sdn_issuffix(this_dn, target_dn) != 0)) {
                        return TRUE;
                }
                break;
        default:
                break;
        }
        return FALSE;
}