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

2016-06-23 Thread Martin Basti



On 23.06.2016 09:44, David Kupka wrote:

On 22/06/16 18:56, Simo Sorce wrote:

On Wed, 2016-06-22 at 18:36 +0200, Martin Babinsky wrote:

On 06/22/2016 06:26 PM, Simo Sorce wrote:

On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:

On 10/05/2015 03:00 PM, 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.





Long time no see.

I am attaching rebased infrastructure patches which were reviewed and
tested by David a year ago :). Now that all related DS bugs were 
fixed

and the patches still work as expected, we may push them so that the
plumbing for further work (API for alias handling etc.) is in place.



If the patches were all reviewed and tested I say push them.

Simo.



There is one problem remaining, however, that when a user is kinit'ing
for the first name using his alias and has to change password, the
operation fails:

"""
[root@master1 ~]# kinit -C talias
Password for tal...@ipa.test:
kinit: KDC reply did not match expectations while getting initial
credentials

"""

This is the related snippet from KDC log:

"""
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: CLIENT KEY EXPIRED:
tal...@ipa.test for krbtgt/ipa.t...@ipa.test, Password has expired
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down 
fd 12

Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: NEEDED_PREAUTH: tal...@ipa.test
for kadmin/chang...@ipa.test, Additional pre-authentication required
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down 
fd 12

Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: ISSUE: authtime 1466612968, 
etypes

{rep=18 tkt=18 ses=18}, tal...@ipa.test for kadmin/chang...@ipa.test
Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): closing down 
fd 12


"""

Here is the same command repeated with captured libkrb5 trace:
https://paste.fedoraproject.org/383358/14666131

If I use kinit with the canonical principal everything works as
expected, even with '-C' and '-'E' options. Subsequent kinits using
canonicalization work as expected.

Frankly I have no idea why this happens and I do not know how much this
error blocks us. We may need to investigate this before pizza orders 
arrive.


I guess the password changing code is making a request without
canonicalization flags set for the kpasswd service.
As you can see the kpasswd case is special because we are making an AS
REQ (not a TGS req) directly for that service, and that request needs to
use canonicalization as well, it probably isn't.

Simo.




Hello!

I've reviewed and tested the patches a year ago and now with current 
master again. The only issue I've found is the problem Martin is 
describing. User can not kinit with alias after password reset.
Since this is not regression I believe the patches can be pushed now. 
and the issue can be solved together with the rest of missing 
functionality. ACK!




pushed to master:
* e43231456d8de954423582dbee439e330573d04b perform case-insensitive 
principal search when canonicalization is requested
* 5f963e1ad18fdf52d0b41e143fd12f236b2a1ce7 mark 'ipaKrbPrincipalAlias' 
attribute as deprecated in schema
* 229ab40dd3d21346db8cd6dc65c03285f917271b add case-insensitive matching 
rule to krbprincipalname index
* 3f93f805571c1b791f0c378053ae8ecf37126e7f add krbCanonicalName to 
attributes watched by MODRDN plugin
* 7ed7a86511ec516c2f785968050f5d0a42978ba5 ipa-kdb: set krbCanonicalName 
when creating new principals
* b169a72735fccb170adb5c84ec1bcc10a70e5494 ipa-enrollment: set 
krbCanonicalName attribute on enrolled host entry
* 705f66f7490c64de1adc129221b31927616c485d IPA API: set krbcanonicalname 
instead of ipakrbprincipalalias on new entities
* 1bba2ed45df83684be1d50ef6e1ddb10f7a7d074 set krbcanonicalname on host 
entry during krbinstance configuration
* 06d945a04607dc36e25af78688b4295420489fb9 account for added 
krbcanonicalname attribute during xmlrpc tests


--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-06-23 Thread David Kupka

On 22/06/16 18:56, Simo Sorce wrote:

On Wed, 2016-06-22 at 18:36 +0200, Martin Babinsky wrote:

On 06/22/2016 06:26 PM, Simo Sorce wrote:

On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:

On 10/05/2015 03:00 PM, 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.





Long time no see.

I am attaching rebased infrastructure patches which were reviewed and
tested by David a year ago :). Now that all related DS bugs were fixed
and the patches still work as expected, we may push them so that the
plumbing for further work (API for alias handling etc.) is in place.



If the patches were all reviewed and tested I say push them.

Simo.



There is one problem remaining, however, that when a user is kinit'ing
for the first name using his alias and has to change password, the
operation fails:

"""
[root@master1 ~]# kinit -C talias
Password for tal...@ipa.test:
kinit: KDC reply did not match expectations while getting initial
credentials

"""

This is the related snippet from KDC log:

"""
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: CLIENT KEY EXPIRED:
tal...@ipa.test for krbtgt/ipa.t...@ipa.test, Password has expired
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: NEEDED_PREAUTH: tal...@ipa.test
for kadmin/chang...@ipa.test, Additional pre-authentication required
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.122.100: ISSUE: authtime 1466612968, etypes
{rep=18 tkt=18 ses=18}, tal...@ipa.test for kadmin/chang...@ipa.test
Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): closing down fd 12

"""

Here is the same command repeated with captured libkrb5 trace:
https://paste.fedoraproject.org/383358/14666131

If I use kinit with the canonical principal everything works as
expected, even with '-C' and '-'E' options. Subsequent kinits using
canonicalization work as expected.

Frankly I have no idea why this happens and I do not know how much this
error blocks us. We may need to investigate this before pizza orders arrive.


I guess the password changing code is making a request without
canonicalization flags set for the kpasswd service.
As you can see the kpasswd case is special because we are making an AS
REQ (not a TGS req) directly for that service, and that request needs to
use canonicalization as well, it probably isn't.

Simo.




Hello!

I've reviewed and tested the patches a year ago and now with current 
master again. The only issue I've found is the problem Martin is 
describing. User can not kinit with alias after password reset.
Since this is not regression I believe the patches can be pushed now. 
and the issue can be solved together with the rest of missing 
functionality. ACK!


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-06-22 Thread Simo Sorce
On Wed, 2016-06-22 at 18:36 +0200, Martin Babinsky wrote:
> On 06/22/2016 06:26 PM, Simo Sorce wrote:
> > On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:
> >> On 10/05/2015 03:00 PM, 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.
> >>>
> >>>
> >>>
> >>
> >> Long time no see.
> >>
> >> I am attaching rebased infrastructure patches which were reviewed and
> >> tested by David a year ago :). Now that all related DS bugs were fixed
> >> and the patches still work as expected, we may push them so that the
> >> plumbing for further work (API for alias handling etc.) is in place.
> >>
> >
> > If the patches were all reviewed and tested I say push them.
> >
> > Simo.
> >
> 
> There is one problem remaining, however, that when a user is kinit'ing 
> for the first name using his alias and has to change password, the 
> operation fails:
> 
> """
> [root@master1 ~]# kinit -C talias
> Password for tal...@ipa.test:
> kinit: KDC reply did not match expectations while getting initial 
> credentials
> 
> """
> 
> This is the related snippet from KDC log:
> 
> """
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: CLIENT KEY EXPIRED: 
> tal...@ipa.test for krbtgt/ipa.t...@ipa.test, Password has expired
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: NEEDED_PREAUTH: tal...@ipa.test 
> for kadmin/chang...@ipa.test, Additional pre-authentication required
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: ISSUE: authtime 1466612968, etypes 
> {rep=18 tkt=18 ses=18}, tal...@ipa.test for kadmin/chang...@ipa.test
> Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> 
> """
> 
> Here is the same command repeated with captured libkrb5 trace: 
> https://paste.fedoraproject.org/383358/14666131
> 
> If I use kinit with the canonical principal everything works as 
> expected, even with '-C' and '-'E' options. Subsequent kinits using 
> canonicalization work as expected.
> 
> Frankly I have no idea why this happens and I do not know how much this 
> error blocks us. We may need to investigate this before pizza orders arrive.

I guess the password changing code is making a request without
canonicalization flags set for the kpasswd service.
As you can see the kpasswd case is special because we are making an AS
REQ (not a TGS req) directly for that service, and that request needs to
use canonicalization as well, it probably isn't.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-06-22 Thread Martin Babinsky

On 06/22/2016 06:26 PM, Simo Sorce wrote:

On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:

On 10/05/2015 03:00 PM, 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.





Long time no see.

I am attaching rebased infrastructure patches which were reviewed and
tested by David a year ago :). Now that all related DS bugs were fixed
and the patches still work as expected, we may push them so that the
plumbing for further work (API for alias handling etc.) is in place.



If the patches were all reviewed and tested I say push them.

Simo.



There is one problem remaining, however, that when a user is kinit'ing 
for the first name using his alias and has to change password, the 
operation fails:


"""
[root@master1 ~]# kinit -C talias
Password for tal...@ipa.test:
kinit: KDC reply did not match expectations while getting initial 
credentials


"""

This is the related snippet from KDC log:

"""
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
{18 17 16 23 25 26}) 192.168.122.100: CLIENT KEY EXPIRED: 
tal...@ipa.test for krbtgt/ipa.t...@ipa.test, Password has expired

Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
{18 17 16 23 25 26}) 192.168.122.100: NEEDED_PREAUTH: tal...@ipa.test 
for kadmin/chang...@ipa.test, Additional pre-authentication required

Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
{18 17 16 23 25 26}) 192.168.122.100: ISSUE: authtime 1466612968, etypes 
{rep=18 tkt=18 ses=18}, tal...@ipa.test for kadmin/chang...@ipa.test

Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): closing down fd 12

"""

Here is the same command repeated with captured libkrb5 trace: 
https://paste.fedoraproject.org/383358/14666131


If I use kinit with the canonical principal everything works as 
expected, even with '-C' and '-'E' options. Subsequent kinits using 
canonicalization work as expected.


Frankly I have no idea why this happens and I do not know how much this 
error blocks us. We may need to investigate this before pizza orders arrive.


--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-06-22 Thread Simo Sorce
On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:
> On 10/05/2015 03:00 PM, 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.
> >
> >
> >
> 
> Long time no see.
> 
> I am attaching rebased infrastructure patches which were reviewed and 
> tested by David a year ago :). Now that all related DS bugs were fixed 
> and the patches still work as expected, we may push them so that the 
> plumbing for further work (API for alias handling etc.) is in place.
> 

If the patches were all reviewed and tested I say push them.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-06-22 Thread Martin Babinsky

On 10/05/2015 03:00 PM, 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.





Long time no see.

I am attaching rebased infrastructure patches which were reviewed and 
tested by David a year ago :). Now that all related DS bugs were fixed 
and the patches still work as expected, we may push them so that the 
plumbing for further work (API for alias handling etc.) is in place.


--
Martin^3 Babinsky
From 1e506e7aa72612f22aadca3894506e324b761596 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 8 Sep 2015 16:45:23 +0200
Subject: [PATCH 01/12] perform case-insensitive principal search when
 canonicalization is requested

When canonicalization is requested, the krbprincipalname attribute is searched
for case-insensitively.

In the case that krbcanonicalname is not set, the matched alias is returned
with the casing stored in backend, not the one input by client.

Part of https://fedorahosted.org/freeipa/ticket/3864
---
 daemons/ipa-kdb/ipa_kdb_principals.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index d4adf27f2de7c7ccd050063e779a30fdae35bc83..34807240213efb86fe8bb9fb7c0cc720bed31077 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -31,7 +31,7 @@
 "(objectclass=krbprincipal)" \
 "(objectclass=ipakrbprincipal))" \
 "(|(ipakrbprincipalalias=%s)" \
-  "(krbprincipalname=%s)))"
+  "(krbprincipalname:caseIgnoreIA5Match:=%s)))"
 
 #define PRINC_SEARCH_FILTER "(&(|(objectclass=krbprincipalaux)" \
 "(objectclass=krbprincipal))" \
@@ -959,6 +959,17 @@ static krb5_error_code ipadb_find_principal(krb5_context kcontext,
 NULL, NULL, ) != 0)
 return KRB5_KDB_INTERNAL_ERROR;
 found = (result == 0);
+if (found) {
+/* replace the incoming principal with the value having
+ * the correct case. This ensures that valid name/alias
+ * is returned even if krbCanonicalName is not present
+ */
+free(*principal);
+*principal = strdup(vals[i]->bv_val);
+if (!(*principal)) {
+return KRB5_KDB_INTERNAL_ERROR;
+}
+}
 } else {
 found = (strcmp(vals[i]->bv_val, (*principal)) == 0);
 }
-- 
2.5.5

From 5d0bb8247111cb31e1ca79099a6b614d13d9766b Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 8 Sep 2015 16:51:23 +0200
Subject: [PATCH 02/12] mark 'ipaKrbPrincipalAlias' attribute as deprecated in
 schema

part of https://fedorahosted.org/freeipa/ticket/3864
---
 install/share/61kerberos-ipav3.ldif | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/install/share/61kerberos-ipav3.ldif b/install/share/61kerberos-ipav3.ldif
index dcdaa5d08b66474ed0dec3db32682137bf56c0b8..c81ce51dfe5ffbdb60797d667c5960c7eef96ce7 100644
--- a/install/share/61kerberos-ipav3.ldif
+++ b/install/share/61kerberos-ipav3.ldif
@@ -1,3 +1,3 @@
 dn: cn=schema
-attributeTypes: (2.16.840.1.113730.3.8.11.32 NAME 'ipaKrbPrincipalAlias' DESC 'IPA principal alias' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3')
+attributeTypes: (2.16.840.1.113730.3.8.11.32 NAME 'ipaKrbPrincipalAlias' DESC 'DEPRECATED - DO NOT USE' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3')
 objectClasses: (2.16.840.1.113730.3.8.12.8 NAME 'ipaKrbPrincipal' SUP krbPrincipalAux AUXILIARY MUST ( krbPrincipalName $ ipaKrbPrincipalAlias ) X-ORIGIN 'IPA v3' )
-- 
2.5.5

From 2597fa5e013c4cf292c1cf33203199559dd9e939 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 8 Sep 2015 18:01:57 +0200
Subject: [PATCH 03/12] add case-insensitive matching rule to krbprincipalname
 index

Part of https://fedorahosted.org/freeipa/ticket/3864
---
 install/share/indices.ldif|  2 ++
 install/updates/20-indices.update | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/install/share/indices.ldif b/install/share/indices.ldif
index 

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

2015-10-08 Thread David Kupka

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=user198,cn=users,cn=accounts,dc=example,dc=test
uid: user198
givenName: Test
sn: User198
cn: Test User198
initials: TU
homeDirectory: /home/user198
gecos: Test User198
loginShell: /bin/sh
mail: user1000...@example.test
uidNumber: 761100198
gidNumber: 761100198
displayName: Test User198
*krbPrincipalName: user1000...@example.test*
*krbCanonicalName: user1000...@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
  

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

2015-10-08 Thread thierry bordaz

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=user198,cn=users,cn=accounts,dc=example,dc=test
uid: user198
givenName: Test
sn: User198
cn: Test User198
initials: TU
homeDirectory: /home/user198
gecos: Test User198
loginShell: /bin/sh
mail: user1000...@example.test
uidNumber: 761100198
gidNumber: 761100198
displayName: Test User198
*krbPrincipalName: user1000...@example.test*
*krbCanonicalName: user1000...@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

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

2015-10-07 Thread David Kupka

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.


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-07 Thread thierry bordaz

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=user198,cn=users,cn=accounts,dc=example,dc=test
uid: user198
givenName: Test
sn: User198
cn: Test User198
initials: TU
homeDirectory: /home/user198
gecos: Test User198
loginShell: /bin/sh
mail: user1000...@example.test
uidNumber: 761100198
gidNumber: 761100198
displayName: Test User198
*krbPrincipalName: user1000...@example.test*
*krbCanonicalName: user1000...@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

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

2015-10-07 Thread thierry bordaz

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=user198,cn=users,cn=accounts,dc=example,dc=test
   uid: user198
   givenName: Test
   sn: User198
   cn: Test User198
   initials: TU
   homeDirectory: /home/user198
   gecos: Test User198
   loginShell: /bin/sh
   mail: user1000...@example.test
   uidNumber: 761100198
   gidNumber: 761100198
   displayName: Test User198
   *krbPrincipalName: user1000...@example.test*
   *krbCanonicalName: user1000...@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: 

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

2015-10-07 Thread Simo Sorce

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=user198,cn=users,cn=accounts,dc=example,dc=test
uid: user198
givenName: Test
sn: User198
cn: Test User198
initials: TU
homeDirectory: /home/user198
gecos: Test User198
loginShell: /bin/sh
mail: user1000...@example.test
uidNumber: 761100198
gidNumber: 761100198
displayName: Test User198
*krbPrincipalName: user1000...@example.test*
*krbCanonicalName: user1000...@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
 

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

2015-10-06 Thread Jakub Hrozek
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.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-06 Thread thierry bordaz

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)

thanks
thierry
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

2015-10-06 Thread Simo Sorce

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.

--
Simo Sorce * Red Hat, Inc * New York

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-06 Thread David Kupka

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.


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-06 Thread Simo Sorce

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).


Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-05 Thread David Kupka

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.


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2015-10-05 Thread Simo Sorce

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.


--
Simo Sorce * Red Hat, Inc * New York

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code