[Freeipa-devel] External trust to AD

Simo Sorce simo at redhat.com
Tue May 3 16:53:36 UTC 2016


On Wed, 2016-03-02 at 21:11 +0200, Alexander Bokovoy wrote:
> On Wed, 02 Mar 2016, Petr Vobornik wrote:
> >On 03/02/2016 11:13 AM, Alexander Bokovoy wrote:
> >>Hi,
> >>
> >>http://www.freeipa.org/page/V4/External_trust_to_AD documents a design
> >>for external trust to AD feature.
> >>
> >>The text is included below for easier review.
> >>-----------------------------------------------------------------------
> >>{{Feature|version=TODO|ticket=TODO|author=Ab}}
> >>
> >>== Overview ==
> >>Support for external trust to a domain from Active Directory forest
> >>
> >>An external trust is a trust relationship between Active Directory
> >>domains that are in different Active Directory forests. While forest
> >>trust always requires to establish trust between root domains of the
> >>Active Directory forests, external trust can be established to any
> >>domain within the forest.
> >>
> >>== Use Cases ==
> >>
> >>As an Active Directory domain admin, I want to establish trust between
> >>IPA and my domain only. The trust between IPA and an external Active
> >>Directory domain will be non-transitive as no users or groups from other
> >>Active Directory domains will have access to IPA resources.
> >>
> >>== Design==
> >>
> >>External trust between Active Directory domains is by definition
> >>non-transitive and enforces SID filtering between the domain boundaries.
> >>This means only users and groups with SIDs from the trusted domain can
> >>use the resources and be visible on IPA systems. None of other users and
> >>groups from domains the trusted domain trusts within its own Active
> >>Directory forest or other externally trusted domains will be allowed to
> >>access IPA resources.
> >>
> >>== Implementation ==
> >>
> >>External trust feature re-uses existing forest trust infrastructure.
> >>There are several specific changes to allow supporting external trust:
> >>* '''Non-transitivity''': since external trust is non-transitive by
> >>* definition, any attempt to set transitivity feature of the trust link
> >>* with LSA SetInformationTrustedDomain() command will fail. Thus, there
> >>* is no need to set transitivity for the external trust.
> >
> >Sounds very simple :)
> >
> >Do I get it right that it is possible to do it today? Because now the 
> >code just do:
> >   root_logger.error('unable to set trust to transitive: %s' % (str(e)))
> >   pass
> I have a patchset to add this support already. I want to clean up some
> parts of it, namely, reporting of the resulting trust type, but it all works.
> 
> >
> >>* '''Trust attributes''': external trust can be detected by looking into
> >>* absense of ipaNTTrustAttributes LDAP attribute of the trusted domain
> >>* object.
> >>
> >>== Feature Management ==
> >>
> >>=== UI ===
> >>An option 'external trust' needs to be added to Web UI, corresponding to
> >>'--external' flag in 'trust-add' command in CLI.
> >>
> >>=== CLI ===
> >>An external trust creation can be requested by passing additional flag
> >>'--external=true' to the 'trust-add' command. The flag defaults to
> >>'false', e.g. no external trust would be created.
> >>
> >>{| class="wikitable"
> >>|-
> >>! Command
> >>! Options
> >>|-
> >>| trust-add
> >>| --external=true/false
> >>|}
> >
> >We should also add 'external' param to output of trust_find and 
> >trust_show + corresponding change in Web UI and CLI.
> It will be part of trust type string, not a separate param.


I reviewed the design and associated tickts, and all checks out for me.
I have only one nitpick that is not spelled out.

What happens if someone has a forest trust and tries to also set up an
external trust with a child domain of the existing forest trust ?

Do we need to add code to prevent it, or should we allow it ?

Secondary nitpick that came to mind right now, will one-way external
trust also be allowed/supported in the first implementation ?

I have some ideas on the answers to the above questions, but I think
they should be put in the design as considerations and explained there. 

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list