Trust relationships can be either one-way or two-way. In an IdM one-way trust, IdM trusts AD without reciprocation. AD users can access IdM resources, but IdM users cannot access AD resources.

In a two-way trust, IdM users can authenticate to AD and AD users can authenticate to IdM. AD users can access resources in IdM in the same way as a one-way trust. IdM users can authenticate to AD but can only access Kerberos-enabled services in AD forests without access control checks. Accessing AD resources from IdM is not currently possible, and so accessing resources is limited from both ends.

In one-way or two-way trusts, IdM servers exchange authentication data with Active Directory Domain Controllers (DC).

The first domain in the forest is the root domain. This domain remains active for the lifecycle of the forest. IdM domains cannot be part of an existing Active Directory forest, and are treated as a separate forest by Active Directory. When you establish a trust relationship between two separate forest root domains, the trust is called an Active Directory cross-forest trust.

IdM can be part of trust relationships with multiple Active Directory forests, allowing users from unrelated Active Directory forests to access resources in the same shared IdM domain.

There are many ways to configure Active Directory trusts between subdomains, root domains, and forests. The trust flow identifies how information moves between domains. Trusted domains contain users, and trusting domains allow access to resources. In a one-way trust, trusts flow only in one direction; users have access to the trusting domain's resources, but users in the trusting domains cannot access resources in the trusted domain.

You can configure transitive and non-transitive trusts between domains. When you configure a transitive trust, the configured domain trusts another domain and any other domain trusted by that trusted domain.

The following diagram describes a transitive trust between three domains. The DOMAIN C domain trusts DOMAIN A because DOMAIN C trusts DOMAIN B and DOMAIN B trusts DOMAIN A.

Figure 8.2: Transitive trust between domains

In a non-transitive trust relationship, the trust is limited to only the domains explicitly specified. Within an Active Directory forest, trust relationships between domains are usually two-way and transitive by default. Trust between two Active Directory forests is a trust between two forest root domains, which can be two-way or one-way. The transitivity of the cross-forest trust is explicit, which means that any domain trust within an Active Directory forest that leads to the root domain of the forest is transitive over the cross-forest trust. Separate cross-forest trusts are not transitive; therefore, you must establish an explicit cross-forest trust between each Active Directory forest root domain to another Active Directory forest root domain.

An IdM domain represents a separate Active Directory forest with a single Active Directory domain. Through a cross-forest trust between an Active Directory forest root domain and an IdM domain, users from the Active Directory forest can interact with Linux machines and services from the IdM domain.

The following diagram describes users from an Active Directory domain accessing resources in an IdM domain after the trust has been established between the two domains:

Figure 8.3: Trust direction between two domains

You can add individual Active Directory users and groups to IdM groups. User groups are required to set access permissions, host-based access control, Sudo rules, and other controls on IdM users. These groups grant or restrict access to IdM domain resources. Active Directory users and groups can be added directly to IdM user groups.

To add users and groups to the IdM server, add Active Directory users to a non-POSIX IdM external group, and then to a local IdM POSIX group. The POSIX group is then used for user and role management of the Active Directory users.

IdM uses LDAP for managing groups, which are expressed by specifying the distinguished name (DN) of an LDAP object that is a member of a group. Active Directory entries are not synchronized or copied to IdM, which means that Active Directory users and groups have no LDAP objects in the LDAP directory. Consequently, LDAP objects cannot be directly used to express group membership in the IdM LDAP.

For this reason, IdM creates non-POSIX external groups, referenced as normal IdM LDAP objects to signify group membership for Active Directory 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 usernames. When a username is used to access IdM resources, SSSD in IdM resolves the username to its security ID before retrieving the information for that SID in the Active Directory domain.

Linux users are assigned a user ID (UID) number and a private group. The private group identifier number is the same as the user ID number. In a Linux environment, this does not create a conflict, but in Active Directory, the security ID number must be unique for every object in the domain. The trusted users in Active Directory require a UID and a group ID (GID) number in Linux systems.

These UID and GID numbers can be generated by IdM, however, if Active Directory entries already have UIDs and GIDs numbers assigned, assigning different numbers creates a conflict. Therefore, to avoid conflict, use the POSIX attributes defined by Active Directory instead of having IdM generate new values. These attributes include the UID, the GID number, and preferred login shell.

When you create a trust, IdM automatically detects which ID range to use and creates a unique range for Active Directory domains added to the trust. Pass one of the following --range-type options to the ipa trust-add command to define the range:

If there are no ID conflicts, then the ID numbers that are generated are unique, so no ID validation or ID range is required.

Before establishing a trust, consider the following requirements for establishing a trust between IdM and Active Directory domains.

Before you establish a trust, you can verify the DNS configuration by resolving the domain services.

If your environment does not use DNSSEC, you can disable it in IdM to prevent communication errors. Edit the /etc/named/ipa-options-ext.conf file and update the dnssec-enable and dnssec-validation directives. Restart the named service after you apply the changes:

[root@host ~]# cat /etc/named/ipa-options-ext.conf
...output omitted...
dnssec-enable no;
dnssec-validation no;
[root@host ~]# systemctl restart named.service

In the following examples, you test different services such as Kerberos and LDAP and the IdM realm name:

[user@host ~]$ dig +short -t SRV _kerberos._udp.example.com
0 100 88 idm.example.com.
[user@host ~]$ dig +short -t SRV _ldap._tcp.idm.example.com
0 100 389 idm.example.com.
[user@host ~]$ dig +short -t TXT _kerberos.idm.example.com.
"EXAMPLE.COM"

In the following examples, you test the resolution of domain controllers and service records in Active Directory:

[user@host ~]$ dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
0 100 88 idm.example.com.
[user@host ~]$ dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
0 100 389 idm.example.com.
[user@host ~]$ dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com.
0 100 88 ad.example.com.
[user@host ~]$ dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
0 100 389 ad.example.com.

Install the ipa-server-trust-ad package and run the ipa-adtrust-install utility. This utility adds DNS service records required for Active Directory trusts. These records are created automatically if IdM is installed with an integrated DNS server.

If IdM is not installed with an integrated DNS server, the ipa-adtrust-install command prints a list of service records that must be manually added to DNS before proceeding with establishing the trust:

[root@host ~]# dnf install ipa-server ipa-server-trust-ad samba-client
...output omitted...
[root@host ~]# ipa-adtrust-install

Use the ipa trust-add command to create a trust agreement. The command sets up a one-way trust by default. To establish a two-way trust, use the --two-way=true option:

[user@host ~]$ ipa trust-add example.com \
  --type=ad \
  --admin=administrator \
  --password

The following procedure describes the necessary steps for verifying the Kerberos configuration upon establishing a trust agreement.

To verify the Kerberos configuration, retrieve a ticket for an AD user. To verify a two-way trust, request a ticket for an IdM user, and then request a service ticket for a service in the Active Directory domain.

[user@host ~]$ kinit user
[user@host ~]$ kvno -S host idm.example.com
[user@host ~]$ kvno -S cifs ad.example.com

If successfully granted, a cross-realm ticket-granting ticket (TGT) is listed with all other requested tickets. The TGT name uses the krbtgt/AD.DOMAIN@IDM.DOMAIN format.

To verify a one-way trust, request a ticket for an Active Directory user, and then request a service ticket for a service within the IdM domain.

[user@host ~]$ kinit user@ad.example.com
[user@host ~]$ kvno -S host idm.example.com

If granted, a cross-realm Ticket-granting Ticket (TGT) is listed with all other requested tickets. The TGT is called krbtgt/IDM.DOMAIN@AD.DOMAIN.

Then, log in to a client as an Active Directory user:

[user@host ~]$ ssh ad_user@ad.example.com@client.example.com

You can also verify the Active Directory trust agreements in the web UI. Log in to the Active Directory server as the administrator user and access the Active Directory Domains and Trusts tool from the Server Manager dashboard. Review the trust type for the domain. Ensure that the trust type reads Forest and that the direction of the trust is set to Incoming.

Shared secrets are passwords known to trusted peers, and which can be used by other domains to join the trust. Using a shared secret, you can configure a two-way trust within Active Directory. The shared secret is stored as a Trusted Domain Object (TDO) within the trust configuration.

IdM supports creating a two-way trust using a shared secret instead of the Active Directory administrator credentials. Setting up such a trust requires the administrator to create the shared secret in Active Directory and manually validate the trust.

To configure a trust in the Active Directory Domains and Trusts console with a shared secret, use the following procedure:

Then you can create a trust agreement. When running the ipa trust-add command, use the --type, --trust-secret, and --two-way=True options, and omit the --admin option. On the IdM server, ensure that the trust relationship is established by running the ipa trust-show command.