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

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to