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

[David Kupka]

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.


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


-- 
David Kupka