[Freeipa-devel] [DESIGN] Kerberos principal alias handling
thierry bordaz
tbordaz at redhat.com
Mon Apr 11 14:58:11 UTC 2016
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.
thanks
thierry
More information about the Freeipa-devel
mailing list