Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On 09/07/2015 09:47 PM, Simo Sorce wrote: On Mon, 2015-09-07 at 09:20 +0200, David Kupka wrote: On 04/09/15 12:49, thierry bordaz wrote: On 09/03/2015 04:03 PM, David Kupka wrote: On 02/09/15 14:27, Simo Sorce wrote: On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: On 01/09/15 16:53, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 1 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. We will add index for caseIgnoreCaseIA5Match matching rule on krbPrincipalName and then the case insensitive match should be as quick as the case sensitive. Without the index it is indeed far slower. I've generated 10k users and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the nonindexed one ~2 minutes. That's by two orders of magnitude worse. When we tried to add the index into DS we uncovered a bug in the way DS handles nsMatchingRule attributes. Thierry investigated it and is filling the ticket for DS right now. Thierry can you please send link? The ticket is https://fedorahosted.org/389/ticket/48270. I think understand where the problem is but I have no fix yet. David, when you said the unindexed search was slow, did you index 'krbPrincipalName' but added a matching rule to your filter ? I would like to also verify the fix against that perf hit. thanks thierry I've tried these 3 searches: 1) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseIgnoreIA5Match:=user1005...@example.com)" 2) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseExactIA5Match:=user1005...@example.com)"' 3) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname=user1005...@example.com)" The first two was slow and only the last one was quick. Sounds like DS do a full search instead of indexed searches when you specify a matching rule ? We should either make sure DS can use indexed searches in this case or go with the plan I proposed earlier. Simo. Yes that is correct, those searches with matching rule are unindexed. I think the reason is #48270 that reject the
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On 04/09/15 12:49, thierry bordaz wrote: On 09/03/2015 04:03 PM, David Kupka wrote: On 02/09/15 14:27, Simo Sorce wrote: On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: On 01/09/15 16:53, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 1 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. We will add index for caseIgnoreCaseIA5Match matching rule on krbPrincipalName and then the case insensitive match should be as quick as the case sensitive. Without the index it is indeed far slower. I've generated 10k users and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the nonindexed one ~2 minutes. That's by two orders of magnitude worse. When we tried to add the index into DS we uncovered a bug in the way DS handles nsMatchingRule attributes. Thierry investigated it and is filling the ticket for DS right now. Thierry can you please send link? The ticket is https://fedorahosted.org/389/ticket/48270. I think understand where the problem is but I have no fix yet. David, when you said the unindexed search was slow, did you index 'krbPrincipalName' but added a matching rule to your filter ? I would like to also verify the fix against that perf hit. thanks thierry I've tried these 3 searches: 1) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseIgnoreIA5Match:=user1005...@example.com)" 2) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseExactIA5Match:=user1005...@example.com)"' 3) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname=user1005...@example.com)" The first two was slow and only the last one was quick. Once it's fixed we should be good. David This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On Mon, 2015-09-07 at 09:20 +0200, David Kupka wrote: > On 04/09/15 12:49, thierry bordaz wrote: > > On 09/03/2015 04:03 PM, David Kupka wrote: > >> On 02/09/15 14:27, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > On 01/09/15 16:53, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket > >> https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make > >> IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), > >> so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this > >> stuff > >> wrong. If that's the case please point me to the right direction. > >> Also > >> please write me some additional stuff which I have fogot and needs > >> to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be > > careful is > > to keep handling entries that have only a single valued > > krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can > > solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" > > case > > there anyway so out mucking with the krbPrincipalName case will not > > be a > > problem for any new entry. > > Or as Honza pointed out we can use case-insensitive search like this: > (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return > all variants of casing and reduce the need for fallback code. > >>> > >>> The principal name is not case insensitive, a search like that would > >>> probably cause DS to do a full search through the krbPrincipalName > >>> index, it might quickly become a performance issue. Before choosing a > >>> method please create an install with a 1 principals, and then > >>> compare the speed of a few thousand search with exact matching case and > >>> a few with specifying caseIgnoreMatch and see the difference. > >>> > >>> Simo. > >> > >> We will add index for caseIgnoreCaseIA5Match matching rule on > >> krbPrincipalName and then the case insensitive match should be as > >> quick as the case sensitive. > >> > >> Without the index it is indeed far slower. I've generated 10k users > >> and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and > >> the nonindexed one ~2 minutes. That's by two orders of magnitude worse. > >> > >> When we tried to add the index into DS we uncovered a bug in the way > >> DS handles nsMatchingRule attributes. Thierry investigated it and is > >> filling the ticket for DS right now. Thierry can you please send link? > > > > The ticket is https://fedorahosted.org/389/ticket/48270. > > I think understand where the problem is but I have no fix yet. > > David, when you said the unindexed search was slow, did you index > > 'krbPrincipalName' but added a matching rule to your filter ? > > I would like to also verify the fix against that perf hit. > > > > thanks > > thierry > > I've tried these 3 searches: > > 1) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname:caseIgnoreIA5Match:=user1005...@example.com)" > > 2) ldapsearch -h localhost -D
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On 09/03/2015 04:03 PM, David Kupka wrote: On 02/09/15 14:27, Simo Sorce wrote: On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: On 01/09/15 16:53, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 1 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. We will add index for caseIgnoreCaseIA5Match matching rule on krbPrincipalName and then the case insensitive match should be as quick as the case sensitive. Without the index it is indeed far slower. I've generated 10k users and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the nonindexed one ~2 minutes. That's by two orders of magnitude worse. When we tried to add the index into DS we uncovered a bug in the way DS handles nsMatchingRule attributes. Thierry investigated it and is filling the ticket for DS right now. Thierry can you please send link? The ticket is https://fedorahosted.org/389/ticket/48270. I think understand where the problem is but I have no fix yet. David, when you said the unindexed search was slow, did you index 'krbPrincipalName' but added a matching rule to your filter ? I would like to also verify the fix against that perf hit. thanks thierry Once it's fixed we should be good. David This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. -- 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] fixing Kerberos principal aliases handling in IPA
On Thu, 2015-09-03 at 16:03 +0200, David Kupka wrote: > On 02/09/15 14:27, Simo Sorce wrote: > > On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > >> On 01/09/15 16:53, Simo Sorce wrote: > >>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > Hi list, > > I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > and I would like to clarify what needs to be done in order to make IPA > to fully support multiple aliases per entry. > > So far I have identified these task based on the ticket comments and > discussion with Simo way back in the past: > > 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > not used in the new code. > > 2.) fix ACIs that do not permit setting multiple values of > 'krbPrincipalName' attribute per entry (see > https://fedorahosted.org/freeipa/ticket/3961) > > 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > 'ipadb_find_principal' functions) to correctly perform lookup of > krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > case-insensitively and krbcanonicalname case-sensitively, return > krbcanonicalname when canonicalization is requested. > > 4.) Modify KDB backend and IPA framework to handle creation of both > krbprincipalname and krbcanonicalname. I am not quite sure what cases > should be covered here (I remember that we should create > krbcanonicalname when we add another aliases to krbprincipalname), so it > would be nice if you could comment on this. > > 5.) write tests which cover all this stuff so that we don't shoot > ourselves in the foot. > > I am not very well versed in Kerberos so I might get some of this stuff > wrong. If that's the case please point me to the right direction. Also > please write me some additional stuff which I have fogot and needs to be > done. > > >>> > >>> I think the summary is correct, the only thing we need to be careful is > >>> to keep handling entries that have only a single valued krbprincipalname > >>> correctly as that will happen in upgrade paths and potentially if > >>> someone uses external tools. > >>> > >>> The tricky part for point 3 is to implement it *without* changing the > >>> schema. KrbPrincipalName is case-sensitive, however I think we can solve > >>> the issue of "searching case-insensitively" by always lower-casing the > >>> principal name components and always upper casing the realm part on > >>> storage. If we always store a krbCanonicalName we get the "correct" case > >>> there anyway so out mucking with the krbPrincipalName case will not be a > >>> problem for any new entry. > >> > >> Or as Honza pointed out we can use case-insensitive search like this: > >> (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return > >> all variants of casing and reduce the need for fallback code. > > > > The principal name is not case insensitive, a search like that would > > probably cause DS to do a full search through the krbPrincipalName > > index, it might quickly become a performance issue. Before choosing a > > method please create an install with a 1 principals, and then > > compare the speed of a few thousand search with exact matching case and > > a few with specifying caseIgnoreMatch and see the difference. > > > > Simo. > > We will add index for caseIgnoreCaseIA5Match matching rule on > krbPrincipalName and then the case insensitive match should be as quick > as the case sensitive. > > Without the index it is indeed far slower. I've generated 10k users and > compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the > nonindexed one ~2 minutes. That's by two orders of magnitude worse. > > When we tried to add the index into DS we uncovered a bug in the way DS > handles nsMatchingRule attributes. Thierry investigated it and is > filling the ticket for DS right now. Thierry can you please send link? > > Once it's fixed we should be good. > > David > > > > >>> This *may* cause issues with upgrades though, so we may need fallback > >>> code that searches with the case sent by the client if we determine the > >>> entry has no krbCanonicalName attribute (sign that it was created before > >>> we started adding krbCanonicalName and never "updated"). Another "upgrade" issue came to mind. Will the referential integrity plugin properly handle a rename of service entries should they be referenced in some object ? Simo. > >>> Note that we also need to think what will happen during and upgrade when > >>> some servers still use the current code and some servers will use the > >>> new code. So I guess it would be nice if you could write down a table > >>> with all possible forms a principal can be in on rows, and old/new > >>> server states in columns, and mark what will happen for various > >>> operations in each case. > >>> > >>> Simo. >
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On 02/09/15 14:27, Simo Sorce wrote: On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: On 01/09/15 16:53, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 1 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. We will add index for caseIgnoreCaseIA5Match matching rule on krbPrincipalName and then the case insensitive match should be as quick as the case sensitive. Without the index it is indeed far slower. I've generated 10k users and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the nonindexed one ~2 minutes. That's by two orders of magnitude worse. When we tried to add the index into DS we uncovered a bug in the way DS handles nsMatchingRule attributes. Thierry investigated it and is filling the ticket for DS right now. Thierry can you please send link? Once it's fixed we should be good. David This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. -- 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] fixing Kerberos principal aliases handling in IPA
On 01/09/15 16:53, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all variants of casing and reduce the need for fallback code. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. -- 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] fixing Kerberos principal aliases handling in IPA
On 2.9.2015 08:11, David Kupka wrote: > On 01/09/15 16:53, Simo Sorce wrote: >> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>> Hi list, >>> >>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>> and I would like to clarify what needs to be done in order to make IPA >>> to fully support multiple aliases per entry. >>> >>> So far I have identified these task based on the ticket comments and >>> discussion with Simo way back in the past: >>> >>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>> not used in the new code. >>> >>> 2.) fix ACIs that do not permit setting multiple values of >>> 'krbPrincipalName' attribute per entry (see >>> https://fedorahosted.org/freeipa/ticket/3961) >>> >>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>> 'ipadb_find_principal' functions) to correctly perform lookup of >>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>> case-insensitively and krbcanonicalname case-sensitively, return >>> krbcanonicalname when canonicalization is requested. >>> >>> 4.) Modify KDB backend and IPA framework to handle creation of both >>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>> should be covered here (I remember that we should create >>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>> would be nice if you could comment on this. >>> >>> 5.) write tests which cover all this stuff so that we don't shoot >>> ourselves in the foot. >>> >>> I am not very well versed in Kerberos so I might get some of this stuff >>> wrong. If that's the case please point me to the right direction. Also >>> please write me some additional stuff which I have fogot and needs to be >>> done. >>> >> >> I think the summary is correct, the only thing we need to be careful is >> to keep handling entries that have only a single valued krbprincipalname >> correctly as that will happen in upgrade paths and potentially if >> someone uses external tools. >> >> The tricky part for point 3 is to implement it *without* changing the >> schema. KrbPrincipalName is case-sensitive, however I think we can solve >> the issue of "searching case-insensitively" by always lower-casing the >> principal name components and always upper casing the realm part on >> storage. If we always store a krbCanonicalName we get the "correct" case >> there anyway so out mucking with the krbPrincipalName case will not be a >> problem for any new entry. > > Or as Honza pointed out we can use case-insensitive search like this: > (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return all > variants of casing and reduce the need for fallback code. +1, I was going to propose the very same thing. This is a standard LDAP thing, see http://tools.ietf.org/search/rfc4515#section-4 . Just keep in mind that we may need to add index for caseIgnoreMatch. Petr^2 Spacek >> This *may* cause issues with upgrades though, so we may need fallback >> code that searches with the case sent by the client if we determine the >> entry has no krbCanonicalName attribute (sign that it was created before >> we started adding krbCanonicalName and never "updated"). >> >> Note that we also need to think what will happen during and upgrade when >> some servers still use the current code and some servers will use the >> new code. So I guess it would be nice if you could write down a table >> with all possible forms a principal can be in on rows, and old/new >> server states in columns, and mark what will happen for various >> operations in each case. >> >> Simo. -- 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] fixing Kerberos principal aliases handling in IPA
On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > > >> Hi list, > > >> > > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > > >> and I would like to clarify what needs to be done in order to make IPA > > >> to fully support multiple aliases per entry. > > >> > > >> So far I have identified these task based on the ticket comments and > > >> discussion with Simo way back in the past: > > >> > > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > > >> not used in the new code. > > >> > > >> 2.) fix ACIs that do not permit setting multiple values of > > >> 'krbPrincipalName' attribute per entry (see > > >> https://fedorahosted.org/freeipa/ticket/3961) > > >> > > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > > >> 'ipadb_find_principal' functions) to correctly perform lookup of > > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > > >> case-insensitively and krbcanonicalname case-sensitively, return > > >> krbcanonicalname when canonicalization is requested. > > >> > > >> 4.) Modify KDB backend and IPA framework to handle creation of both > > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > > >> should be covered here (I remember that we should create > > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > > >> would be nice if you could comment on this. > > >> > > >> 5.) write tests which cover all this stuff so that we don't shoot > > >> ourselves in the foot. > > >> > > >> I am not very well versed in Kerberos so I might get some of this stuff > > >> wrong. If that's the case please point me to the right direction. Also > > >> please write me some additional stuff which I have fogot and needs to be > > >> done. > > >> > > > > > > I think the summary is correct, the only thing we need to be careful is > > > to keep handling entries that have only a single valued krbprincipalname > > > correctly as that will happen in upgrade paths and potentially if > > > someone uses external tools. > > > > > > The tricky part for point 3 is to implement it *without* changing the > > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > > the issue of "searching case-insensitively" by always lower-casing the > > > principal name components and always upper casing the realm part on > > > storage. If we always store a krbCanonicalName we get the "correct" case > > > there anyway so out mucking with the krbPrincipalName case will not be a > > > problem for any new entry. > > > > > > This *may* cause issues with upgrades though, so we may need fallback > > > code that searches with the case sent by the client if we determine the > > > entry has no krbCanonicalName attribute (sign that it was created before > > > we started adding krbCanonicalName and never "updated"). > > > > > > Note that we also need to think what will happen during and upgrade when > > > some servers still use the current code and some servers will use the > > > new code. So I guess it would be nice if you could write down a table > > > with all possible forms a principal can be in on rows, and old/new > > > server states in columns, and mark what will happen for various > > > operations in each case. > > > > > > Simo. > > > > The list looks OK. Do we also plan to change the default RDN for new > > services > > or other objects that use krbPrincipalName as RDN at the moment? > > > > AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > > then only allow krbPrincipalName to be added for the aliases. Of course, the > > framework needs to still work with old services having krbPrincipalName. > > no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName > is only optional according to the scheme. We might stropping using either and use CN instead for the RDN. 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] fixing Kerberos principal aliases handling in IPA
On 09/02/2015 02:32 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: >> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: >>> On 09/01/2015 04:53 PM, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > Hi list, > > I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > and I would like to clarify what needs to be done in order to make IPA > to fully support multiple aliases per entry. > > So far I have identified these task based on the ticket comments and > discussion with Simo way back in the past: > > 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > not used in the new code. > > 2.) fix ACIs that do not permit setting multiple values of > 'krbPrincipalName' attribute per entry (see > https://fedorahosted.org/freeipa/ticket/3961) > > 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > 'ipadb_find_principal' functions) to correctly perform lookup of > krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > case-insensitively and krbcanonicalname case-sensitively, return > krbcanonicalname when canonicalization is requested. > > 4.) Modify KDB backend and IPA framework to handle creation of both > krbprincipalname and krbcanonicalname. I am not quite sure what cases > should be covered here (I remember that we should create > krbcanonicalname when we add another aliases to krbprincipalname), so it > would be nice if you could comment on this. > > 5.) write tests which cover all this stuff so that we don't shoot > ourselves in the foot. > > I am not very well versed in Kerberos so I might get some of this stuff > wrong. If that's the case please point me to the right direction. Also > please write me some additional stuff which I have fogot and needs to be > done. > I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. >>> >>> The list looks OK. Do we also plan to change the default RDN for new >>> services >>> or other objects that use krbPrincipalName as RDN at the moment? >>> >>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and >>> then only allow krbPrincipalName to be added for the aliases. Of course, the >>> framework needs to still work with old services having krbPrincipalName. >> >> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName >> is only optional according to the scheme. > > We might stropping using either and use CN instead for the RDN. This would make changing krbPrincipalName that happens to be RDN much easier. Wouldn't this break software that depends on this RDN already? Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? Martin -- 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] fixing Kerberos principal aliases handling in IPA
On 09/01/2015 04:53 PM, Simo Sorce wrote: > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >> Hi list, >> >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >> and I would like to clarify what needs to be done in order to make IPA >> to fully support multiple aliases per entry. >> >> So far I have identified these task based on the ticket comments and >> discussion with Simo way back in the past: >> >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >> not used in the new code. >> >> 2.) fix ACIs that do not permit setting multiple values of >> 'krbPrincipalName' attribute per entry (see >> https://fedorahosted.org/freeipa/ticket/3961) >> >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >> 'ipadb_find_principal' functions) to correctly perform lookup of >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >> case-insensitively and krbcanonicalname case-sensitively, return >> krbcanonicalname when canonicalization is requested. >> >> 4.) Modify KDB backend and IPA framework to handle creation of both >> krbprincipalname and krbcanonicalname. I am not quite sure what cases >> should be covered here (I remember that we should create >> krbcanonicalname when we add another aliases to krbprincipalname), so it >> would be nice if you could comment on this. >> >> 5.) write tests which cover all this stuff so that we don't shoot >> ourselves in the foot. >> >> I am not very well versed in Kerberos so I might get some of this stuff >> wrong. If that's the case please point me to the right direction. Also >> please write me some additional stuff which I have fogot and needs to be >> done. >> > > I think the summary is correct, the only thing we need to be careful is > to keep handling entries that have only a single valued krbprincipalname > correctly as that will happen in upgrade paths and potentially if > someone uses external tools. > > The tricky part for point 3 is to implement it *without* changing the > schema. KrbPrincipalName is case-sensitive, however I think we can solve > the issue of "searching case-insensitively" by always lower-casing the > principal name components and always upper casing the realm part on > storage. If we always store a krbCanonicalName we get the "correct" case > there anyway so out mucking with the krbPrincipalName case will not be a > problem for any new entry. > > This *may* cause issues with upgrades though, so we may need fallback > code that searches with the case sent by the client if we determine the > entry has no krbCanonicalName attribute (sign that it was created before > we started adding krbCanonicalName and never "updated"). > > Note that we also need to think what will happen during and upgrade when > some servers still use the current code and some servers will use the > new code. So I guess it would be nice if you could write down a table > with all possible forms a principal can be in on rows, and old/new > server states in columns, and mark what will happen for various > operations in each case. > > Simo. The list looks OK. Do we also plan to change the default RDN for new services or other objects that use krbPrincipalName as RDN at the moment? AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and then only allow krbPrincipalName to be added for the aliases. Of course, the framework needs to still work with old services having krbPrincipalName. -- 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] fixing Kerberos principal aliases handling in IPA
On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > > Simo. > > The list looks OK. Do we also plan to change the default RDN for new services > or other objects that use krbPrincipalName as RDN at the moment? > > AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > then only allow krbPrincipalName to be added for the aliases. Of course, the > framework needs to still work with old services having krbPrincipalName. no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName is only optional according to the scheme. bye, Sumit > > -- > 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 -- 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] fixing Kerberos principal aliases handling in IPA
On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > On 01/09/15 16:53, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > Or as Honza pointed out we can use case-insensitive search like this: > (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return > all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 1 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > > 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] fixing Kerberos principal aliases handling in IPA
On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: > On 09/02/2015 02:32 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > >> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > >>> On 09/01/2015 04:53 PM, Simo Sorce wrote: > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > > Hi list, > > > > I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > > and I would like to clarify what needs to be done in order to make IPA > > to fully support multiple aliases per entry. > > > > So far I have identified these task based on the ticket comments and > > discussion with Simo way back in the past: > > > > 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > > not used in the new code. > > > > 2.) fix ACIs that do not permit setting multiple values of > > 'krbPrincipalName' attribute per entry (see > > https://fedorahosted.org/freeipa/ticket/3961) > > > > 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > > 'ipadb_find_principal' functions) to correctly perform lookup of > > krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > > case-insensitively and krbcanonicalname case-sensitively, return > > krbcanonicalname when canonicalization is requested. > > > > 4.) Modify KDB backend and IPA framework to handle creation of both > > krbprincipalname and krbcanonicalname. I am not quite sure what cases > > should be covered here (I remember that we should create > > krbcanonicalname when we add another aliases to krbprincipalname), so > > it > > would be nice if you could comment on this. > > > > 5.) write tests which cover all this stuff so that we don't shoot > > ourselves in the foot. > > > > I am not very well versed in Kerberos so I might get some of this stuff > > wrong. If that's the case please point me to the right direction. Also > > please write me some additional stuff which I have fogot and needs to > > be > > done. > > > > I think the summary is correct, the only thing we need to be careful is > to keep handling entries that have only a single valued krbprincipalname > correctly as that will happen in upgrade paths and potentially if > someone uses external tools. > > The tricky part for point 3 is to implement it *without* changing the > schema. KrbPrincipalName is case-sensitive, however I think we can solve > the issue of "searching case-insensitively" by always lower-casing the > principal name components and always upper casing the realm part on > storage. If we always store a krbCanonicalName we get the "correct" case > there anyway so out mucking with the krbPrincipalName case will not be a > problem for any new entry. > > This *may* cause issues with upgrades though, so we may need fallback > code that searches with the case sent by the client if we determine the > entry has no krbCanonicalName attribute (sign that it was created before > we started adding krbCanonicalName and never "updated"). > > Note that we also need to think what will happen during and upgrade when > some servers still use the current code and some servers will use the > new code. So I guess it would be nice if you could write down a table > with all possible forms a principal can be in on rows, and old/new > server states in columns, and mark what will happen for various > operations in each case. > > Simo. > >>> > >>> The list looks OK. Do we also plan to change the default RDN for new > >>> services > >>> or other objects that use krbPrincipalName as RDN at the moment? > >>> > >>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN > >>> and > >>> then only allow krbPrincipalName to be added for the aliases. Of course, > >>> the > >>> framework needs to still work with old services having krbPrincipalName. > >> > >> no, I think we can/should keep krbPrincipalName e.g. becasue > >> krbCanonicalName > >> is only optional according to the scheme. > > > > We might stropping using either and use CN instead for the RDN. > > This would make changing krbPrincipalName that happens to be RDN much easier. > Wouldn't this break software that depends on this RDN already? > > Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? It would,. but so would a change to krbCanonicalName. If you need to change something we might as well go CN. Otherwise keep it as is, but I guess your worry is that the RDN becomes multivalued which is really a pain. 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] fixing Kerberos principal aliases handling in IPA
On 09/02/2015 02:38 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: >> On 09/02/2015 02:32 PM, Simo Sorce wrote: >>> On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > On 09/01/2015 04:53 PM, Simo Sorce wrote: >> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>> Hi list, >>> >>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>> and I would like to clarify what needs to be done in order to make IPA >>> to fully support multiple aliases per entry. >>> >>> So far I have identified these task based on the ticket comments and >>> discussion with Simo way back in the past: >>> >>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>> not used in the new code. >>> >>> 2.) fix ACIs that do not permit setting multiple values of >>> 'krbPrincipalName' attribute per entry (see >>> https://fedorahosted.org/freeipa/ticket/3961) >>> >>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>> 'ipadb_find_principal' functions) to correctly perform lookup of >>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>> case-insensitively and krbcanonicalname case-sensitively, return >>> krbcanonicalname when canonicalization is requested. >>> >>> 4.) Modify KDB backend and IPA framework to handle creation of both >>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>> should be covered here (I remember that we should create >>> krbcanonicalname when we add another aliases to krbprincipalname), so >>> it >>> would be nice if you could comment on this. >>> >>> 5.) write tests which cover all this stuff so that we don't shoot >>> ourselves in the foot. >>> >>> I am not very well versed in Kerberos so I might get some of this stuff >>> wrong. If that's the case please point me to the right direction. Also >>> please write me some additional stuff which I have fogot and needs to >>> be >>> done. >>> >> >> I think the summary is correct, the only thing we need to be careful is >> to keep handling entries that have only a single valued krbprincipalname >> correctly as that will happen in upgrade paths and potentially if >> someone uses external tools. >> >> The tricky part for point 3 is to implement it *without* changing the >> schema. KrbPrincipalName is case-sensitive, however I think we can solve >> the issue of "searching case-insensitively" by always lower-casing the >> principal name components and always upper casing the realm part on >> storage. If we always store a krbCanonicalName we get the "correct" case >> there anyway so out mucking with the krbPrincipalName case will not be a >> problem for any new entry. >> >> This *may* cause issues with upgrades though, so we may need fallback >> code that searches with the case sent by the client if we determine the >> entry has no krbCanonicalName attribute (sign that it was created before >> we started adding krbCanonicalName and never "updated"). >> >> Note that we also need to think what will happen during and upgrade when >> some servers still use the current code and some servers will use the >> new code. So I guess it would be nice if you could write down a table >> with all possible forms a principal can be in on rows, and old/new >> server states in columns, and mark what will happen for various >> operations in each case. >> >> Simo. > > The list looks OK. Do we also plan to change the default RDN for new > services > or other objects that use krbPrincipalName as RDN at the moment? > > AFAIU, we are supposed to always use krbCanonicalName as the primary RDN > and > then only allow krbPrincipalName to be added for the aliases. Of course, > the > framework needs to still work with old services having krbPrincipalName. no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName is only optional according to the scheme. >>> >>> We might stropping using either and use CN instead for the RDN. >> >> This would make changing krbPrincipalName that happens to be RDN much easier. >> Wouldn't this break software that depends on this RDN already? >> >> Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? > > It would,. but so would a change to krbCanonicalName. If you need to > change something we might as well go CN. Otherwise keep it as is, but I > guess your worry is that the RDN becomes multivalued which is really a > pain. Yes, this is the worry. I think we want to avoid issues with having to rename the whole object just because we are changing the alias. Using krbCanonicalName as default RDN always and then
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On 02/09/15 14:19, Sumit Bose wrote: On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: On 09/01/2015 04:53 PM, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. The list looks OK. Do we also plan to change the default RDN for new services or other objects that use krbPrincipalName as RDN at the moment? AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and then only allow krbPrincipalName to be added for the aliases. Of course, the framework needs to still work with old services having krbPrincipalName. no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName is only optional according to the scheme. That's right. We should keep krbprincipalname as RDN as it must be there anyway. We just need to set krbprincipalname and krbcanonicalname to the same value at entry creation and use this value in RDN. Also we won't allow removing krbprincipalname with the same value as krbcanonicalname. This allows us to maintain backwards compatibility with no additional effort. David bye, Sumit -- 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 -- 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] fixing Kerberos principal aliases handling in IPA
On Wed, 2015-09-02 at 14:44 +0200, Martin Kosek wrote: > On 09/02/2015 02:38 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: > >> On 09/02/2015 02:32 PM, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > > On 09/01/2015 04:53 PM, Simo Sorce wrote: > >> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >>> Hi list, > >>> > >>> I own the following ticket > >>> https://fedorahosted.org/freeipa/ticket/3864 > >>> and I would like to clarify what needs to be done in order to make > >>> IPA > >>> to fully support multiple aliases per entry. > >>> > >>> So far I have identified these task based on the ticket comments and > >>> discussion with Simo way back in the past: > >>> > >>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >>> not used in the new code. > >>> > >>> 2.) fix ACIs that do not permit setting multiple values of > >>> 'krbPrincipalName' attribute per entry (see > >>> https://fedorahosted.org/freeipa/ticket/3961) > >>> > >>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >>> 'ipadb_find_principal' functions) to correctly perform lookup of > >>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >>> case-insensitively and krbcanonicalname case-sensitively, return > >>> krbcanonicalname when canonicalization is requested. > >>> > >>> 4.) Modify KDB backend and IPA framework to handle creation of both > >>> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >>> should be covered here (I remember that we should create > >>> krbcanonicalname when we add another aliases to krbprincipalname), so > >>> it > >>> would be nice if you could comment on this. > >>> > >>> 5.) write tests which cover all this stuff so that we don't shoot > >>> ourselves in the foot. > >>> > >>> I am not very well versed in Kerberos so I might get some of this > >>> stuff > >>> wrong. If that's the case please point me to the right direction. > >>> Also > >>> please write me some additional stuff which I have fogot and needs to > >>> be > >>> done. > >>> > >> > >> I think the summary is correct, the only thing we need to be careful is > >> to keep handling entries that have only a single valued > >> krbprincipalname > >> correctly as that will happen in upgrade paths and potentially if > >> someone uses external tools. > >> > >> The tricky part for point 3 is to implement it *without* changing the > >> schema. KrbPrincipalName is case-sensitive, however I think we can > >> solve > >> the issue of "searching case-insensitively" by always lower-casing the > >> principal name components and always upper casing the realm part on > >> storage. If we always store a krbCanonicalName we get the "correct" > >> case > >> there anyway so out mucking with the krbPrincipalName case will not be > >> a > >> problem for any new entry. > >> > >> This *may* cause issues with upgrades though, so we may need fallback > >> code that searches with the case sent by the client if we determine the > >> entry has no krbCanonicalName attribute (sign that it was created > >> before > >> we started adding krbCanonicalName and never "updated"). > >> > >> Note that we also need to think what will happen during and upgrade > >> when > >> some servers still use the current code and some servers will use the > >> new code. So I guess it would be nice if you could write down a table > >> with all possible forms a principal can be in on rows, and old/new > >> server states in columns, and mark what will happen for various > >> operations in each case. > >> > >> Simo. > > > > The list looks OK. Do we also plan to change the default RDN for new > > services > > or other objects that use krbPrincipalName as RDN at the moment? > > > > AFAIU, we are supposed to always use krbCanonicalName as the primary > > RDN and > > then only allow krbPrincipalName to be added for the aliases. Of > > course, the > > framework needs to still work with old services having krbPrincipalName. > > no, I think we can/should keep krbPrincipalName e.g. becasue > krbCanonicalName > is only optional according to the scheme. > >>> > >>> We might stropping using either and use CN instead for the RDN. > >> > >> This would make changing krbPrincipalName that happens to be RDN much > >> easier. > >> Wouldn't this break software that depends on this RDN already? > >> > >> Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? > > > > It would,. but so would a change to krbCanonicalName. If you
Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA
On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > Hi list, > > I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > and I would like to clarify what needs to be done in order to make IPA > to fully support multiple aliases per entry. > > So far I have identified these task based on the ticket comments and > discussion with Simo way back in the past: > > 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > not used in the new code. > > 2.) fix ACIs that do not permit setting multiple values of > 'krbPrincipalName' attribute per entry (see > https://fedorahosted.org/freeipa/ticket/3961) > > 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > 'ipadb_find_principal' functions) to correctly perform lookup of > krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > case-insensitively and krbcanonicalname case-sensitively, return > krbcanonicalname when canonicalization is requested. > > 4.) Modify KDB backend and IPA framework to handle creation of both > krbprincipalname and krbcanonicalname. I am not quite sure what cases > should be covered here (I remember that we should create > krbcanonicalname when we add another aliases to krbprincipalname), so it > would be nice if you could comment on this. > > 5.) write tests which cover all this stuff so that we don't shoot > ourselves in the foot. > > I am not very well versed in Kerberos so I might get some of this stuff > wrong. If that's the case please point me to the right direction. Also > please write me some additional stuff which I have fogot and needs to be > done. > I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. 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] fixing Kerberos principal aliases handling in IPA
On 09/01/2015 04:53 PM, Simo Sorce wrote: On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. Just to be sure, the new code should add 'krbcanonicalname' even if 'krbprinicpalname' contains only single value? So if for example we create a new entry, should it have both krbprincipalname and krbcanonical name set at creation? The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Yes we need to be extra careful to get it right here. Simo. -- 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] fixing Kerberos principal aliases handling in IPA
On Tue, 2015-09-01 at 17:55 +0200, Martin Babinsky wrote: > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > Just to be sure, the new code should add 'krbcanonicalname' even if > 'krbprinicpalname' contains only single value? So if for example we > create a new entry, should it have both krbprincipalname and > krbcanonical name set at creation? It wouldn't hurt. Simo. > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > Yes we need to be extra careful to get it right here. > > 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
