Kerberos also has the ability to create a relationship between two otherwise separate Kerberos realms: a cross-realm trust. Realms that are part of a trust use a shared pair of a ticket and key; a member of one realm then counts as a member of both realms.
Red Hat Identity Management supports configuring a cross-forest trust between an IdM domain and an Active Directory domain.
5.1. Introduction to Cross-forest Trusts
Kerberos realm only concerns authentication. Other services and protocols are involved in complementing identity and authorization for resources running on the machines in the Kerberos realm.
As such, establishing Kerberos cross-realm trust is not enough to allow users from one realm to access resources in the other realm; a support is required at other levels of communication as well.
5.1.1. The Architecture of a Trust Relationship
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.
Active Directory Trusts, Forests, and Cross-forest Trusts
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.
Trust Flow and One-way Trusts
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 subdomains, 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.
Figure 5.1. One-way Trust
Transitive and Non-transitive Trusts
Trusts can be transitive so that a domain trusts another domain and any other domain trusted by that second domain.
Figure 5.2. Transitive Trusts
Trusts can also be non-transitive which means the trust is limited only to the explicitly included domains.
Cross-forest Trust in Active Directory and Identity Management
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.
Figure 5.3. Trust Direction
5.1.2. Active Directory Security Objects and Trust
Active Directory Global Catalog
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.
Global Catalog and POSIX Attributes
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.
5.1.3. Trust Architecture in IdM
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:
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.
Access 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
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.
126.96.36.199. Active Directory PACs and IdM Tickets
Group information in Active Directory is stored in a list of identifiers in the Privilege Attribute Certificate (MS-PAC or PAC) data set. The PAC contains various authorization information, such as group membership or additional credentials information. It also includes security identifiers (SIDs) of users and groups in the Active Directory domain. SIDs are identifiers assigned to Active Directory users and groups when they are created. In trust environments, group members are identified by SIDs, rather than by names or DNs.
A PAC is embedded in the Kerberos service request ticket for Active Directory users as a way of identifying the entity to other Windows clients and servers in the Windows domain. IdM maps the group information in the PAC to the Active Directory groups and then to the corresponding IdM groups to determine access.
When an Active Directory user requests a ticket for a service on IdM resources, the process goes as follows:
The request for a service contains the PAC of the user. The IdM 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.
When the IdM client evaluates the service ticket, the process includes the following steps:
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.
188.8.131.52. Active Directory Users and Identity Management Groups
When managing Active Directory users and groups, you can add individual AD users and whole AD groups to Identity Management groups.
Non-POSIX External Groups and SID Mapping
Group membership in the IdM LDAP is expressed by specifying a distinguished name (DN) of an LDAP object that is a member of a group. AD entries are not synchronized or copied over to IdM, which means that AD users and groups have no LDAP objects in the IdM LDAP. Therefore, they cannot be directly used to express group membership in the IdM LDAP.
For this reason, IdM creates non-POSIX external groups: proxy LDAP objects that contain references to SIDs of AD users and groups as strings. Non-POSIX external groups are then referenced as normal IdM LDAP objects to signify group membership for AD users and groups in IdM.
SIDs of non-POSIX external groups are processed by SSSD; SSSD maps SIDs of groups to which an AD user belongs to POSIX groups in IdM. The SIDs on the AD side are associated with user names. When the user name is used to access IdM resources, SSSD in IdM resolves that user name to its SID, and then looks up the information for that SID within the AD domain, as described in Section 184.108.40.206, “Active Directory PACs and IdM Tickets”
When a user is created in Linux, it is assigned a user ID number. In addition, a private group is created for the user. The private group ID number is the same as the user ID number. In Linux environment, this does not create a conflict. On Windows, however, the security ID number must be unique for every object in the domain.
Trusted AD users require a UID and GID number on a Linux system. This UID and GID number can be generated by IdM, but if the AD entry already has UID and GID numbers assigned, assigning different numbers creates a conflict. To avoid such conflicts, it is possible to use the AD-defined POSIX attributes, including the UID and GID number and preferred login shell.
AD stores a subset of information for all objects within the forest in a global catalog. The global catalog includes every entry for every domain in the forest. If you want to use AD-defined POSIX attributes, Red Hat strongly recommends that you first replicate the attributes to the global catalog.
When a trust is created, IdM automatically detects what kind of ID range to use and creates a unique ID range for the AD domain added to the trust. You can also choose this manually by passing one of the following options to the
ipa trust-add command:
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.
ipa trust-add --range-type=ipa-ad-trust-posix
220.127.116.11. Active Directory Users and IdM Policies and Configuration
Several IdM policy definitions, such as SELinux, host-based access control, sudo, and netgroups, rely on user groups to identify how the policies are applied.
Figure 5.4. Active Directory Users and IdM Groups and Policies
Active Directory users are external to the IdM domain, but they can still be added as group members to IdM groups, as long as those groups are configured as external groups described in Section 18.104.22.168, “Active Directory Users and Identity Management Groups”
. In such cases, the sudo, host-based access controls, and other policies are applied to the external POSIX group and, ultimately, to the AD user when accessing IdM domain resources.
The user SID in the PAC in the ticket is resolved to the AD identity. This means that Active Directory users can be added as group members using their fully-qualified user name or their SID.
5.1.4. One-Way and Two-Way Trusts
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.
- 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. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings.
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.
5.1.5. External Trusts to Active Directory
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.
5.1.6. Trust Controllers and Trust Agents
IdM provides the following types of IdM servers that support trust to Active Directory:
- Trust agents
IdM servers that can perform identity lookups against Active Directory domain controllers.
- Trust controllers
IdM servers with the capabilities of trust agents that also run the Samba suite. Active Directory domain controllers contact trust controllers when establishing and verifying the trust to Active Directory.
Trust controllers run an increased amount of network-facing services compared to trust agents, and thus present a greater attack surface for potential intruders.
In addition to trust agents and controllers, the IdM domain can also include standard IdM servers. However, these servers do not communicate with Active Directory. Therefore, clients that communicate with the standard servers cannot resolve Active Directory users and groups or authenticate and authorize Active Directory users.
Table 5.1. A comparison of the capabilities provided by trust controllers and trust agents
| Capability || Trust agents || Trust controllers |
| 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) || No || Yes |
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 standard server. To do this, use the
utility on the IdM server as described in Section 22.214.171.124.1, “Preparing the IdM Server for Trust”
You cannot downgrade an existing trust controller to a trust agent.