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

[thierry bordaz]

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
>
> 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").
>>>>
>>>> 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.
>>>>
>>
>>
>
>