search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

index with both exact and case-insensitive match only matches exact matches #6164

Open abbra opened 4 months ago

abbra commented 4 months ago

FreeIPA uses exact and case-insensitive matches for krbPrincipalName, in the hope that both user@REALM and user@realm would match the entry with user@REALM value in krbPrincipalName:

[root@master1 ~]# dsconf IPA1-TEST backend index get --attr krbprincipalname userRoot
dn: cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: krbPrincipalName
nsIndexType: eq
nsIndexType: sub
nsMatchingRule: caseIgnoreIA5Match
nsMatchingRule: caseExactIA5Match
nsSystemIndex: false
objectClass: nsIndex
objectClass: top

However, case-insensitive match does not work for 389-ds-base 2.4.5 in Fedora 39:

[root@master1 ~]# ldapsearch '(krbprincipalname=admin@ipa1.test)' dn
SASL/GSSAPI authentication started
SASL username: admin@IPA1.TEST
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa1,dc=test> (default) with scope subtree
# filter: (krbprincipalname=admin@ipa1.test)
# requesting: dn 
#

# search result
search: 4
result: 0 Success

# numResponses: 1
[root@master1 ~]# ldapsearch '(krbprincipalname=admin@IPA1.TEST)' dn
SASL/GSSAPI authentication started
SASL username: admin@IPA1.TEST
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa1,dc=test> (default) with scope subtree
# filter: (krbprincipalname=admin@IPA1.TEST)
# requesting: dn 
#

# admin, users, accounts, ipa1.test
dn: uid=admin,cn=users,cn=accounts,dc=ipa1,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1
progier389 commented 4 months ago

Created associated ticket in jira: https://issues.redhat.com/browse/IDMDS-4370

abbra commented 3 months ago

I just tried on Fedora 40 and the same issue is reproducible with lmdb backend as well.

tbordaz commented 3 months ago

Just for confirmation, what is the equality matching rule of krbprincipalname ? is it caseExactIA5Match ? What is the result of "ldapsearch '(krbprincipalname:1.3.6.1.4.1.1466.109.114.2:=admin@ipa1.test)' dn' ?

abbra commented 3 months ago

With explicit matching rule:

[root@master1 ~]# ldapsearch '(krbprincipalname:1.3.6.1.4.1.1466.109.114.2:=admin@ipa1.test)' dn
SASL/GSSAPI authentication started
SASL username: admin@IPA1.TEST
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa1,dc=test> (default) with scope subtree
# filter: (krbprincipalname:1.3.6.1.4.1.1466.109.114.2:=admin@ipa1.test)
# requesting: dn 
#

# admin, users, accounts, ipa1.test
dn: uid=admin,cn=users,cn=accounts,dc=ipa1,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1

Without explicit matching rule:

[root@master1 ~]# ldapsearch '(krbprincipalname=admin@ipa1.test)' dn
SASL/GSSAPI authentication started
SASL username: admin@IPA1.TEST
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa1,dc=test> (default) with scope subtree
# filter: (krbprincipalname=admin@ipa1.test)
# requesting: dn 
#

# search result
search: 4
result: 0 Success

# numResponses: 1

Extract from indexes:

# dsconf IPA1-TEST backend index list userRoot

....
dn: cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: krbPrincipalName
nsIndexType: eq
nsIndexType: sub
nsMatchingRule: caseIgnoreIA5Match
nsMatchingRule: caseExactIA5Match
nsSystemIndex: false
objectClass: nsIndex
objectClass: top
....
tbordaz commented 3 months ago

Unless I am missing something the behavior looks normal to me. (I assume that 'krbPrincipalName' is exactIA5). With regular search, it uses the attribute's equality matching rule (caseExactIA5Match). With extended search it is using the client provided MR (caseIgnoreIA5Match) that matches the filter assertion 'admin@ipa1.test' with admin attribute value 'admin@IPA1.TEST'.

The index is only to make the search indexed (not notes=A) but you should get the same result with or without the index

abbra commented 3 months ago

So we should probably force the client side to use intended matching rule