[Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization

[Jakub Hrozek]

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.