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

[thierry bordaz]

On 09/07/2015 09:47 PM, Simo Sorce wrote:
> 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.
>
Yes that is correct, those searches with matching rule are unindexed. I 
think the reason is #48270 that reject the configuration of the index 
with such MR.
Once it will be fixed it should do an indexed search with the MR 
specified in the filter.
Storing lower case/upper case principal/realm will work with new 
database but if we have to handle old database we should fix DS.

thierry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150908/9d3c4b79/attachment.htm>