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

Wed Oct 7 15:32:04 UTC 2015

On 10/07/2015 05:29 PM, Simo Sorce wrote:
> On 07/10/15 11:06, thierry bordaz wrote:
>> 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)"
>
> It is not an option, no changing attributes, no changing syntaxes, if 
> DS can't be fixed we'll need to adopt a completely different strategy 
> we discussed already previously.
> However it would be much nicer if we could fix DS to allow to create 
> (and use) indexes for matching rules that are not defined in the schema.
Ok I understand... and agree. Let's investigate what's need to be done 
in DS :-)
>
> Simo.
>