[Freeipa-devel] Supporting UPNs of trusted forests

[Alexander Bokovoy]

On Wed, 02 Mar 2016, Simo Sorce wrote:
>On Wed, 2016-03-02 at 17:24 +0200, Alexander Bokovoy wrote:
>> On Wed, 02 Mar 2016, Petr Vobornik wrote:
>> >On 03/02/2016 11:55 AM, Alexander Bokovoy wrote:
>> >>Hi,
>> >>
>> >>http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains
>> >>describes a design page to support name suffixes from trusted Active
>> >>Directory domains.
>> >>
>> >>A prototype code exists (written by me and Sumit) and was tested by Sumit
>> >>against recent releases of SSSD.
>> >>
>> >>Text is provided below for easier commenting.
>> >>-----------------------------------------------------------------
>> >>{{Feature|version=TODO|ticket=TODO|author=Ab}}
>> >>
>> >>== Overview ==
>> >>User principal name (UPN) in Active Directory is the primary form of
>> >>addressing users. UPN has structure of 'user name at suffix' where both
>> >>user name and suffix parts may vary. By default the suffix is the same
>> >>as the Active Directory domain name but AD administrators may create
>> >>additional name suffixes and associate them with specific users. These
>> >>additional UPNs for users may then be used for Kerberos authentication
>> >>against Active Directory domains.
>> >>
>> >>Alternative UPNs are often used when several companies with Active
>> >>Directory deployments merge and want to provide unified logon namespace.
>> >>
>> >>The purpose of this feature is to allow using alternative UPNs
>> >>associated with the Active Directory users when accessing resources in
>> >>FreeIPA domain.
>> >>
>> >>== Use Cases ==
>> >>
>> >>As an Active Directory user, I want to login using my user at EXAMPLE user
>> >>principal name even if my Active Directory domain is named
>> >>REGION.EXAMPLE.COM.
>> >>== Design==
>> >>Support for UPNs is split to three different components:
>> >>;Client-side
>> >>: SSSD already supports logon with UPN by asking a KDC to accept
>> >>enterprise logon names.  By default, the use of enterprise principals is
>> >>disabled, therefore, <code>krb5_use_enterprise_principal = True</code>
>> >>needs to be added to sssd.conf to enable it.
>> >>
>> >>;KDC
>> >>: IPA KDC does understand multiple domains associated with the trusted
>> >>AD forest. However, since no information about name suffixes associated
>> >>with the forest is available, it cannot take them into account when
>> >>processing enteprise logon names to issue referrals to the correct
>> >>realm. Support needs to be added to allow IPA KDC to look up name
>> >>suffixes associated with a trusted forest.
>> >>
>> >>; IPA framework
>> >>: Changes needed on IPA framework side to fetch from Active Directory a
>> >>list of name suffixes and store them in the trusted domain objects.
>> >>
>> >>== Implementation ==
>> >>For retrieving name suffixes, IPA framework needs to move to use
>> >>NETLOGON netr_DsRGetForestTrustInformation function instead of
>> >>netr_DsrEnumerateDomainTrusts. This allows to retrieve both domains and
>> >>top level names associated with the forest.
>> >>
>> >>As top level names (TLNs) have only a single string as a name suffix,
>> >>they cannot be stored as trusted domains (they lack SID and NetBIOS
>> >>name). Thus, either IPA KDB driver needs to be extended to understand
>> >>trusted domains without SID and NetBIOS name, or TLNs need to be stored
>> >>as a property of tree root domains of the forest.
>> >>
>> >>== Feature Management ==
>> >>
>> >>=== UI ===
>> >>If TLNs are added as a property of tree root domains of the forest,
>> >>appropriate panel needs to be extended to display them.
>> >>
>> >>=== CLI ===
>> >>If TLNs are added as a property of tree root domains of the forest,
>> >>appropriate attribute need to be handled by '''trust-show''' command. If
>> >>TLNs represented as separate 'trusted domains' of the trusted forest, no
>> >>work is needed on CLI other than being able to support 'trusted domains'
>> >>without SID and NetBIOS name.
>> >
>> >What is meant by 'tree root domains of the forest' in IPA context? The
>> >trust object?
>> Yes. A forest might have multiple tree roots. We establish trust with
>> one of them (forest root domain) but you can have distinct tree roots
>> too. For a forest example.com a separate tree root could be ad.test
>> which is still a part of the forest. In Windows' UI for domains and
>> forests trust you'll see it as a separate entry at the top level. Each
>> tree root may have associated name suffixes.
>>
>> There are actually two different approaches we discussed with Sumit
>> -- one is to store TLNs as attributes of TDO, another is to create
>> separate TDOs, building on the fact you noticed:
>> >Btw trustdomain object has ipantflatname and ipanttrusteddomainsid
>> >attributes as optional so it is possible to store it there assuming
>> >modification of KDB driver.
>> This is what I did already in the prototype:
>> https://abbra.fedorapeople.org/.paste/0001-WIP-support-UPNs-for-trusted-domain-users.master.patch
>>
>> So we are sure that either way would work, the question is what would be
>> more usable UX-wise.
>
>How does Windows represent them ?
Weirdly.

>I'd try to stick to something close to what AD does to avoid pain if
>later is found that the way Windows does things is necessary (or just
>easier) to keep adding further options down the road.
See following article as an example, starting from third figure:
http://bohemiangrove.co.uk/outlook-anywhere-with-additonal-upn-suffix/

It is totally hidden under tree root domain properties in Active
Directory Domains and Trusts. There you can add name suffixes.

To use them you need to go to a specific user properties in Active
Directory Users and Computers and select the name suffix for user logon
name under account tab.

Once you chose a specific suffix, other suffixes cannot be used for this
user -- other than the primary one which is always enabled.

-- 
/ Alexander Bokovoy