[Freeipa-devel] fixing Kerberos principal aliases handling in IPA

[Simo Sorce]

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:=ADMIN at 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