Language and Page Formatting Options
Chapter 5. Creating Cross-forest Trusts with Active Directory and Identity Management
5.1. Introduction to Cross-forest Trusts
5.1.1. The Architecture of a Trust Relationship
Active Directory Trusts, Forests, and Cross-forest Trusts
Trust Flow and One-way Trusts
Figure 5.1. One-way Trust
Transitive and Non-transitive Trusts
Figure 5.2. Transitive Trusts
Cross-forest Trust in Active Directory and Identity Management
Figure 5.3. Trust Direction
5.1.2. Active Directory Security Objects and Trust
Active Directory Global Catalog
Global Catalog and POSIX Attributes
5.1.3. Trust Architecture in IdM
- SSSD, to perform identity lookups on Active Directory and to retrieve user and group security identifiers (SIDs) for authorization. SSSD also caches user, group, and ticket information for users and maps Kerberos and DNS domains,
- Identity Management (Linux domain management), to associate the Active Directory user with an IdM group for IdM policies and access.
NoteAccess control rules and policies for Linux domain administration, such as SELinux, sudo, and host-based access controls, are defined and applied through Identity Management. Any access control rules set on the Active Directory side are not evaluated or used by IdM; the only Active Directory configuration which is relevant is group membership.
Trusts with Different Active Directory Forests
188.8.131.52. Active Directory PACs and IdM Tickets
- The request for a service contains the PAC of the user. The IdM Kerberos Distribution Centre (KDC) analyzes the PAC by comparing the list of Active Directory groups to memberships in IdM groups.
- For SIDs of the Kerberos principal defined in the MS-PAC, the IdM KDC evaluates external group memberships defined in the IdM LDAP. If additional mappings are available for an SID, the MS-PAC record is extended with other SIDs of the IdM groups to which the SID belongs. The resulting MS-PAC is signed by the IdM KDC.
- The service ticket is returned to the user with the updated PAC signed by the IdM KDC. Users belonging to AD groups known to the IdM domain can now be recognized by SSSD running on the IdM clients based on the MS-PAC content of the service ticket. This allows to reduce identity traffic to discover group memberships by the IdM clients.
- The Kerberos client libraries used in the evaluation process send the PAC data to the SSSD PAC responder.
- The PAC responder verifies the group SIDs in the PAC and adds the user to the corresponding groups in the SSSD cache. SSSD stores multiple TGTs and tickets for each user as new services are accessed.
- Users belonging to the verified groups can now access the required services on the IdM side.
184.108.40.206. Active Directory Users and Identity Management Groups
Non-POSIX External Groups and SID Mapping
- This range option is used for IDs algorithmically generated by IdM based on the SID.If IdM generates the SIDs using SID-to-POSIX ID mapping, the ID ranges for AD and IdM users and groups must have unique, non-overlapping ID ranges available.
- This range option is used for IDs defined in POSIX attributes in the AD entry.IdM obtains the POSIX attributes, including
gidNumber, from the global catalog in AD or from the directory controller. If the AD domain is managed correctly and without ID conflicts, the ID numbers generated in this way are unique. In this case, no ID validation or ID range is required.
[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix
Recreating a trust with the other ID range
- View all the ID ranges that are currently in use:
[root@ipaserver ~]# ipa idrange-findIn the list, identify the name of the ID range that was created by the
ipa trust-addcommand. The first part of the name of the ID range is the name of the trust: name_of_the_trust_id_range, for example ad.example.com.
- (Optional) If you do not know which
ipa-ad-trust-posix, was used when the trust was created, identify the option:
[root@ipaserver ~]# ipa idrange-show name_of_the_trust_id_rangeMake note of the type so that you choose the opposite type for the new trust in Step 5.
- Remove the range that was created by the
[root@ipaserver ~]# ipa idrange-del name_of_the_trust_id_range
- Remove the trust:
[root@ipaserver ~]# ipa trust-del name_of_the_trust
- Create a new trust with the correct
--range-typeoption. For example:
[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust
220.127.116.11. Active Directory Users and IdM Policies and Configuration
Figure 5.4. Active Directory Users and IdM Groups and Policies
5.1.4. One-Way and Two-Way Trusts
- One-way trust
- One-way trust enables AD users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain.One-way trust is the default mode for creating a trust.
- Two-way trust
- Two-way trust enables AD users and groups to access resources in IdM. You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the S4U2Self and S4U2Proxy Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might request S4U2Self or S4U2Proxy information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature.Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD.
ipa trust-addcommand again; by doing this, you can delete the existing trust and establish a new one.
5.1.5. External Trusts to Active Directory
5.1.6. Trust Controllers and Trust Agents
- Trust controllers
- IdM servers that can control the trust and perform identity lookups against Active Directory domain controllers (DC). Active Directory domain controllers contact trust controllers when establishing and verifying the trust to Active Directory. The first trust controller is created when you configure the trust.For details about configuring an IdM server as a trust controller, see Section 5.2.2, “Creating Trusts”.Trust controllers run an increased amount of network-facing services compared to trust agents, and thus present a greater attack surface for potential intruders.
- Trust agents
- IdM servers that can perform identity lookups against Active Directory domain controllers.For details about configuring an IdM server as a trust agent, see Section 18.104.22.168.1, “Preparing the IdM Server for Trust”.
Table 5.1. A comparison of the capabilities provided by trust controllers and trust agents
|Capability||Trust controllers||Trust agents|
|Resolve Active Directory users and groups||Yes||Yes|
|Enroll IdM clients that run services accessible by users from trusted Active Directory forests||Yes||Yes|
|Manage the trust (for example, add trust agreements)||Yes||No|
- Configure at least two trust controllers per Identity Management deployment.
- Configure at least two trust controllers in each data center.
ipa-adtrust-installutility on the IdM server as described in Section 22.214.171.124.1, “Preparing the IdM Server for Trust”.