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

[Alexander Bokovoy]

On Fri, 06 May 2016, Martin Babinsky wrote:
>On 05/05/2016 02:58 PM, Milan Kubík wrote:
>>On 04/08/2016 05:10 PM, 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!
>>
>>I went through the design document and the related email thread here on
>>the list and I have few questions:
>>
>>1. Is there any progress on what's to happen if MODRDN would colide with
>>an existing alias on a different entry?
>>
>Both krbPrincipalName and krbCanonicalName will be guarded by 
>uniqueness plugin so this should raise an error in the DS backend.
>
>It will need some more investigation though and will probably warrant 
>a separate test case in the future test plan.
>
>>2. How does this RFE change the behavior of stage user plugin? Is the
>>principal (as in the canonical name) assigned at this stage of user
>>lifetime?
>>
>I didn't think about staged users when designing/doing patches. Thank 
>you for pointing this out. The principal name is assigned when 
>creating the staged user and it is also checked during activation and 
>again added if it is not present. We will need to handle both of these 
>cases. I will update the design to reflect this.
>
>>3. Will there be any constraints on what string can be used as an alias?
>>(The document mentions email address as one use case)
>>
>The e-mail case can be tricky, since having two '@' in the principal 
>name can break parsing/unparsing of principal name in KDB DAL. We will 
>likely have to implement some sort of escaping to handle this 
>correctly. This should be discussed in more detail with 
>Simo/Alexander/Sumit.
We should not allow anything after @ not belonging to the list of
realm domains. We also will need to extend realm domains to include
non-domain-based UPN suffixes. This actually flies close to what I need
to finish in my AD trust UPN patches, so I need to make sure we have the
same approach there.

>
>>4. Will this RFE have any impact on AD trust (possibility of cross realm
>>routing, RFC 6806 section 9)
>>
>
>IIRC there should be no impact on trusts.
We should never allow to specify alias from the realm we don't own. This
means the code needs to look into the namespaces associated with any of
the trusted domains and reject them.

-- 
/ Alexander Bokovoy