Re: [Freeipa-devel] One-way trust design
Thank you, the design page reads well to me. I had a short chat with Alexander where we cleared up some confusion. On Mon, Feb 23, 2015 at 06:02:53PM +0200, Alexander Bokovoy wrote: == 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@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. I will experiment with retrieving keytabs manually for now to simulate this part, then I'll write up a more detailed design on how to handle the one-way trusts. 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. -- 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
Re: [Freeipa-devel] One-way trust design
On Tue, 03 Mar 2015, Jan Pazdziora wrote: On Mon, Feb 23, 2015 at 06:02:53PM +0200, Alexander Bokovoy wrote: 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 Could you clarify which domain is the our domain? From SMB perspective whole IPA realm is a single domain. 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 Lost ability might be confusing -- was removed in 3.1 (?) might be better. We never had it as a feature so support for that wasn't removed. Rather, we lost ability to add that support. purpose of this feature is to regain the one-way trust support, yet without giving an elevated access to TDO credentials. You might also want to either add a note or a link, explaining why one-way trust is harder than two-way, IOW, why we lost the one-way ability when we have the two-way one. I think current text covers it clearly. If you have concrete suggestions, feel free to edit the wiki, it is not locked down. :) -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] One-way trust design
On Mon, Feb 23, 2015 at 06:02:53PM +0200, Alexander Bokovoy wrote: 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 Could you clarify which domain is the our domain? 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 Lost ability might be confusing -- was removed in 3.1 (?) might be better. purpose of this feature is to regain the one-way trust support, yet without giving an elevated access to TDO credentials. You might also want to either add a note or a link, explaining why one-way trust is harder than two-way, IOW, why we lost the one-way ability when we have the two-way one. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] One-way trust design
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@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@IPA.REALM
and host/ipa.master@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@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
