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

[Simo Sorce]

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).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York