On Wed, Mar 02, 2016 at 04:06:24PM +0100, 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
>
> Btw trustdomain object has ipantflatname and ipanttrusteddomainsid
> attributes as optional so it is possible to store it there assuming
> modification of KDB driver.
yes, Alexander has a POC patch which does exactly that. Nevertheless I
would prefer to store the list in the ipaNTTrustedDomain object of the
forest root where we also store the SID blacklist. I think this makes
sense because the alternative domain suffixes are a feature of the whole
forest. Any domain in the forest can use them and they basically have no
meaning on their own.
Additionally I think it is more clear the have them in properly named
attributes than adding some heuristics like:
ipaNTTrustedDomain with no SID and flat name == alternative domain
suffix
ipaNTTrustedDomain with SID and flat name and nothing else == member
domain in
the trusted forest
ipaNTTrustedDomain with SID, flat name and more == forest root
bye,
Sumit
>
> >
> >=== Configuration ===
> >No configuration options.
> >
> >== Upgrade ==
> >No impact to upgrade.
> >
> >== How to Test ==
> >In order to test UPN-based logons, create additional name suffixes in
> >Active Directory and establish trust to it. After trust is established,
> >the name suffixes should be usable when trying to kinit as enterprise
> >principal.
> >
> >== Test Plan ==
> >
> >-----------------------------------------------------------------
> >
> --
> Petr Vobornik
>
> --
> 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
--
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
