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

[Simo Sorce]

On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote:
> 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.

Yes.

> When requesting TGS search is always case-sensitive and principal from 
> request is used.

No, this sounds wrong to me, I think we want a case-insensitve search
for TGS requests.

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

I do not think the TGS part is right.
A case insensitive search in TGS would allow to match upper case service
or host names which are sometime mistakenly used, especially in Windows
born software, given that the AD KDC is case insensitive.

> 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

+1

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

-1 for users a rename means we change the principal and the canonical
name and we do not retain any old principal 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.

Yes, this is a problematic point, I am wondering if we should have a way
to tell if all KDCs are at a specific level before allowing to turn on
this behavior, but then we need to make it conditional and this all
starts to sound a lot like a new domain level.
OTOH only alias resolution fails on older KDCs, so that may be ok in
some cases.

Are there any strong opinions?
Should we make this change optional and activate it only when enough
features come up that demand a new domain level ?
We can always generate the canonicalName now to be ready, but prevent
adding aliases until a new domain level is created ?
Any other idea ?

Simo.

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