389-ds-base

Clone
Source Code
GIT

#50677 Allow subtree search with empty base to be a search over default naming context
Closed: wontfix 5 years ago by mreynolds. Opened 5 years ago by abbra.

Closed: wontfix
Reopen Issue

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
5 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
5 years 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)
5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3732

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
4 years ago

Log in to comment on this ticket.

Metadata
None
None
None
None
None
None
None
Related Pull Requests
Powered by Pagure 5.14.1
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.