On Tue, 03 May 2016, Simo Sorce wrote:
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:
>>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.
>>== 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 ?
I think we should prevent it. This is currently a bit unclear because
I'm trying to come to a common ground in understanding trust namespace
conflicts with Samba AD DC and Windows. The way Metze implemented
conflict checking in Samba AD DC is against Windows rules and I plan to
clear it during SambaXP so that we have common logic. Once the logic is
defined, I can run verification using the algorithm implemented in

Secondary nitpick that came to mind right now, will one-way external
trust also be allowed/supported in the first implementation ?
Yes, it will -- the implementation I currently have is orthogonal to
one-way/two-way trust types.

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.
I agree, I'll add clarifications once everything is clear.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to