#50677 Allow subtree search with empty base to be a search over default naming context
Closed: fixed 3 months ago by mreynolds. Opened 3 months ago by abbra.

Issue Description

Windows systems issue requests with empty base and subtree search against global catalog service. This seems to get resolved as a search against default naming context.

For example, below is a search I have against AD Global Catalog (Windows Server 2016):

# ldapsearch -E '!pr=1024' -Y GSS-SPNEGO -h metis.ad.ipa.cool -p 3268 -b '' "(&(|(&(sAMAccountType=*)(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10))(sAMAccountType=805306368))(|(name=ab*)(sAMAccountName=ab*)(displayName=ab*)(msDS-PhoneticDisplayName=ab*)))" name objectClass userAccountControl userPrincipalName mail sAMAccountName description objectSid
SASL/GSS-SPNEGO authentication started
SASL username: ab@XS.IPA.COOL
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(|(&(sAMAccountType=*)(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10))(sAMAccountType=805306368))(|(name=ab*)(sAMAccountName=ab*)(displayName=ab*)(msDS-PhoneticDisplayName=ab*)))
# requesting: name objectClass userAccountControl userPrincipalName mail sAMAccountName description objectSid 
# with pagedResults critical control: size=1024
#

# a b, Users, ad.ipa.cool
dn: CN=a b,CN=Users,DC=ad,DC=ipa,DC=cool
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
name: a b
userAccountControl: 66048
objectSid:: AQUAAAAAAAUVAAAAZ6LXUDqjySZHQCxgZwQAAA==
sAMAccountName: ab
userPrincipalName: ab@ad.ipa.cool

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MIQAAAAFAgEABAA=
pagedresults: cookie=

# numResponses: 2
# numEntries: 1

This is the search I get from Windows Server 2016 against my implementation of the global catalog based on 389-ds:

[29/Oct/2019:15:05:55.063261967 +0100] conn=4 fd=64 slot=64 connection from metis.ad to nyx.xs
[29/Oct/2019:15:05:55.063905568 +0100] conn=4 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry dsservicename namingContexts defaultnamingcontext schemanamingcontex
t configurationnamingcontext rootdomainnamingcontext supportedControl supportedLDAPVersion supportedldappolicies supportedSASLMechanisms dNSHostName ldapservicename serverName supportedcapab
ilities"
[29/Oct/2019:15:05:55.065813135 +0100] conn=4 op=0 RESULT err=0 tag=101 nentries=1 etime=0.0002483301
[29/Oct/2019:15:05:55.406262247 +0100] conn=4 op=1 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
[29/Oct/2019:15:05:55.428532728 +0100] conn=4 op=1 RESULT err=0 tag=97 nentries=0 etime=0.0022385844 dn="uid=read-only-principal,cn=configuration,dc=xs,dc=ipa,dc=cool"
[29/Oct/2019:15:05:55.430418096 +0100] conn=4 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry supportedControl supportedcapabilities schemanamingcontext"
[29/Oct/2019:15:05:55.431174625 +0100] conn=4 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0002612749
[29/Oct/2019:15:05:55.432636993 +0100] conn=4 op=3 SRCH base="" scope=2 filter="(&(|(&(sAMAccountType=*)(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)
(groupType:1.2.840.113556.1.4.804:=10))(sAMAccountType=805306368))(|(name=ab*)(sAMAccountName=ab*)(displayName=ab*)(msDS-PhoneticDisplayName=ab*)))" attrs="name objectClass userAccountContro
l userPrincipalName mail sAMAccountName description objectSid"
[29/Oct/2019:15:05:55.432717796 +0100] conn=4 op=3 RESULT err=0 tag=101 nentries=0 etime=0.0001498473 notes=P details="Paged Search" pr_idx=0 pr_cookie=-1
[29/Oct/2019:15:05:59.551003877 +0100] conn=4 op=15 UNBIND

As you can see, it does subtree search against empty base and expects it to come as a normal search against a default naming context. Unfortunately, MS-ADTS document is very ambigous in how this should be treated. However, at least phonetic display name sort searches require search against empty base: MS-ADTS 3.1.1.3.4.1.13
LDAP_SERVER_SORT_OID and LDAP_SERVER_RESP_SORT_OID: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/6b7b93f1-7c1a-45c2-9544-c067b94bba20


The LDAP RFC's do not dictate what to do if a null basedn search (aka root DSE search) is performed using a subtree scope. The only requirement is that the Root DSE entry can only be retuned if it's a base scope search. Anything else seems to be fair game as to how we want to handle the search for different scopes. Mapping it to the default naming context for non-base scope searches seems perfectly acceptable to me, especially if it eases the interactions with other LDAP vendors.

Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

3 months ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

3 months ago

Thanks, the patch worked quite well:

# ldapsearch -E '!pr=1024' -Y GSS-SPNEGO -h nyx.xs.ipa.cool -p 3268 -b '' "(&(|(&(sAMAccountType=*)(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10))(sAMAccountType=805306368))(|(name=ab*)(sAMAccountName=ab*)(displayName=ab*)(msDS-PhoneticDisplayName=ab*)))" name objectClass userAccountControl userPrincipalName mail sAMAccountName description objectSid
SASL/GSS-SPNEGO authentication started
SASL username: ab@XS.IPA.COOL
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(|(&(sAMAccountType=*)(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10))(sAMAccountType=805306368))(|(name=ab*)(sAMAccountName=ab*)(displayName=ab*)(msDS-PhoneticDisplayName=ab*)))
# requesting: name objectClass userAccountControl userPrincipalName mail sAMAccountName description objectSid 
# with pagedResults critical control: size=1024
#

# Alexander Bokovoy, users, xs.ipa.cool
dn: CN=Alexander Bokovoy,cn=users,dc=xs,dc=ipa,dc=cool
name: Alexander Bokovoy
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: ad-top
objectClass: ad-organizationalPerson
objectClass: user
objectClass: securityPrincipal
objectClass: posixAccount
objectClass: inetUser
userAccountControl: 66048
userPrincipalName: ab@xs.ipa.cool
mail: ab@xs.ipa.cool
sAMAccountName: ab
objectSid:: AQUAAAAAAAUVAAAAblz7IUjf4sZPfPtE6QMAAA==

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQAEAA==
pagedresults: cookie=

# numResponses: 2
# numEntries: 1

Commit 5e338e9 relates to this ticket

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue set to the milestone: 1.4.2
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata
Related Pull Requests