[Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
thierry bordaz
tbordaz at redhat.com
Thu Oct 8 09:11:48 UTC 2015
On 10/08/2015 11:03 AM, David Kupka wrote:
> 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.
Hello David,
There is an upstream ticket tracking this issue
(https://fedorahosted.org/389/ticket/48270).
I started looking at it and discussing with DS team it requires more
investigation to determine the amount of work to do.
So far it is planned that I will continue this investigation and I
expect to complete this evaluation next week.
Now who will implement the fix, this is not decided yet.
thanks
thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20151008/3471e267/attachment.htm>
More information about the Freeipa-devel
mailing list