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

Tue Apr 19 16:50:47 UTC 2016

On Tue, 2016-04-19 at 12:37 +0200, Martin Babinsky wrote:
> On 04/19/2016 10:11 AM, David Kupka wrote:
> > On 18/04/16 21:42, Simo Sorce wrote:
> >> 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.
> >>
> >
> > Ok, thanks for correcting me.
> >
> >>> 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.
> >>
> >
> > But this is inconsistent with the constrains above, especially
> > "krbCanonicalName cannot be modified". We have the following options:
> >
> > 1) Do not allow rename for hosts and services but allow it for users.

Yep, this is what we had for a long time, I see no reason for changing,
no any inconsistency.

> > 2) Allow renaming of all objects.
> > 3) Do not allow renaming of anything.
> >
> We already support renaming of user entries and the MODRDN plugin 
> handles the rename of krbPrincipalName attribute. In this case we need 
> to retain this behavior to be backwards compatible. Moreover, we would 
> *have* to rename krbCanonicalName for the same reason. The question 
> remains what to do if there are already some other aliases in place and 
> the user is renamed. I will investigate this further.

Aliases should be preserve, the only gotcha is if someone is renaming a
user to a name that is already on the entry as an alias.
We need to allow that and not fail the operation in that case, IMO.

> > I don't like 1) because it is inconsistent. User renaming is nice
> > feature so we probably don't want 3). Which leaves us with different set
> > of constrains:
> >
> > there always needs to be krbPrincipalName with the same value as
> > krbCanonicalName
> > krbPrincipalName must be case-insensitively unique in whole DB
> > krbPrincipalName attributes can be added and/or removed
> >
> > Is this what we want? Is it wise to allow renaming of hosts and
> > services? Is there a use case? Is there any potential danger?
> >
> For now I'do go with option 1.). It kind of preserves the current status 
> quo (users have --rename but services/hosts do not) and I'm afraid that 
> allowing rename operation on hosts/services will open a Pandora's box.

Renaming of services makes little sense, you'd have to download a keytab
again anyway, in most cases. And host and services are generally tied to
the hostname anyway.
If there is huge demand for something like this we may allow it, but in
general I'd say we keep the status quo.

> >>> 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 ?
> >
> > I would not go for a new domain level, it will just add a lot of 'if'
> > statements all over the code. I believe it will be enough to document
> > that canonicalization and other new features can be used only after all
> > replicas in topology are upgraded.
> >
> + 1 just look how much work was required (and still is) to fully support 
> domain level 1.

So here I disagree with the reasoning, it doesn't really matter if it is
inconvenient for *us*. What matters is what is most usable and
convenient for admins and reduces confusion and possible misbehavior.

We may not need to use a domain level, but, unless we have a clear path
to make sure mixed domain (with old and new servers) work properly we
may not have any other option actually.

Simo.

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