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

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.

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.

Other than that it seems reasonable.

Thank you for your comments.

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