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

[Petr Spacek]

On 2.9.2015 08:11, 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.

+1, I was going to propose the very same thing.

This is a standard LDAP thing, see
http://tools.ietf.org/search/rfc4515#section-4 . Just keep in mind that we may
need to add index for caseIgnoreMatch.

Petr^2 Spacek

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