[Freeipa-devel] One-way trust design

[Alexander Bokovoy]

Hi!

I've added a design page for one-way trust to www.freeipa.org/page/V4/One-way_trust

Below is the page content for easy discussion:

========================================================================
{{Feature|version=4.2.0|ticket=4546|author=Ab}}

= Overview =
Active Directory implementation of a trust between domains and forests
uses credentials of a trust domain object (TDO) to communicate across
the trust boundary. This is made possible on AD side because whole
domain controller implementation is seen as a monolith that doesn't pass
around the credentials for the trust domain object. This is purely
implementation detail though important one.

In early stages of a trust feature development FreeIPA also used trust
domain object to directly authenticate against Active Directory
services. However, as IPA is a combination of several loosely coupled
services, access to the trust domain object is highly guarded to prevent
unwanted elevation of privileges across the trust boundary. If FreeIPA
was to use TDO's credentials everywhere, it would mean most of
trust-related  functionality would be limited to IPA admins or TDO
object in LDAP would have to be more  accessible. Given that TDO
credentials can be used to compromise access to our  domain, it is not
advisable to give a wider access to them.

As a side-effect of reducing exposure of TDO credentials, FreeIPA lost
ability to establish and use one-way trust to Active Directory. The
purpose of this feature is to regain the one-way trust support, yet
without giving an elevated access to TDO credentials.

= Use cases =
A primary use case is the following one:

* One-way trust to Active Directory where FreeIPA realm trusts Active
* Directory forest using cross-forest trust feature of AD but the AD
* forest does not trust FreeIPA realm. Users from AD forest can access
* resources in FreeIPA realm.

No other use cases exist at the moment.

= Design =

The one-way feature relies on an implementation of FreeIPA trust to AD
feature as released in FreeIPA v3.3. The difference between FreeIPA v3.3
and v3.0 is in the way how credentials to access information from a
trusted forest are used.

== FreeIPA v3.0 and v3.3 ==
In FreeIPA v3.0 each IPA master initialized with ipa-adtrust-install
command was running Samba suite: smbd and winbindd daemons were used to
provide both capabilities to resolve AD users from trusted forests, to
manage trust forest topology, and to respond on NETLOGON interfaces as
Active Directory Domain Controllers expect to complete the sequence of
establishing trust relationships. The rest of clients in FreeIPA were
connecting to IPA masters through SSSD by means of an extended LDAP
control to resolve AD users and groups. FreeIPA LDAP server's plugin
which implemented the extended LDAP control was, in turn, talking to
winbindd daemon to complete the resolution of AD users and groups.

Additionally, in early FreeIPA v3.0 versions a management framework
(both CLI and web UI) was using credentials of TDO to directly resolve
AD users and groups against Active Directory Domain Controllers. The
consequence of this was that only IPA admins were able to map users and
groups from trusted Active Directory forests to local groups.

The trust by AD DCs means that FreeIPA framework can utilize existing
Kerberos service ticket it has (HTTP/ipa.master at IPA.REALM) to
authenticate to AD LDAP servers. AD LDAP servers allow access to its
information only to authenticated clients but the clients can provide
any proof of authenticity allowed by Active Directory. In the case of
cross-forest trust in AD, a properly issued Kerberos ticket from a
trusted forest is enough. In order to issue such ticket, FreeIPA KDC
does generate privilege attribute certificate data (MS-PAC) as required
by Microsoft's specification
[https://msdn.microsoft.com/en-us/library/cc237917.aspx [MS-PAC]]. In
order to limit which Kerberos services are allowed to authenticate
against services in a trusting AD forest, only HTTP/ipa.master at IPA.REALM
and host/ipa.master at IPA.REALM are given the MS-PAC in their TGT tickets
where the services are presented as members of a virtual Domain
Controllers group in FreeIPA domain.

FreeIPA v3.0 management framework was switched to use
HTTP/ipa.master at IPA.REALM Kerberos ticket with attached MS-PAC
information to directly resolve AD users and groups.

In FreeIPA v3.3 each IPA master initialized with ipa-adtrust-install
command still runs Samba suite: smbd and winbindd daemons. They are used
to respond on NETLOGON interfaces as Active Directory Domain Controllers
expect them, and to manage trust forest topology. However, users and
groups from trusted Active Directory forests are now resolved by SSSD
running on the IPA masters. SSSD has gained a so-called "IPA server
mode" which means the requests to resolve AD users and groups will go
directly to Active Directory Domain Controllers. The rest of clients in
FreeIPA are connecting to IPA masters through SSSD by means of the same
extended LDAP control to resolve AD users and groups. However, FreeIPA
LDAP server's plugin which implements the extended LDAP control now
talks to SSSD on the IPA master instead of winbindd daemon to complete
the resolution of AD users and groups. Finally, a management framework
also relies on the SSSD on IPA master to resolve users and groups from
trusted Active Directory forests. As a consequence of that, IPA admins
can delegate rights to map AD users and groups without giving access to
TDO credentials anymore.

In its own turn, SSSD 1.11 as used by FreeIPA v3.3, relies on the fact
that Active Directory Domain Controllers do trust FreeIPA realm and uses
host/ipa.master at IPA.REALM Kerberos ticket to directly resolve AD users
and groups. 

Final consequence of v3.0 and v3.3 trust feature designs was the fact
that if IPA clients needed to resolve AD users and groups, they needed
to be enrolled to an IPA master which has been initialized with
ipa-adtrust-install. As a result, in major deployments all of IPA
masters had to run smbd and winbindd processes. While this is an
improvement over requirement to run winbindd to every single client as
with some other solutions, it is still too fragile for production. This
shortcoming is addressed by [[V4/Trust agents]] feature design.

== New design ==
In order to support one-way trust to Active Directory, we need to switch
SSSD in IPA master mode to use TDO credentials when resolving AD users
and groups. This is a high level description of the design, and majority
of work to allow the switch will be done by SSSD team. Corresponding
ticket tracker on SSSD side is
[https://fedorahosted.org/sssd/ticket/2579 ticket 2579], the text below
is an overview of the design.

On each IPA master SSSD runs in "IPA master mode". This mode means that
in case of existing trust to AD forest, SSSD will directly resolve AD
users and groups against Active Directory Domain Controllers. To perform
user/group resolution, SSSD needs to authenticate against AD LDAP
servers and it does so using Kerberos authentication based on a
host/ipa.master at IPA.REALM service ticket. The ticket towards AD LDAP
services is issued by FreeIPA KDC with the help of cross-realm trust
credentials.

For one-way trust SSSD cannot use this approach because Active Directory
Domain Controllers do not trust FreeIPA realm and, therefore, no
cross-realm trust credentials exist in AD for FreeIPA realm. However,
SSSD can use TDO object which always exists in AD for the trusting
domain (cross-forest trust is done by forest root domains' trust). This
means the ticket SSSD would need to request belongs to a different realm
(AD forest root realm) rather than to FreeIPA realm.

As FreeIPA supports multiple trusts to separate Active Directory
forests, a support for multiple separate tickets is required. SSSD will
need to gain ability to use different credentials caches to store TDO
tickets and use different keytabs with TDO credentials to obtain the
ticket from an Active Directory Domain Controllers.

In order to separate privilege access, FreeIPA masters have to provide
keytabs for SSSD running on IPA masters, one keytab per trusted AD
forest, so that SSSD could request the keys when required.

Additionally, FreeIPA management framework will need to change its
defaults from producing a two-way trust to a one-way trust. Two-way
trust will be added back when support for Global Catalog service will be
added so that Active Directory resources could be properly accessed and
access to them discretionally granted to FreeIPA users and groups.

= Implementation =
Following changes will need to be done on FreeIPA side in order to
support one-way trust:

# Switch two-way trust creation in ipaserver/dcerpc.py to one-way by
# default. 
## The code needs to be changed to allow specifying either one- or
two-way trust and should manipulate trust_direction property (by setting
lsa.LSA_TRUST_DIRECTION_OUTBOUND or a combination of
lsa.LSA_TRUST_DIRECTION_INBOUND and lsa.LSA_TRUST_DIRECTION_OUTBOUND) in
TrustDomainInstance.establish_trust() method. 
## One-way trust can be created with full AD administrator credentials
too, while shared secret method will rely on the AD administrator
creating the remote part of it in AD.
# Make sure ipalib/plugins/trust.py passes properly a flag to enable
# two-way trust. 
# Change ipasam to create additional principal named IPA$@AD.REALM form
# when creating TDO object for AD.REALM forest trust. This principal has
# to be disabled so that KDC cannot use it to issue tickets.

= Feature management =

== CLI ==
At first stage nothing needs to be changed. The created trust will
become one-way only, no additional options will be needed.

At second stage we can add an option to create two-way trust.

== Web UI ==
No changes in Web UI are required if we wouldn't expose two-way trust
option.

== Replication ==
Trust-related information is in the replicated subtree already.

== Upgrades ==
No changes on upgrade are needed.

When SSSD will gain ability to handle one-way trusts, it will use
ipa-getkeytab to obtain the keytabs.



-- 
/ Alexander Bokovoy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150223/2f007de9/attachment.sig>