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

[1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases

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)
         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
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@REALM -> krbCanoncialName: johns@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

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to