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.

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

Reply via email to