The implementation of aliases support has been 'unfortunate'. The only case that was considered is case-insensitive searches and the code unnecessarily adds a new attribute, but most importantly forces it to be a single value.
The only reason a new attribute was added is because krbPrincipalName is marked caseExactIA5Match, and DS wouldn't perform insensitive matches. However KrbPrincipalName is not single valued, and on purpose, because when aliases are used KrbCanonicalName becomes the 'real' name, and KrbPrincipalName holds all the aliases. note that the code never adds a proper KrbCanonicalName either.
The introduction of krbPrincipalAlias actually breaks support for aliases as it is defined SINGLE value, therefore multiple aliases cannot be added.
I suggest we correct this oversight by changing the Kerberos schema and modifying the framework to completely ignore ipakrbprincipalalias, by deprecating it and finally removing it in ipa 4.x
We cannot remove ipakrbprincipalalias now because it would break other replicas when the first one is upgraded. We can only stop using it, stop adding it by default in new installations (relis on replication to carry it forward on old installations), and drop it completely at a future date.
I suggest we change KrbPrincipalName to the following definition: attributetypes: ( 2.16.840.1.113719.1.301.4.1.1 NAME 'krbPrincipalName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
NOTE: Here I did not change EQUALITY and SUBSTR matching only but also the SYNTAX type, from IA5String to DirectoryString. We have evidence that Microsoft does support use of unicode names in principals, also the MIT code is agnostic and will use UTF-8 names w/o issues. So restricting our code to only IA5Strings is an unwanted limitation.
NOTE: This change is forward compatibile, and our framework still enforces ASCII only names in principals and DNS names for now, so this doesn't change much in practice at the moment, but allows us in future to fully enable internationalized principal names.
At the same time I suggest we change also krbCanonicalName to: attributetypes: ( 1.2.840.113554.1.4.1.6.1 NAME 'krbCanonicalName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE)
NOTE: Same reasonings as above. NOTE: We will change the framework to always set the canonical name, once we add the option to set aliases too.
ipakrbprincipalalias should be changed with the following and dropped later in v4 attributeTypes: (2.16.840.1.113730.3.8.11.32 NAME 'ipaKrbPrincipalAlias' DESC 'DO NOT USE - DEPRECATED' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3')
Actually I think we may drop ipakrbprincipalalias from new installs, needs some testing, but I think replication will keep it around in older installs. Need to be tested with replica creation.
3.4 development was shifted for one month, moving tickets to reflect reality better.
Slightly related ticket: #3961.
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
Simo, I think you will need to consider contributing a patch or ask somebody as there are no takers for a really long time.
Moving to further milestone.
We reviewed this ticket together with Dmitri and Simo and decided to postpone it as we do not have enough resources to finish it within 4.0 time frame.
No clone, #3961 would be cloned
This ticket is not critical for 4.2 GA and can be done in follow-up stabilization release - postponing.
In the description I suggest changing the schema for krbPrincipalName/krbCanonicalName I think we can obtain the same results by better validating names at store time. for example forcing the realm to alwys be the same case (as defined at installation) and then case changing it before the search if necessary. Also always lowercasing all the components (and again the same before a search), while keeping only krbCanonicalName case-sesnsitive.
With this method we can achieve full alias support and case-insensitive behavior w/o changing the schema. We just need to deprecate and remove krbprincipalaliases
FreeIPA 4.2.1 was released, moving to 4.2.x.
It won't make 4.3. Implementation is [ready] but is blocked by https://fedorahosted.org/389/ticket/48270 389 bug.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1117306 (Red Hat Enterprise Linux 7)
For information https://fedorahosted.org/389/ticket/48270 is now fixed upstream (adding it as 'blocked by')
After fixing https://fedorahosted.org/389/ticket/48270, several others bugs were found related to indexing with specific matching and use of ldap extensible match filter:
- https://fedorahosted.org/389/ticket/48497: Under certain condition it can prevent indexing with matching rule. If freeipa install script does a extensible match filter before indexing, then further indexing will fail. It may be a blocker - https://fedorahosted.org/389/ticket/48746: It crash DS when indexing with matching rules. It is not systematic. It is a blocker. - https://fedorahosted.org/389/ticket/48745: caseExactIA5Match incorrectly index strings with upper cases. It is a blocker
master:
ipapython/kerberos.py
Metadata Update from @simo: - Issue assigned to mbabinsk - Issue set to the milestone: FreeIPA 4.4
Login to comment on this ticket.