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