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 (
Setting multiple principal aliases on hosts/services is beyond
of this patchset and should be done after these patches are
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
fixed in 389ds ?
The issue is still there. Thierry investigated this in 389 DS
he is not sure if it's bug or completely missing feature.
still don't know how much time is needed there.
that is correct.
I can reproduce the problem. Although the matching rule (in my test
caseIgnoreIA5Match) is found, it has no registered indexing
the setting (nsMatchingRule) is ignored.
I do not know if the indexing function is missing or there is a
that the matching rule "forget" to register it.
This feature is documented but I can not find any QA test around
I do not know yet if it is a regression or if it was not enabled
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
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
we'll have to negotiate a time for the fix.
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
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
asking for it.
I think Windows clients ask for canonicalization by default, and in
see we turn on by default krb5_canonicalize in the IPA nd LDAP case
enough not in the AD case ?)
So SSSD's authentication requests would end up hitting this case all
time if I am reading the code correctly (CCed Jakub to
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
Clearly we need to make the search indexed.
In your deployment you defined:
cn: Test User1000098
gecos: Test User1000098
displayName: Test User1000098
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
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code