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@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@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
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
