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

[David Kupka]

On 08/04/16 17:10, 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,
after reading the designs following thoughts comes to my mind.

1) Just to be sure that I understand the new ticket obtaining process 
correctly I'd like to summarize.
We need to always search all krbPrincipalName values, krbCanonicalName 
and ipaKrbPrincipalAlias (for backward compatibility).
For TGT request case sensitivity of the search and principal in returned 
ticket depends on canonicalization. When canonicalization is requested 
the search is case-insensitive and krbCanonicalName is used otherwise 
case-sensitive search is performed and principal from request is used.
When requesting TGS search is always case-sensitive and principal from 
request is used.

In pseudo-code:

get_tgt(principal, secret, canonicalization)
     if canonicalization
         if principal case-insensitive-in {krbPrincipalName + 
ipaKrbPrincipalAlias + krbCanonicalName}
             # verify secret, perform various other checks...
             return TGT(krbCanonicalName)
     else
         if principal case-sensitive-in {krbPrincipalName + 
ipaKrbPrincipalAlias + krbCanonicalName}
             # verify secret, perform various other checks...
             return TGT(principal)

get_tgs(service_principal, TGT)
     if service_principal case-sensitive-in {krbPrincipalName + 
ipaKrbPrincipalAlias + krbCanonicalName}
         # verify TGT, perform various other checks...
         return TGS(service_principal)

Do I understand it right?

2) I would like to add following constrains for 
krb{Canonical,Principal}Name attributes:

when user/host/service is created krbCanonicalName is set to the same 
value as krbPrincipalName
krbCanonicalName cannot be modified
krbPrincipalName with the same value as krbCanonicalName cannot be 
removed/modified
krbPrincipalName must be case-insensitively unique in whole DB
krbPrincipalName attributes can be added and/or removed

This will allow us to keep the first krbPrincipalName as RDN for 
services/hosts and give the flexibility of adding/removing aliases.

'Change of username' use case is also solvable with this approach. When 
username is changed we add krbPrincipalName with the new username. That 
will allow user to login with either old or new name.

3) ad CLI:
{user,host,service}-add - Can canonicalname be specified? Or will it 
take principal argument/option value?
Can we add {user,host,service}-{add,remove}-principal set of commands 
for principal manipulation? I really don't want to use 
--{add,set,del}-attr unless necessary.
Will {user,host,service}-{show,find} display krbCanonicalName by default 
or only with --all option?

4) ad Upgrade:
I think it would be worth to check and document what happens during 
upgrade of multiple replicas. There may be confusing behavior when 
obtaining tickets. KDC behavior will differ among servers and since 
autodiscovery is in use we don't know if we are talking to the old or 
new server. I'm not sure what exactly will happen but I suspect it won't 
be nice.

-- 
David Kupka