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

Martin Babinsky mbabinsk at redhat.com
Fri May 13 12:36:15 UTC 2016


On 05/13/2016 12:07 PM, Alexander Bokovoy wrote:
> On Thu, 12 May 2016, Martin Babinsky wrote:
>>> 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]?
> Why? I have not said that. I have said that you should not be able to
> specify UPN with a suffix that does not belong to us. I don't want us to
> allow to have Kerberos principals aliased to a trusted forest
> namespaces as this is violation of a forest trust.
>
I see that my reading comprehension skills are slowly declining over 
time :D. I now hope that I understand what you mean: the alias suffix 
MUST NOT overlap with any UPN suffix of a trusted forest. We then need 
to add these checks onto alias manipulation commands and add this to the 
design document.

>>>>> 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)?
> Again, no, this is not what I said. For UPNs from trusted domains I
> already have code to detect them and issue correct referral for clients
> to go to the proper KDC.
OK so it seems that we will need to coordinate our respective efforts.

-- 
Martin^3 Babinsky




More information about the Freeipa-devel mailing list