Chapter 5. Creating Cross-forest Trusts with Active Directory and Identity Management

Both Active Directory and Identity Management manage a variety of core services such as Kerberos, LDAP, DNS, or certificate services. To transparently integrate these two diverse environments, all core services must interact seamlessly with one another.

Kerberos cross-realm trust plays an important role in authentication between Active Directory environments. All activities to resolve user and group names in a trusted AD domain require authentication, regardless of how access is performed: using LDAP protocol or as part of the Distributed Computing Environment/Remote Procedure Calls (DCE/RPC) on top of the Server Message Block (SMB) protocol. Because there are more protocols involved in organizing access between two different Active Directory domains, trust relationship has a more generic name, Active Directory trust.

Multiple AD domains can be organized together into an Active Directory forest. A root domain of the forest is the first domain created in the forest. Identity Management domain cannot be part of an existing AD forest, thus it is always seen as a separate forest.

When trust relationship is established between two separate forest root domains, allowing users and services from different AD forests to communicate, a trust is called Active Directory cross-forest trust.

A trust establishes an access relationship between two domains. Active Directory environments can be complex so there are different possible types and arrangements for Active Directory trusts, between child domains, root domains, or forests. A trust is a path from one domain to another. The way that identities and information move between the domains is called a trust flow.

The trusted domain contains users, and the trusting domain allows access to resources. In a one-way trust, trust flows only in one direction: users can access the trusting domain's resources but users in the trusting domain cannot access resources in the trusted domain. In Figure 5.1, “One-way Trust”, Domain A is trusted by Domain B, but Domain B is not trusted by Domain A.

IdM allows the administrator to configure both one-way and two-way trusts. For details, see Section 5.1.4, “One-Way and Two-Way Trusts”.

Trusts can be transitive so that a domain trusts another domain and any other domain trusted by that second domain.

Trusts can also be non-transitive which means the trust is limited only to the explicitly included domains.

Within an Active Directory forest, trust relationships between domains are normally two-way and transitive by default.

Because trust between two AD forests is a trust between two forest root domains, it can also be two-way or one-way. The transitivity of the cross-forest trust is explicit: any domain trust within an AD forest that leads to the root domain of the forest is transitive over the cross-forest trust. However, separate cross-forest trusts are not transitive. An explicit cross-forest trust must be established between each AD forest root domain to another AD forest root domain.

From the perspective of AD, Identity Management represents a separate AD forest with a single AD domain. When cross-forest trust between an AD forest root domain and an IdM domain is established, users from the AD forest domains can interact with Linux machines and services from the IdM domain.

The global catalog contains information about objects of an Active Directory. It stores a full copy of objects within its own domain. From objects of other domains in the Active Directory forest, only a partial copy of the commonly most searched attributes is stored in the global catalog. Additionally, some types of groups are only valid within a specific scope and might not be part of the global catalog.

Note that the cross-forest trust context is wider than a single domain. Therefore, some of these server-local or domain-local security group memberships from a trusted forest might not be visible to IdM servers.

Active Directory does not replicate POSIX attributes with its default settings. If it is required to use POSIX attributes that are defined in AD Red Hat strongly recommends to replicate them to the global catalog service.

On the Identity Management side, the IdM server has to be able to recognize Active Directory identities and appropriately process their group membership for access controls. The Microsoft PAC (MS-PAC, Privilege Account Certificate) contains the required information about the user; their security ID, domain user name, and group memberships. Identity Management has two components to analyze data in the PAC on the Kerberos ticket:

IdM can also be part of trust relationships with different AD forests. Once a trust is established, additional trusts with other forests can be added later, following the same commands and procedures. IdM can trust multiple entirely unrelated forests at the same time, allowing users from such unrelated AD forests access to resources in the same shared IdM domain.

[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix

IdM supports two types of trust agreements, depending on whether the entities that can establish connection to services in IdM are limited to only AD or can include IdM entities as well.

For more general information on one-way and two-way trusts, see Section 5.1.1, “The Architecture of a Trust Relationship”.

After a trust is established, it is not possible to modify its type. If you require a different type of trust, run the ipa trust-add command again; by doing this, you can delete the existing trust and establish a new one.

An external trust is a trust relationship between domains that are in a different forests. While forest trusts always require to establish the trust between the root domains of Active Directory forests, you can establish an external trust to any domain within the forest.

External trusts are non-transitive. For this reason, users and groups from other Active Directory domains have no access to IdM resources. For further information, see the section called “Transitive and Non-transitive Trusts”.

IdM provides the following types of IdM servers that support trust to Active Directory:

In addition to trust controllers and agents, the IdM domain can also include replicas without any role. However, these servers do not communicate with Active Directory. Therefore, clients that communicate with these servers cannot resolve Active Directory users and groups or authenticate and authorize Active Directory users.

When planning the deployment of trust controllers and trust agents, consider these guidelines:

If you ever want to create additional trust controllers or if an existing trust controller fails, create a new trust controller by promoting a trust agent or a replica. To do this, use the ipa-adtrust-install utility on the IdM server as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.