5.2. Creating Cross-forest Trusts
5.2.1. Environment and Machine Requirements
5.2.1.1. Supported Windows Platforms
- Forest functional level range: Windows Server 2008 - Windows Server 2016 R2
- Domain functional level range: Windows Server 2008 - Windows Server 2016 R2
- Windows Server 2012 R2
- Windows Server 2016
5.2.1.2. DNS and Realm Settings
- Unique primary DNS domains
- Each system must have its own unique primary DNS domain configured. For example:
ad.example.comfor AD andidm.example.comfor IdMexample.comfor AD andidm.example.comfor IdM
Note
Due to a bug, tracked in BZ#1421869, IdM does not work correctly when the IdM domain is a parent domain of the AD domain, for example:example.comfor IdM andad.example.comfor AD.The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but it is possible to use any other standard-compliant DNS server as well.It is not possible for AD or IdM to share the primary DNS domain with another system for identity management. For more information, see documentation for host name and DNS configuration requirements in the Linux Domain Identity, Authentication, and Policy Guide. - Kerberos realm names as upper-case versions of primary DNS domain names
- Kerberos realm names must be the same as the primary DNS domain names, with all letters uppercase. For example, if the domain names are
ad.example.comfor AD andidm.example.comfor IdM, the Kerberos realm names are required to beAD.EXAMPLE.COMandIDM.EXAMPLE.COM. - DNS records resolvable from all DNS domains in the trust
- All machines must be able to resolve DNS records from all DNS domains involved in the trust relationship:
- When configuring IdM DNS, follow the instructions described in the section on configuring DNS services within the IdM domain and section on managing DNS forwarding in the Linux Domain Identity, Authentication, and Policy Guide.
- If you are using IdM without integrated DNS, follow the instructions described in the section describing the server installation without integrated DNS in the Linux Domain Identity, Authentication, and Policy Guide.
- No overlap between IdM and AD DNS domains
- Machines joined to IdM can be distributed over multiple DNS domains. DNS domains containing IdM clients must not overlap with DNS domains containing machines joined to AD. The primary IdM DNS domain must have proper SRV records to support AD trusts.You can acquire a list of the required SRV records specific to your system setup by running the
$ ipa dns-update-system-records --dry-runcommand.The generated list can look for example like this:$ ipa dns-update-system-records --dry-run IPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos.example.com. 86400 IN TXT "EXAMPLE.COM" _kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com. _kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com. _ntp._udp.example.com. 86400 IN SRV 0 100 123 server.example.com.
For other DNS domains that are part of the same IdM realm, it is not required for the SRV records to be configured when the trust to AD is configured. The reason is that AD domain controllers do not use SRV records to discover KDCs but rather base the KDC discovery on name suffix routing information for the trust.
Verifying the DNS Configuration
ipconfig /flushdns command.
- Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust
- Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
The commands are expected to list all IdM servers. - Run a DNS query for the TXT record with the IdM Kerberos realm name. The obtained value is expected to match the Kerberos realm that you specified when installing IdM.
[root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com. IPA.EXAMPLE.COM
- After you execute the
ipa-adtrust-installutility, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”, run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
The commands are expected to list all IdM servers on whichipa-adtrust-installhas been executed. Note that the output is empty ifipa-adtrust-installhas not been executed on any IdM server, which is typically before establishing the very first trust relationship.
- Verify that IdM is able to resolve service records for AD
- Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
These commands are expected to return the names of AD domain controllers. - Verify that the IdM-hosted services are resolvable from the AD server
- On the AD server, set the
nslookup.exeutility to look up service records.C:\>nslookup.exe > set type=SRV
- Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
> _kerberos._udp.ipa.example.com. _kerberos._udp.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.ipa.example.com _ldap._tcp.ipa.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.comThe expected output contains the same set of IdM servers as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust. - Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name.
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"The output is expected to contain the same value as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust. - After you execute the
ipa-adtrust-installutility, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”, run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.ipa.example.com. _kerberos._udp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.dc._msdcs.ipa.example.com. _ldap._tcp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.comThe command is expected to list all IdM servers on which theipa-adtrust-installutility has been executed. Note that the output is empty ifipa-adtrust-installhas not been executed on any IdM server, which is typically before establishing the very first trust relationship.
- Verify that AD services are resolvable from the AD server
- On the AD server, set the
nslookup.exeutility to look up service records.C:\>nslookup.exe > set type=SRV
- Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
> _kerberos._udp.dc._msdcs.ad.example.com. _kerberos._udp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = addc1.ad.example.com > _ldap._tcp.dc._msdcs.ad.example.com. _ldap._tcp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = addc1.ad.example.comThe expected output contains the same set of AD servers as displayed in Verify that IdM is able to resolve service records for AD.
5.2.1.3. NetBIOS Names
Note
linux.example.com, the NetBIOS name is linux. If the domain name is example.com, the NetBIOS name is example.
5.2.1.4. Firewalls and Ports
- Open ports required for an AD trust and ports required by an IdM server in an AD trust on IdM servers and all AD domain controllers in both directions: from the IdM servers to the AD domain controllers and back.
- Open the port required by an IdM client in an AD trust on all AD domain controllers of the trusted AD forest. On the IdM clients, make sure the port is open in the outgoing direction (see Prerequisites for Installing a Client in the Linux Domain Identity, Authentication, and Policy Guide).
Table 5.2. Ports Required for an AD Trust
| Service | Port | Protocol |
|---|---|---|
| Endpoint resolution portmapper | 135 | TCP |
| NetBIOS-DGM | 138 | TCP and UDP |
| NetBIOS-SSN | 139 | TCP and UDP |
| Microsoft-DS | 445 | TCP and UDP |
| Endpoint mapper listener range | 1024-1300 | TCP |
| AD Global Catalog | 3268 | TCP |
| LDAP | 389 | TCP [a] and UDP |
[a]
The TCP port 389 is not required to be open on IdM servers for trust, but it is necessary for clients communicating with the IdM server.
| ||
Table 5.3. Ports Required by IdM Servers in a Trust
| Service | Port | Protocol | Notes |
|---|---|---|---|
| Kerberos | See Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide. | ||
| LDAP | |||
| DNS | |||
Table 5.4. Ports Required by IdM Clients in an AD Trust
| Service | Port | Protocol | Notes |
|---|---|---|---|
| Kerberos | 88 | UDP and TCP |
The port is not required if you have configured Key Distribution Center (KDC) proxy, in which case the IdM clients send Kerberos requests through the IdM servers.
|
Additional Resources
- For advice on how to open the required ports, see Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide.
5.2.1.5. IPv6 Settings
5.2.1.6. Clock Settings
5.2.1.7. Supported User Name Formats
name@domain. Active Directory supports several different kinds of name formats: username, username@DOMAIN.NAME, and DOMAIN\username.
re_expression option. The regular expression is used for IdM back ends or AD back ends and supports all the mentioned formats:
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
5.2.2. Creating Trusts
5.2.2.1. Creating a Trust from the Command Line
- Preparing the IdM server for the trust, described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”
- Creating a trust agreement, described in Section 5.2.2.1.2, “Creating a Trust Agreement”
- Verifying the Kerberos configuration, described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”
5.2.2.1.1. Preparing the IdM Server for Trust
- Install the required IdM, trust, and Samba packages:
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
- Configure the IdM server to enable trust services:
- Run the
ipa-adtrust-installutility. The utility adds DNS service records required for AD trusts. These records are created automatically if IdM was installed with an integrated DNS server.If IdM was installed without an integrated DNS server,ipa-adtrust-installprints a list of service records that must be manually added to DNS before you can continue.Important
Red Hat strongly recommends to verify the DNS configuration as described in the section called “Verifying the DNS Configuration” every time after runningipa-adtrust-install, especially if IdM or AD do not use integrated DNS servers. - The script prompts to configure the
slapi-nisplug-in, a compatibility plug-in that allows older Linux clients to work with trusted users.Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]: y
- At least one user (the IdM administrator) exists when the directory is first installed. The SID generation task can create a SID for any existing users, to support the trust environment. This is a resource-intensive task; for a high number of users, this can be run separately.
Do you want to run the ipa-sidgen task? [no]: yes
- Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
- Start the
smbdaemon and use thesmbclientutility to verify that Samba responds to Kerberos authentication from the IdM side.[root@ipaserver ~]# systemctl start smb [root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Domain=[IDM] OS=[Windows 6.1] Server=[Samba 4.2.10] Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.2.10) Domain=[IDM] OS=[Windows 6.1] Server=[Samba 4.2.10] Server Comment --------- ------- Workgroup Master --------- -------
5.2.2.1.2. Creating a Trust Agreement
ipa trust-add command:
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
ipa trust-add command sets up a one-way trust by default. To establish a two-way trust, pass the --two-way=true option. See Section 5.1.4, “One-Way and Two-Way Trusts” for details.
--external=true option to the ipa trust-add command. See Section 5.1.5, “External Trusts to Active Directory” for details.
Note
ipa trust-add command configures the server as a trust controller by default. See Section 5.1.6, “Trust Controllers and Trust Agents” for details.
--two-way=true option:
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true
Active Directory domain administrator's password:
-------------------------------------------------------
Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------------
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified5.2.2.1.3. Verifying the Kerberos Configuration
- Request a ticket for an IdM user:
[root@ipaserver ~]# kinit user
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.example.com
- Request service tickets for a service within the AD domain:
[root@ipaserver ~]# kvno -S cifs adserver.example.com
If the AD service ticket is successfully granted, there is a cross-realm ticket-granting ticket (TGT) listed with all of the other requested tickets. The TGT is namedkrbtgt/AD.DOMAIN@IPA.DOMAIN.[root@ipaserver ]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@IPA.DOMAIN Valid starting Expires Service principal 06/15/12 12:13:04 06/16/12 12:12:55 krbtgt/IPA.DOMAIN@IPA.DOMAIN 06/15/12 12:13:13 06/16/12 12:12:55 host/ipaserver.ipa.example.com@IPA.DOMAIN 06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/AD.DOMAIN@IPA.DOMAIN 06/15/12 12:14:58 06/15/12 22:14:58 cifs/adserver.ad.example.com@AD.DOMAIN
- Request a ticket for an Active Directory user:
[root@ipaserver ~]# kinit user@AD.DOMAIN
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.example.com
If the AD service ticket is successfully granted, there is a cross-realm ticket-granting ticket (TGT) listed with all of the other requested tickets. The TGT is namedkrbtgt/IPA.DOMAIN@AD.DOMAIN.[root@ipaserver ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.DOMAIN Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/ipaserver.ipa.example.com@IPA.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IPA.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00
localauth plug-in maps Kerberos principals to local SSSD user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly.
Note
5.2.2.3. Creating a Trust on an Existing IdM Instance
- Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
- Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.
- Generate SIDs for each IdM user.
Note
Do not perform this step if the SIDs were generated when theipa-adtrust-installutility was used to establish the trust.- Add a new
ipaNTSecurityIdentifierattribute, containing a SID, automatically for each entry by running theipa-sidgen-taskoperation on the back-end LDAP directory.[root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipa.example.com:389 -D "cn=directory manager" -w password dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: sidgen nsslapd-basedn: dc=ipadomain,dc=com delay: 0 adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
- After the task completes successfully, a message is recorded in the error logs that the SID generation task (
Sidgen task) finished with a status of zero (0).[root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ... [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
- Verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.
5.2.2.4. Adding a Second Trust
- Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
- Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.
5.2.2.5. Creating a Trust in the Web UI
- Open the IdM web UI:
https://ipaserver.example.com
- Open the IPA Server main tab, and select the Trusts subtab.
- In the Trusts subtab, click Add to open the new trust configuration window.
- Fill in the required information about the trust:
- Provide the AD domain name in the Domain field.
- To set up the trust as two-way, select the Two-way trust check box. To set up the trust as one-way, leave Two-way trust unselected.For more information about one-way and two-way trusts, see Section 5.1.4, “One-Way and Two-Way Trusts”.
- To establish an external trust to a domain in another forest, select the External Trust check box.For more information, see Section 5.1.5, “External Trusts to Active Directory”.
- The Establish using section defines how the trust is to be established:
- To establish the trust using the AD administrator's user name and password, select Administrative account and provide the required credentials.
- Alternatively, to establish the trust with a shared password, select Pre-shared password and provide the trust password.
- Define the ID configuration for the trust:
- The Range type option allows you to choose the ID range type. If you want IdM to automatically detect what kind of ID range to use, select Detect.
- To define the starting ID of the ID range, use the Base ID field. To define the size of the ID range, use the Range size field. If you want IdM to use default values for the ID range, do not specify these options.
For more information about ID ranges, see the section called “ID Ranges”.

Figure 5.5. Adding a Trust in the Web UI
- Click to save the new trust.
5.2.3. Post-installation Considerations for Cross-forest Trusts
5.2.3.1. Potential Behavior Issues with Active Directory Trust
5.2.3.1.1. Active Directory Users and IdM Administration
5.2.3.1.2. Authenticating Deleted Active Directory Users
5.2.3.1.3. Credential Cache Collections and Selecting Active Directory Principals
- service name
- host name
- realm name
kinit utility and then uses SSH to connect to an IdM resource, the principal is not selected for the resource ticket. an IdM principal is used because the IdM principal matches the realm name of the resource.
Administrator and the domain is ADEXAMPLE.ADREALM, the principal is Administrator@ADEXAMPLE.ADREALM.
[root@server ~]# kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: [root@server ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16
admin), then there is a separate IdM credentials cache, with an IdM default principal. That IdM default principal is selected for a host ticket if the Active Directory user uses SSH to connect to a resource.
[root@vm-197 ~]# ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: [root@vm-197 ~]# klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0Default principal: admin@EXAMPLE.COM>>>>> IdM user Valid starting Expires Service principal 27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM>>>>> host principal
5.2.3.1.4. Resolving Group SIDs
Losing Kerberos Tickets
net getlocalsid or net getdomainsid, removes any existing admin ticket from the Kerberos cache.
Note
net getlocalsid or net getdomainsid in order to use Active Directory trusts.
Cannot Verify Group Membership for Users
Cannot Display Remote Active Directory Group Memberships for an Active Directory User
Important
id utility can be used to display local group associations for Linux system users. However, id does not display Active Directory group memberships for Active Directory users, even though Samba tools do display them.
ssh utility to log into an IdM client machine as the given AD user. After the AD user logs in successfully for the first time, the id search detects and displays the AD group memberships:
[root@ipaserver ~]# id ADDOMAIN\user uid=1921801107(user@ad.example.com) gid=1921801107(user@ad.example.com) groups=1921801107(user@ad.example.com),129600004(ad_users),1921800513(domain users@ad.example.com)
5.2.3.2. Configuring Trust Agents
- Run the
ipa-adtrust-install --add-agentscommand on a trust controller. The command enters interactive configuration session and prompts you for the information required to set up the agent.For more information about the--add-agentsoption, see the ipa-adtrust-install(1) man page. - Restart the LDAP service.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.