[Freeipa-devel] Supporting UPNs of trusted forests

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy