Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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
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
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
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
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
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, &result) != 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 4ea4a876ded5fdf3972924d8a86e4fec3ae5ed92..642c2f7aee78b684b3e451c259
Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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 objectCl
Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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
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 ip
Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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
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: cn=user19
Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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
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
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
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
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
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
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
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
[Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization
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.
--
Martin^3 Babinsky
From 4832fa024a3083f6cce3c151ab29ae99a696fcf1 Mon Sep 17 00:00:00 2001
From: Martin Babinsky
Date: Fri, 2 Oct 2015 18:05:03 +0200
Subject: [PATCH 09/09] account for added krbcanonicalname attribute during
xmlrpc tests
https://fedorahosted.org/freeipa/ticket/3864
---
ipatests/test_xmlrpc/objectclasses.py | 1 -
ipatests/test_xmlrpc/test_host_plugin.py | 4 +++-
ipatests/test_xmlrpc/test_service_plugin.py | 4 ++--
ipatests/test_xmlrpc/test_stageuser_plugin.py | 5 -
ipatests/test_xmlrpc/test_user_plugin.py | 7 +--
5 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/ipatests/test_xmlrpc/objectclasses.py b/ipatests/test_xmlrpc/objectclasses.py
index 1cd77c7f885fe408d0d9d48fc6d8284900c91b7f..206cb3689a97623f5144686b23a9a3f56c113560 100644
--- a/ipatests/test_xmlrpc/objectclasses.py
+++ b/ipatests/test_xmlrpc/objectclasses.py
@@ -100,7 +100,6 @@ service = [
u'ipaobject',
u'ipaservice',
u'pkiuser',
-u'ipakrbprincipal',
u'top',
]
diff --git a/ipatests/test_xmlrpc/test_host_plugin.py b/ipatests/test_xmlrpc/test_host_plugin.py
index bba86492e98d098d4c0bbd42de58e96b9b570e1d..efd9403f0028a7ae45261cabcb4f490b94d7db66 100644
--- a/ipatests/test_xmlrpc/test_host_plugin.py
+++ b/ipatests/test_xmlrpc/test_host_plugin.py
@@ -122,7 +122,8 @@ class HostTracker(Tracker):
'ipaallowedtoperform_write_keys_hostgroup'}
retrieve_all_keys = retrieve_keys | {
u'cn', u'ipakrbokasdelegate', u'ipakrbrequirespreauth', u'ipauniqueid',
-u'managing_host', u'objectclass', u'serverhostname'}
+u'managing_host', u'objectclass', u'serverhostname',
+u'krbcanonicalname'}
create_keys = retrieve_keys | {'objectclass', 'ipauniqueid',
'randompassword'}
update_keys = retrieve_keys - {'dn'}
@@ -178,6 +179,7 @@ class HostTracker(Tracker):
description=[self.description],
l=[self.location],
krbprincipalname=[u'host/%s@%s' % (self.fqdn, self.api.env.realm)],
+krbcanonicalname=[u'host/%s@%s' % (self.fqdn, self.api.env.realm)],
objectclass=objectclasses.host,
ipauniqueid=[fuzzy_uuid],
managedby_host=[self.fqdn],
diff --git a/ipatests/test_xmlrpc/test_service_plugin.py b/ipatests/test_xmlrpc/test_service_plugin.py
index 78ba60a691a625d3fdce2ea0df0f2aef9ef3caac..6c399ed62b9ec52000ab155fbcd5a387c6135fc2 100644
--- a/ipatests/test_xmlrpc/test_service_plugin.py
+++ b/ipatests/test_xmlrpc/test_service_plugin.py
@@ -236,7 +236,7 @@ class test_service(Declarative):
result=dict(
dn=service1dn,
krbprincipalname=[service1],
-ipakrbprincipalalias=[service1],
+krbcanonicalname=[service1],
objectclass=objectclasses.service,
ipauniqueid=[fuzzy_uuid],
managedby_host=[fqdn1],
@@ -278,7 +278,7 @@ class test_service(Declarative):
dict(
dn=service1dn,
krbprincipalname=[service1],
-ipakrbprincipalalias=[service1],
+krbcanonicalname=[service1],
objectclass=objectclasses.service,
ipauniqueid=[fuzzy_uuid],
has_keytab=False,
diff --git a/ipatests/test_xmlrpc/test_stageuser_plugin.py b/ipatests/test_xmlrpc/test_stageuser_plugin.py
index b09ef6e84cd95a32061b07d833c5a39f1750f80b..d19bbdf450085b55a02b68ac5ebbb091ae7dc227 100644
--- a/ipatests/test_xmlrpc/test_stageuser_plugin.py
+++ b/ipatests/test_xmlrpc/test_stageuser_plugin.py
@@ -103,7 +103,8 @@ class StageUserTracker(Tracker):
u'st', u'mobile', u'pager', }
retrieve_all_keys = retrieve_keys | {
u'cn', u'ipauniqueid', u'objectclass', u'description',
-u'displayname', u'gecos', u'initials', u'krbprincipalname', u'manager'}
+u'displayname', u'gecos', u'initials', u'krbprincipalname',
+u'krbcanonicalname', u'manager'}
create_keys = retrieve_all_keys | {
u'objectclass', u'ipauniqueid', u'randompassword',
@@ -170,6 +171,7 @@ class StageUserTracker(Tracker):
uidnumber=[u'-1'],
gidnumber=[u'-1'],
krbprincipalname=[u'%s@%s' % (self.uid, self.api.env.realm)],
+krbcanonicalname=[u'%s@%s' % (self.uid, self.api.env.realm)],
mail=[u'%s@%s' % (self.uid, self.api.env.domain)],
gecos=[u'%s %s' % (se
