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

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

Reply via email to