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

[Martin Babinsky]

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.
>
> Other than that it seems reasonable.
>

Thank you for your comments.


-- 
Martin^3 Babinsky