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

[Martin Babinsky]

On 04/13/2016 07:50 AM, 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.
> 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
>
I will definitwly add this constraints into the design.

> 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.
I have added the commands to the design.

> Will {user,host,service}-{show,find} display krbCanonicalName by default
> or only with --all option?
>
IIRC it should be printed out only when '--all' is requested.
> 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.
>
I will test this but I expected that 'kinit -C' will get back TGT with 
different principal for different replica (old vs. new) for newly added 
entries (the old entries will behave the same as before). That may not 
be what we want, but I can not think of any way to amend this.

What we forgot to discuss is the handling of krbCanonicalName during 
MODRDN operation, e.g. when username is changed.

Currently the design assumes that when uid changes the MODRDN plugin 
will change krbCanonicalName attribute to reflect this change, e.g.

uid: jsmith->johns

krbCanonicalName: jsmith at REALM -> krbCanoncialName: johns at REALM

I remember talking with Simo (CC'ed) that this is the desired behavior 
but I am not sure if this still holds.

-- 
Martin^3 Babinsky