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

[abbra]

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]

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

[abbra]

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

[tbordaz]

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]

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]

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]

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