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

Wed Oct 7 15:06:20 UTC 2015

On 10/07/2015 03:10 PM, David Kupka wrote:
> On 06/10/15 17:52, Jakub Hrozek wrote:
>> 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.
>>
>
> Then SSSD will hit this every time it requests ticket on behalf of user.
> But to be sure what the impact would be I've once again set up FreeIPA 
> server with 10K users and run some tests.
>
> 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without 
> specifying the matching rule).
> Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed 
> search takes ~100 times longer than indexed.
>
> 2) kinit with and without requested canonicalization.
>
> As we use kinit to get the ticket it makes sense to check what will 
> the performance hit be when we run kinit as a whole and not just an 
> isolated LDAP search.
> The results (http://fpaste.org/275848/21793144/raw/) shows that with 
> canonicalization it takes ~2 times longer than without it.
> While this is nothing to be happy about it's certainly better than I 
> would expect.
>
Clearly we need to make the search indexed.
In your deployment you defined:

    dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test
    uid: user1000098
    givenName: Test
    sn: User1000098
    cn: Test User1000098
    initials: TU
    homeDirectory: /home/user1000098
    gecos: Test User1000098
    loginShell: /bin/sh
    mail: user1000098 at example.test
    uidNumber: 7611001000098
    gidNumber: 7611001000098
    displayName: Test User1000098
    *krbPrincipalName: user1000098 at EXAMPLE.TEST*
    *krbCanonicalName: user1000098 at EXAMPLE.TEST*
    memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test
    objectClass: ipaobject
    objectClass: person
    objectClass: top
    objectClass: ipasshuser
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: krbticketpolicyaux
    objectClass: krbprincipalaux
    objectClass: inetuser
    objectClass: posixaccount
    objectClass: ipaSshGroupOfPubKeys
    objectClass: mepOriginEntry
    ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb
    mepManagedEntry: cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test

Would it be an option to create a new attribute, 'krbNonCanonicalName' 
(containing the krbprincipal) but with a 'caseignoreIA5' syntax ?
If this attribute is indexed, your lookup from a raw principal would 
user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)"

thanks
theirry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20151007/de919720/attachment.htm>