[Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
David Kupka
dkupka at redhat.com
Thu Oct 8 09:03:57 UTC 2015
On 07/10/15 17:32, thierry bordaz wrote:
> 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.
>>
>
Thierry is focused mainly on integration of 389 DS and FreeIPA. Since
this is a general 389 DS issue and it is not related specifically to
FreeIPA could we ask 389 DS upstream for a fix?
In general extensible matching never uses indices. I believe this is
severe enough to be considered major issue by upstream.
--
David Kupka
More information about the Freeipa-devel
mailing list