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

[Martin Babinsky]

On 05/09/2016 08:26 AM, Alexander Bokovoy wrote:
> 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.
>

Does this mean that we would not be able to implement e-mail as 
principal alias [1]?

>>
>>> 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.
>

So if I understand correctly we should reject tickets incoming from 
trusted domains if they do not contain canonical principal name (i.e. UPN)?

[1] https://fedorahosted.org/freeipa/ticket/5413

-- 
Martin^3 Babinsky