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
Metadata Update from @mreynolds: - Issue assigned to mreynolds
Created PR
https://pagure.io/389-ds-base/pull-request/50678
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.