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

[Simo Sorce]

On Mon, 2016-04-11 at 12:50 +0200, Martin Babinsky wrote:
> On 04/11/2016 11:05 AM, Petr Spacek wrote:
> > On 8.4.2016 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
> >
> > I cannot say much about the implementation, but I would appreciate following
> > information:
> >
> > CLI
> > ===
> > 1) {user,host,service}-add operate with canonical name, right? This could be
> > made clear so normal user understands the text.
> >
> The *-add commands operate on both, they will set krbCanonicalName 
> attribute and copy the same value to the krbPrincipalName. I will update 
> the design to made this clear.
> 
> > 2) Is it possible to change the canonical name?
> For users the canonical name will be changed during 'rename' operation, 
> since the principal is generated from the primary key. I'm not sure 
> about hosts/services since their primary keys are currently immutable.
> 
> If we make them mutable, then the behavior shall be consistent with the 
> user entries.
> 
> >
> > 3) Can Web UI work with aliases without --principal-alias parameter?
> >
> Probably not and we would require to add this options to users and 
> services. Hosts already have '--principalname' option currently 
> restricted to single value, we may change it to multi-valued and add it 
> also to other two entities.
> 
> >
> > Upgrade
> > =======
> >> The backward compatibility with older machines will be kept while the new attributes will be replicated to older master when new host/service/entries will be created on new ones. No special upgrade procedure shall be necessary.
> >
> > It would be good to explicitly mention that old attributes will be still
> > populated => old and new replicas can work in the same topology.
> >
> Ok I will make this more clear.

Old attributes should not be populated, we are abandoning them because
they can't work, they will simply not be removed from the schema to
avoid constraints violations, but they will rapidly be deprecated and
not used anymore.

We need to assess the impact on keeping older replicas running for long,
with old framework and KDC code, but I do not think there will be issues
in the general case.

Simo.

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