Chapter 7. Planning a cross-forest trust between IdM and AD Active Directory (AD) and Identity Management (IdM) are two alternative environments managing a variety of core services, such as Kerberos, LDAP, DNS, and certificate services. A cross-forest trust relationship transparently integrates these two diverse environments by enabling all core services to interact seamlessly. The following sections provide advice on how to plan and design a cross-forest trust deployment. 7.1. Cross-forest and external trusts between IdM and AD A cross-forest trust between IdM and AD In a pure Active Directory (AD) environment, a cross-forest trust connects two separate AD forest root domains. When you create a cross-forest trust between AD and IdM, the IdM domain presents itself to AD as a separate forest with a single domain. A trust relationship is then established between the AD forest root domain and the IdM domain. As a result, users from the AD forest can access the resources in the IdM domain. IdM can establish a trust with one AD forest or multiple unrelated forests. Note Two separate Kerberos realms can be connected in a cross-realm trust . However, a Kerberos realm only concerns authentication, not other services and protocols involved in identity and authorization operations. Therefore, establishing a Kerberos cross-realm trust is not enough to enable users from one realm to access resources in another realm. An external trust to an AD domain An external trust is a trust relationship between IdM and an Active Directory domain. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to any domain within a forest. 7.2. Trust controllers and trust agents Identity Management (IdM) provides the following types of IdM servers that support trust to Active Directory (AD): Trust controllers IdM servers that can perform identity lookups against AD domain controllers. They also run the Samba suite so they can establish trust with AD. AD domain controllers contact trust controllers when establishing and verifying the trust to AD. AD-enrolled machines communicate with IdM trust controllers for Kerberos authentication requests. The first trust controller is created when you configure the trust. In environments with multiple domain controllers across different geographic locations, it is beneficial to designate additional RHEL IdM servers as trust controllers in these locations. Trust controllers run more network-facing services than trust agents, and thus present a greater attack surface for potential intruders. Trust agents IdM servers that can resolve identity lookups from RHEL IdM clients against AD domain controllers. Unlike trust controllers, trust agents cannot process Kerberos authentication requests. In addition to trust agents and controllers, the IdM domain can also include standard IdM servers. However, these servers do not communicate with AD. Therefore, clients that communicate with these standard servers cannot resolve AD users and groups or authenticate and authorize AD users. By default, IdM servers cannot resolve users and groups from trusted domains. To allow IdM servers to interact with trusted domains, you must explicitly configure them to operate as trust controllers or trust agents. Table 7.1. Comparing the capabilities supported by trust controllers and trust agents Capability Trust agent Trust controller Resolve AD users and groups Yes Yes Enroll IdM clients that run services accessible by users from trusted AD forests Yes Yes Add, modify, or remove trust agreements No Yes Assign the trust agent role to an IdM server No Yes When planning the deployment of trust controllers and trust agents, consider these guidelines: Configure at least two trust controllers per IdM deployment. Configure at least two trust controllers in each data center. 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 ipa-adtrust-install utility on the IdM server. Important You cannot downgrade an existing trust controller to a trust agent. Additional resources Creating a trust agent 7.3. One-way trusts and two-way trusts In one way trusts, Identity Management (IdM) trusts Active Directory (AD) but AD does not trust IdM. AD users can access resources in the IdM domain but users from IdM cannot access resources within the AD domain. The IdM server connects to AD using a special account, and reads identity information that is then delivered to IdM clients over LDAP. In two way trusts, IdM users can authenticate to AD, and AD users can authenticate to IdM. AD users can authenticate to and access resources in the IdM domain as in the one way trust case. IdM users can authenticate but cannot access most of the resources in AD. They can only access those Kerberized services in AD forests that do not require any access control check. To be able to grant access to the AD resources, IdM needs to implement the Global Catalog service. This service does not yet exist in the current version of the IdM server. Because of that, a two-way trust between IdM and AD is nearly functionally equivalent to a one-way trust between IdM and AD. 7.4. Kerberos FAST for trusted domains Kerberos Flexible Authentication Secure Tunneling (FAST) is also called Kerberos armoring in an Active Directory (AD) environment. Kerberos FAST provides an additional security layer for the Kerberos communication between the clients and the Key Distribution Center (KDC). In IdM, the KDCs are running on the IdM servers and FAST is enabled by default. The Two-Factor Authentication (2FA) in IdM also requires enabling FAST. In AD, Kerberos armoring is disabled by default on the AD Domain Controllers (DC). You can enable it on the Domain Controller on the Tools>Group Policy Management>Default Domain Controller Policy: Right-click Default Domain Controller Policy and select edit . Navigate to Computer Configuration>Policies>Administrative Templates>System>KDC and double-click KDC support for claims, compound authentication, and Kerberos armoring . Once you enable KDC support for claims, the policy setting allows the following options: Not supported Supported Always provide claims Fail unarmored authentication requests Kerberos FAST is implemented in the Kerberos client libraries on IdM clients. You can configure IdM clients either to use FAST for all trusted domains which advertise FAST or to not use Kerberos FAST at all. If you enable Kerberos armoring in the trusted AD forest the IdM client uses Kerberos FAST by default. FAST establishes a secure tunneling with the help of a cryptographic key. To protect the connection to the domain controllers of a trusted domain, Kerberos FAST must get a cross-realm Ticket Granting Ticket (TGT) from the trusted domain because those keys are valid only inside the Kerberos realm. Kerberos FAST uses the Kerberos hosts keys of the IdM client to request the cross-realm TGT with the help of the IdM servers. That only works when the AD forest trusts the IdM domain which means a two-way trust is required. If AD policies require the enforcing of Kerberos FAST use, you need to establish a two-way trust between IdM domain and AD forest. You must plan this before the connection is established because both IdM and AD must have records about direction and the type of trust. If you already established a one-way trust, run the ipa trust-add ... --two-way=true command to remove the existing trust agreement and create a two-way trust. This requires use of administrative credentials. As IdM attempts to remove the existing trust agreement from the AD side, it requires administrator permissions for AD access. If you establish the original trust by using a shared secret rather than an AD administrative account, it recreates the trust as a two-way and changes trusted domain objects on the IdM side only. Windows administrators must repeat the same procedure by using Windows UI to choose a bi-directional trust and use the same shared secret to recreate the trust. If using a two-way trust is not possible, you must disable Kerberos FAST on all IdM clients. The users from the trusted AD forest can authenticate with a password or direct smart card. To disable Kerberos FAST, add the following setting to the sssd.conf file in the [domain] section: Note, you do not need to use this option when the authentication is based on ssh-keys, GSSAPI authentication or SSH with smart cards from remote Windows clients. These methods do not use Kerberos FAST because the IdM client does not have to communicate with a DC. Additionally, after disabling FAST on the IdM client, the two-factor authentication IdM feature is also unavailable. 7.5. POSIX and ID mapping ID range types for AD users Identity Management (IdM) enforces access control rules based on the POSIX User ID (UID) and Group ID (GID) of a user. In contrast, Active Directory (AD) identifies users by Security Identifiers (SIDs).As an administrator, you can configure AD to store POSIX attributes for your AD users and groups, such as uidNumber , gidNumber , unixHomeDirectory , or loginShell . You configure AD to store POSIX attributes when you are setting up the trust agreement using the ipa-ad-trust-posix ID range. In scenarios when AD does not store POSIX attributes, the System Security Services Daemon (SSSD) can consistently map a unique UID based on a user's SID in a process called ID mapping . You can explicitly choose this behavior by selecting the ipa-ad-trust ID range during trust creation. Additional resources Options for automatically mapping private groups for AD users Setting up a trust agreement using the command line 7.6. Options for automatically mapping private groups for AD users: POSIX trusts Each user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG. If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range. auto_private_groups =false By default, the auto_private_groups option is set to false for ipa-ad-trust-posix ID ranges used in a POSIX trust. With this configuration, SSSD retrieves the uidNumber and gidNumber from each AD user entry. When auto_private_groups is set to false , SSSD assigns the uidNumber value to the user's UID, the gidNumber to the user's GID. A group with that GID must exist in AD, or you will not be able to resolve that user. The following table demonstrates user resolution outcomes based on various AD configurations. Table 7.2. SSSD behavior when the auto_private_groups variable is set to false for a POSIX ID range User configuration in AD Output of id username AD user entry has: uidNumber = 4000 gidNumber is not defined No group in AD with gidNumber = 4000. SSSD cannot resolve the user. AD user entry has: uidNumber = 4000 gidNumber = 4000 No group in AD with gidNumber = 4000. SSSD cannot resolve the user. AD user entry has: uidNumber = 4000 gidNumber = 4000 AD has a group with gidNumber = 4000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( adgroup@ad-domain.com ) groups=4000( adgroup@ad-domain.com ), ... If an AD user does not have a primary group configured in AD, or its gidNumber does not correspond to an existing group, the IdM server is unable to resolve that user correctly because it cannot look up all the groups the user belongs to. To work around this issue, you can enable automatic private group mapping in SSSD by setting the auto_private_groups option to true or hybrid : auto_private_groups = true SSSD always maps a private group with the gidNumber set to match the uidNumber from the AD user entry. Table 7.3. SSSD behavior when the auto_private_groups variable is set to true for a POSIX ID range User configuration in AD Output of id username AD user entry has: uidNumber = 4000 gidNumber is not defined AD does not have a group with GID=4000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( aduser@ad-domain.com ) groups=4000( aduser@ad-domain.com ), ... AD user entry has: uidNumber = 4000 gidNumber = 5000 AD does not have a group with gidNumber = 5000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( aduser@ad-domain.com ) groups=4000( aduser@ad-domain.com ), ... AD user entry has: uidNumber = 4000 gidNumber = 4000 AD does not have a group with gidNumber = 4000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( aduser@ad-domain.com ) groups=4000( aduser@ad-domain.com ), ... AD user entry has: uidNumber = 4000 gidNumber = 5000 AD has a group with gidNumber = 5000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( aduser@ad-domain.com ) groups=4000( aduser@ad-domain.com ), ... auto_private_groups = hybrid If the uidNumber value matches gidNumber , but there is no group with this gidNumber , SSSD maps a private group as the user's primary user group with a gidNumber that matches the uidNumber . If the uidNumber and gidNumber values differ, and there is a group with this gidNumber , SSSD uses the value from gidNumber . Table 7.4. SSSD behavior when the auto_private_groups variable is set to hybrid for a POSIX ID range User configuration in AD Output of id username AD user entry with: uidNumber = 4000 gidNumber is not defined AD does not have a group with gidNumber = 4000. SSSD cannot resolve the user. AD user entry with: uidNumber = 4000 gidNumber = 5000 AD does not have a group with gidNumber = 5000. SSSD cannot resolve the user. AD user entry with: uidNumber = 4000 gidNumber = 4000 AD does not have a group with gidNumber = 4000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=4000( aduser@ad-domain.com ) groups=4000( aduser@ad-domain.com ), ... AD user entry with: uidNumber = 4000 gidNumber = 5000 AD has a group with gidNumber = 5000. # id aduser@AD-DOMAIN.COM uid=4000( aduser@ad-domain.com ) gid=5000( aduser@ad-domain.com ) groups=5000( adgroup@ad-domain.com ), ... Additional resources Enabling automatic private group mapping for a POSIX ID range on the CLI Enabling automatic private group mapping for a POSIX ID range in the IdM WebUI 7.7. Options for automatically mapping private groups for AD users: ID mapping trusts Each user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG. If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range. By default, the auto_private_groups option is set to true for ipa-ad-trust ID ranges used in an ID mapping trust. With this configuration, SSSD computes the UID and GID for an AD user based on its Security Identifier (SID). SSSD ignores any POSIX attributes in AD, such as uidNumber , gidNumber , and also ignores the primaryGroupID . auto_private_groups = true SSSD always maps a private group with the GID set to match the UID, which is based on the SID of the AD user. Table 7.5. SSSD behavior when the auto_private_groups variable is set to true for an ID mapping ID range User configuration in AD Output of id username AD user entry where: SID maps to 7000 primaryGroupID maps to 8000 # id aduser@AD-DOMAIN.COM uid=7000( aduser@ad-domain.com ) gid=7000( aduser@ad-domain.com ) groups=7000( aduser@ad-domain.com ), 8000( adgroup@ad-domain.com ), ... auto_private_groups = false If you set the auto_private_groups option to false , SSSD uses the primaryGroupID set in the AD entry as the GID number. The default value for primaryGroupID corresponds to the Domain Users group in AD. Table 7.6. SSSD behavior when the auto_private_groups variable is set to false for an ID mapping ID range User configuration in AD Output of id username AD user entry where: SID maps to 7000 primaryGroupID maps to 8000 # id aduser@AD-DOMAIN.COM uid=7000( aduser@ad-domain.com ) gid=8000( adgroup@ad-domain.com ) groups=8000( adgroup@ad-domain.com ), ... 7.8. Non-POSIX external groups and SID mapping Identity Management (IdM) uses LDAP for managing groups. Active Directory (AD) entries are not synchronized or copied over to IdM, which means that AD users and groups have no LDAP objects in the LDAP server, so they cannot be directly used to express group membership in the IdM LDAP. For this reason, administrators in IdM need to create non-POSIX external groups, referenced as normal IdM LDAP objects to signify group membership for AD users and groups in IdM. Security IDs (SIDs) for non-POSIX external groups are processed by SSSD, which maps the SIDs of groups in Active Directory to POSIX groups in IdM. In Active Directory, SIDs are associated with user names. When an AD user name is used to access IdM resources, SSSD uses the user's SID to build up a full group membership information for the user in the IdM domain. 7.9. Guidelines for setting up DNS for an IdM-AD trust These guidelines can help you configure DNS to establish a cross-forest trust between Identity Management (IdM) and Active Directory (AD). Unique primary DNS domains Ensure both AD and IdM have their own unique primary DNS domains configured. For example: ad.example.com for AD and idm.example.com for IdM example.com for AD and idm.example.com for IdM The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but you can also use any other standard-compliant DNS server. IdM and AD DNS Domains Systems joined to IdM can be distributed over multiple DNS domains. Red Hat recommends that you deploy IdM clients in a DNS zone different to the ones owned by Active Directory. The primary IdM DNS domain must have proper SRV records to support AD trusts. Note In some environments with trusts between IdM and Active Directory, you can install an IdM client on a host that is part of the Active Directory DNS domain. The host can then benefit from the Linux-focused features of IdM. This is not a recommended configuration and has some limitations. See Configuring IdM clients in an Active Directory DNS domain for more details. Proper SRV records Ensure the primary IdM DNS domain has proper SRV records to support AD trusts. For other DNS domains that are part of the same IdM realm, the SRV records do not have to be configured when the trust to AD is established. The reason is that AD domain controllers do not use SRV records to discover Kerberos key distribution centers (KDCs) but rather base the KDC discovery on name suffix routing information for the trust. DNS records resolvable from all DNS domains in the trust Ensure all machines can resolve DNS records from all DNS domains involved in the trust relationship: When configuring the IdM DNS, follow the instructions described in Installing an IdM server with an external CA . If you are using IdM without integrated DNS, follow the instructions described in Installing an IdM server without integrated DNS . Kerberos realm names as upper-case versions of primary DNS domain names Ensure Kerberos realm names are the same as the primary DNS domain names, with all letters uppercase. For example, if the domain names are ad.example.com for AD and idm.example.com for IdM, the Kerberos realm names must be AD.EXAMPLE.COM and IDM.EXAMPLE.COM . 7.10. Guidelines for configuring NetBIOS names The NetBIOS name is usually the far-left component of the domain name. For example: In the domain name linux.example.com , the NetBIOS name is linux . In the domain name example.com , the NetBIOS name is example . Different NetBIOS names for the Identity Management (IdM) and Active Directory (AD) domains Ensure the IdM and AD domains have different NetBIOS names. The NetBIOS name is critical for identifying the AD domain. If the IdM domain is within a subdomain of the AD DNS, the NetBIOS name is also critical for identifying the IdM domain and services. Character limit for NetBIOS names The maximum length of a NetBIOS name is 15 characters. 7.11. Supported versions of Windows Server You can establish a trust relationship with Active Directory (AD) forests that use the following forest and domain functional levels: Forest functional level range: Windows Server 2012 - Windows Server 2016 Domain functional level range: Windows Server 2012 - Windows Server 2016 Identity Management (IdM) supports establishing a trust with Active Directory domain controllers running the following operating systems: Windows Server 2022 (RHEL 9.1 and later) Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Important Identity Management (IdM) does not support establishing trust to Active Directory with Active Directory domain controllers running Windows Server 2008 R2 or earlier versions. RHEL IdM requires SMB encryption when establishing the trust relationship, which is only supported in Windows Server 2012 or later. 7.12. AD server discovery and affinity Server discovery and affinity configuration affects which Active Directory (AD) servers an Identity Management (IdM) client communicates with in a cross-forest trust between IdM and AD. Configuring clients to prefer servers in the same geographical location helps prevent time lags and other problems that occur when clients contact servers from another, remote data center. To verify clients communicate with local servers, you must ensure that: Clients communicate with local IdM servers over LDAP and over Kerberos Clients communicate with local AD servers over Kerberos Embedded clients on IdM servers communicate with local AD servers over LDAP and over Kerberos Options for configuring LDAP and Kerberos on the IdM client for communication with local IdM servers When using IdM with integrated DNS By default, clients use automatic service lookup based on the DNS records. In this setup, you can also use the DNS locations feature to configure DNS-based service discovery. To override the automatic lookup, you can disable the DNS discovery in one of the following ways: During the IdM client installation by providing failover parameters from the command line After the client installation by modifying the System Security Services Daemon (SSSD) configuration When using IdM without integrated DNS You must explicitly configure clients in one of the following ways: During the IdM client installation by providing failover parameters from the command line After the client installation by modifying the SSSD configuration Options for configuring Kerberos on the IdM client for communication with local AD servers IdM clients are unable to automatically discover which AD servers to communicate with. To specify the AD servers manually, modify the krb5.conf file: Add the AD realm information Explicitly list the AD servers to communicate with For example: Options for configuring embedded clients on IdM servers for communication with local AD servers over Kerberos and LDAP The embedded client on an IdM server works also as a client of the AD server. It can automatically discover and use the appropriate AD site. When the embedded client performs the discovery, it might first discover an AD server in a remote location. If the attempt to contact the remote server takes too long, the client might stop the operation without establishing the connection. Use the dns_resolver_timeout option in the sssd.conf file on the client to increase the amount of time for which the client waits for a reply from the DNS resolver. See the sssd.conf(5) man page for details. Once the embedded client has been configured to communicate with the local AD servers, the SSSD remembers the AD site the embedded client belongs to. Thanks to this, SSSD normally sends an LDAP ping directly to a local domain controller to refresh its site information. If the site no longer exists or the client has meanwhile been assigned to a different site, SSSD starts querying for SRV records in the forest and goes through a whole process of autodiscovery. Using trusted domain sections in sssd.conf , you can also explicitly override some of the information that is discovered automatically by default. Additional resources Working with DNS in Identity Management 7.13. Operations performed during indirect integration of IdM to AD The following table lists operations and requests performed by an Identity Management IdM trust controller towards Active Directory AD domain controllers during the creation of an IdM to AD trust. Table 7.7. Operations performed from an IdM trust controller towards AD domain controllers Operation Protocol used Purpose DNS resolution against the AD DNS resolvers configured on an IdM trust controller DNS To discover the IP addresses of AD domain controllers Requests to UDP/UDP6 port 389 on an AD DC Connectionless LDAP (CLDAP) To perform AD DC discovery Requests to TCP/TCP6 ports 389 and 3268 on an AD DC LDAP To query AD user and group information Requests to TCP/TCP6 ports 389 and 3268 on an AD DC DCE RPC and SMB To set up and support cross-forest trust to AD Requests to TCP/TCP6 ports 135, 139, 445 on an AD DC DCE RPC and SMB To set up and support cross-forest trust to AD Requests to dynamically opened ports on an AD DC as directed by the Active Directory domain controller, likely in the range of 49152-65535 (TCP/TCP6) DCE RPC and SMB To respond to requests by DCE RPC End-point mapper (port 135 TCP/TCP6) Requests to ports 88 (TCP/TCP6 and UDP/UDP6), 464 (TCP/TCP6 and UDP/UDP6), and 749 (TCP/TCP6) on an AD DC Kerberos To obtain a Kerberos ticket; change a Kerberos password; administer Kerberos remotely The following table lists operations and requests performed by AD domain controllers towards IdM trust controllers during the creation of an IdM to AD trust. Table 7.8. Operations performed from an AD domain controller towards IdM trust controllers Operation Protocol used Purpose DNS resolution against the IdM DNS resolvers configured on an AD domain controller DNS To discover the IP addresses of IdM trust controllers Requests to UDP/UDP6 port 389 on an IdM trust controller CLDAP To perform IdM trust controller discovery Requests to TCP/TCP6 ports 135, 139, 445 on an IdM trust controller DCE RPC and SMB To verify the cross-forest trust to AD Requests to dynamically opened ports on an IdM trust controller as directed by the IdM trust controller, likely in the range of 49152-65535 (TCP/TCP6) DCE RPC and SMB To respond to requests by DCE RPC End-point mapper (port 135 TCP/TCP6) Requests to ports 88 (TCP/TCP6 and UDP/UDP6), 464 (TCP/TCP6 and UDP/UDP6), and 749 (TCP/TCP6) on an IdM trust controller Kerberos To obtain a Kerberos ticket; change a Kerberos password; administer Kerberos remotely

Commands:
krb5_use_fast = never
[realms] AD.EXAMPLE.COM = { kdc = server1.ad.example.com kdc = server2.ad.example.com }