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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York