<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 10/08/2015 11:03 AM, David Kupka wrote: </div> <blockquote cite="mid:5616317D.7090504@redhat.com" type="cite">On 07/10/15 17:32, thierry bordaz wrote: <blockquote type="cite">On 10/07/2015 05:29 PM, Simo Sorce wrote: <blockquote type="cite">On 07/10/15 11:06, thierry bordaz wrote: <blockquote type="cite">On 10/07/2015 03:10 PM, David Kupka wrote: <blockquote type="cite">On 06/10/15 17:52, Jakub Hrozek wrote: <blockquote type="cite">On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: <blockquote type="cite">On 06/10/15 08:04, David Kupka wrote: <blockquote type="cite">On 06/10/15 13:35, Simo Sorce wrote: <blockquote type="cite">On 06/10/15 03:51, thierry bordaz wrote: <blockquote type="cite">On 10/06/2015 07:19 AM, David Kupka wrote: <blockquote type="cite">On 05/10/15 16:12, Simo Sorce wrote: <blockquote type="cite">On 05/10/15 09:00, Martin Babinsky wrote: <blockquote type="cite">These patches implement the plumbing required to properly support canonicalization of Kerberos principals ( <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/3864">https://fedorahosted.org/freeipa/ticket/3864</a>). 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. </blockquote> 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. </blockquote> 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. </blockquote> 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) </blockquote> 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. </blockquote> 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. </blockquote> 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). </blockquote> We ask for canonicalization always in IPA and LDAP, but also whenever enterprise principals are used, which is true for AD provider. </blockquote> 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 (<a class="moz-txt-link-freetext" href="http://fpaste.org/275847/44221770/raw/">http://fpaste.org/275847/44221770/raw/</a>) 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 (<a class="moz-txt-link-freetext" href="http://fpaste.org/275848/21793144/raw/">http://fpaste.org/275848/21793144/raw/</a>) 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. </blockquote> 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: <a class="moz-txt-link-abbreviated" href="mailto:user1000098@example.test">user1000098@example.test</a> uidNumber: 7611001000098 gidNumber: 7611001000098 displayName: Test User1000098 *krbPrincipalName: <a class="moz-txt-link-abbreviated" href="mailto:user1000098@EXAMPLE.TEST*">user1000098@EXAMPLE.TEST*</a> *krbCanonicalName: <a class="moz-txt-link-abbreviated" href="mailto:user1000098@EXAMPLE.TEST*">user1000098@EXAMPLE.TEST*</a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:(krbNonCanonicalname=user10000098@EXAMPLE.TEST)">"(krbNonCanonicalname=user10000098@EXAMPLE.TEST)"</a> </blockquote> 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. </blockquote> Ok I understand... and agree. Let's investigate what's need to be done in DS :-) <blockquote type="cite"> Simo. </blockquote> </blockquote> 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. </blockquote> Hello David, <blockquote>There is an upstream ticket tracking this issue (<a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/48270">https://fedorahosted.org/389/ticket/48270</a>). 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 </blockquote> </body> </html>