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:[email protected]). 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. > > 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
