On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: > On 06/10/15 08:04, David Kupka wrote: > >On 06/10/15 13:35, Simo Sorce wrote: > >>On 06/10/15 03:51, thierry bordaz wrote: > >>>On 10/06/2015 07:19 AM, David Kupka wrote: > >>>>On 05/10/15 16:12, Simo Sorce wrote: > >>>>>On 05/10/15 09:00, Martin Babinsky wrote: > >>>>>>These patches implement the plumbing required to properly support > >>>>>>canonicalization of Kerberos principals ( > >>>>>>https://fedorahosted.org/freeipa/ticket/3864). > >>>>>> > >>>>>>Setting multiple principal aliases on hosts/services is beyond the > >>>>>>scope > >>>>>>of this patchset and should be done after these patches are pushed. > >>>>>> > >>>>>>I will try to send some tests for the patches later this week. > >>>>>> > >>>>>>Please review the hell out of them. > >>>>> > >>>>>LGTM, I do not see any issue at quick visual inspection. > >>>>>What about the performance regression with the indexes ? Is that bug > >>>>>fixed in 389ds ? > >>>>> > >>>>>Simo. > >>>>> > >>>>> > >>>> > >>>>The issue is still there. Thierry investigated this in 389 DS and IIUC > >>>>he is not sure if it's bug or completely missing feature. Therefore we > >>>>still don't know how much time is needed there. > >>>> > >>>Hi, > >>>that is correct. > >>>I can reproduce the problem. Although the matching rule (in my test > >>>caseIgnoreIA5Match) is found, it has no registered indexing function, so > >>>the setting (nsMatchingRule) is ignored. > >>>I do not know if the indexing function is missing or there is a bug so > >>>that the matching rule "forget" to register it. > >>>This feature is documented but I can not find any QA test around it, so > >>>I do not know yet if it is a regression or if it was not enabled at all. > >>> > >>>I do not expect rapid progress on it. How urgent is it ? 7.3 ? > >>>For the moment I can think to only two workarounds: > >>> > >>> * use filtered matching rule (preferred) > >>> * change the attribute syntax/matching rule, in the schema (I would > >>> discourage this one because changing the schema is risky) > >> > >>We can't change the syntax at this point. > >> > >>Well this patchset is blocked until the 389 ds bug is fixed (the > >>performance regression is too big to just put it in and hope) so I guess > >>we'll have to negotiate a time for the fix. > >> > >>Simo. > >> > > > >I agree that we really shouldn't change schema. > > > >But I don't think the patches're necessary blocked by this issue. > >Canonicalization was never supported in FreeIPA and when it is not > >requested the performance is not effected at all. We could merge patches > >as soon as they're carefully reviewed and tested to avoid tedious > >rebasing and start using the new functionality when 389 DS gets fixed. > > The fact we didn't do canonicalization this way doesn't mean clients aren't > asking for it. > > I think Windows clients ask for canonicalization by default, and in SSSD I > see we turn on by default krb5_canonicalize in the IPA nd LDAP case (oddly > enough not in the AD case ?) > > So SSSD's authentication requests would end up hitting this case all the > time if I am reading the code correctly (CCed Jakub to confirm/dispel this).
We ask for canonicalization always in IPA and LDAP, but also whenever enterprise principals are used, which is true for AD provider. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
