[Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Petr Spacek]

On 11.4.2016 16:58, thierry bordaz wrote:
> 
> 
> On 04/11/2016 04:51 PM, Simo Sorce wrote:
>> On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote:
>>> On 04/08/2016 05:10 PM, Martin Babinsky wrote:
>>>> Hi list,
>>>>
>>>> I have put together a draft [1] outlining the effort to reimplement
>>>> the handling of Kerberos principals in both backend and frontend
>>>> layers of FreeIPA so that we may have multiple aliases per user, host
>>>> or service and thus implement stuff like
>>>> https://fedorahosted.org/freeipa/ticket/3961 and
>>>> https://fedorahosted.org/freeipa/ticket/5413 .
>>>>
>>>> Since much of the plumbing was already implemented,[2] the document
>>>> mainly describes what the patches do. Some parts required by other use
>>>> cases may be missing so please point these out.
>>>>
>>>> I would also be happy if you could correct all factual inacurracies, I
>>>> did research on this issue a long time ago and my knowledge turned a
>>>> bit rusty.
>>>>
>>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
>>>> [2]
>>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html
>>>>
>>> Hi Martin,
>>>
>>>      Currently DS is enforcing that 'krbPrincipalName' and
>>>      'krbCanonicalName' are unique.
>>>      krbPrincipalName is caseExactIA5Match.
>>>      Is it possible to imagine entries having the same (IgnoreCase) alias:
>>>
>>>          dn: uid=user_one,cn=users,cn=accounts,<suffix>
>>>          ...
>>>          krbCanonicalName: user_one@<realm>
>>>          krbPrincipalName: user_one@<realm>
>>>          krbPrincipalName: user_ONE@<realm>
>>>
>>>          dn: uid=user_two,cn=users,cn=accounts,<suffix>
>>>          ...
>>>          krbCanonicalName: user_two@<realm>
>>>          krbPrincipalName: user_two@<realm>
>>>          krbPrincipalName: user_TWO@<realm>
>>>          krbPrincipalName: *user_**One*@<realm>
>>>
>>>      So KDB, searching as case insentive
>>>      "krbPrincipalName:caseIgnoreIA5Match:=USER_one@<realm>" will
>>>      retrieve user_one and user_two ?
>> Yes, but it is an error to have the same alias (differing just by case)
>> on two distinct principals. So this is an error condition not an
>> expected use case.
>>
>> Simo.
>>
> I agree.
> At uniqueness plugin, this could be prevented if we add the support of
> matchingRule for uniqueness lookup.

Sounds like a good idea to me!

-- 
Petr^2 Spacek