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

[Simo Sorce]

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:=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?
> >
> > 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:=user1005000 at EXAMPLE.COM)"
> 
> 2) ldapsearch -h localhost -D "cn=Directory Manager" -b 
> cn=users,cn=accounts,dc=example,dc=com -w freeipa8 
> "(krbprincipalname:caseExactIA5Match:=user1005000 at EXAMPLE.COM)"'
> 
> 3) ldapsearch -h localhost -D "cn=Directory Manager" -b 
> cn=users,cn=accounts,dc=example,dc=com -w freeipa8 
> "(krbprincipalname=user1005000 at 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.

-- 
Simo Sorce * Red Hat, Inc * New York