Chapter 6. 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.

6.1. Cross-forest trusts 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.

6.2. Trust controllers and trust agents

Identity Management (IdM) provides the following types of IdM servers that support trust to Active Directory (AD):

Trust agents
IdM servers that can perform identity lookups against AD domain controllers.
Trust controllers

Trust agents that also run the Samba suite. AD domain controllers contact trust controllers when establishing and verifying the trust to AD.

The first trust controller is created when you configure the trust.

Trust controllers run more network-facing services than 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 AD. Therefore, clients that communicate with the standard servers cannot resolve AD users and groups or authenticate and authorize AD users.

Table 6.1. Comparing the capabilities supported by trust controllers and trust agents

CapabilityTrust agentTrust controller

Resolve AD users and groups

Yes

Yes

Enroll IdM clients that run services accessible by users from trusted AD 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:

  • 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.

6.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.

6.4. 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.

6.5. Setting up DNS

These guidelines can help you achieve the right DNS configuration for establishing 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.

No overlap between IdM and AD DNS Domains
Systems joined to IdM can be distributed over multiple DNS domains. Ensure the DNS domains that contain IdM clients do not overlap with DNS domains that contain systems joined to AD.
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:

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.

6.6. 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.

6.7. 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 2008 — Windows Server 2016
  • Domain functional level range: Windows Server 2008 — Windows Server 2016

Identity Management (IdM) supports the following operating systems:

  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

6.8. Configuring AD server discovery and affinity

Server discovery and affinity configuration affects which Active Directory (AD) servers an Identity Management (IdM) client communicates with. This section provides an overview of how discovery and affinity work in an environment with 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 make sure 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:

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

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.

6.9. Operations performed during indirect integration of IdM to AD

Table 6.2, “Operations performed from an IdM trust controller towards AD domain controllers” shows which operations and requests are performed during the creation of an Identity Management (IdM) to Active Directory (AD) trust from the IdM trust controller towards AD domain controllers.

Table 6.2. Operations performed from an IdM trust controller towards AD domain controllers

OperationProtocol usedPurpose

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

Table 6.3, “Operations performed from an AD domain controller towards IdM trust controllers” shows which operations and requests are performed during the creation of an IdM to AD trust from the AD domain controller towards IdM trust controllers.

Table 6.3. Operations performed from an AD domain controller towards IdM trust controllers

OperationProtocol usedPurpose

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