Chapter 10. Troubleshooting setting up a cross-forest trust
Learn more about troubleshooting the process of configuring a cross-forest trust between your Identity Management (IdM) environment and an Active Directory (AD) forest.
10.1. Sequence of events when establishing a cross-forest trust with AD
When you use the ipa trust-add
command to establish a cross-forest trust with an Active Directory (AD) Domain Controller (DC), the command operates on behalf of the user who ran the command and performs the following actions on the IdM server. If you have trouble establishing a cross-forest trust, you can use this list to help narrow down and troubleshoot your issue.
Part 1: The command verifies settings and inputs
- Verify that the IdM server has the Trust Controller role.
-
Validate the options passed to the
ipa trust-add
command. -
Validate the ID range associated with a trusted forest root domain. If you did not specify the ID range type and properties as options to the
ipa trust-add
command, they are discovered from Active Directory.
Part 2: The command attempts to establish a trust to an Active Directory domain
- Create a separate trust object for each trust direction. Each of the objects get created on both sides (IdM and AD). If you are establishing a one-way trust, only one object is created on each side.
The IdM server uses the Samba suite to handle domain controller capabilities for Active Directory and creates a trust object on the target AD PDC:
-
The IdM server establishes a secure connection to the
IPC$
share on the target DC. Since RHEL 8.4, the connection requires at least the SMB3 protocol with Windows Server 2012 and above to ensure the connection is sufficiently secure with AES-based encryption used for the session. -
The IdM server queries for the presence of the trusted domain object (TDO) using an
LSA QueryTrustedDomainInfoByName
call. If the TDO is already present, remove it with an
LSA DeleteTrustedDomain
call.NoteThis call fails if the AD user account used to establish the trust does not have full Enterprise Admin (EA) or Domain Admin (DA) privileges for the forest root, such as members of the Incoming Forest Trust Builders group. If the old TDO is not automatically removed, an AD Administrator must manually remove it from AD.
-
The IdM server creates a new TDO with an
LSA CreateTrustedDomainEx2
call. The TDO credentials are randomly generated using a Samba-provided password generator with 128 random characters. The new TDO is then modified with an
LSA SetInformationTrustedDomain
call to make sure encryption types supported by the trust are set properly:-
The
RC4_HMAC_MD5
encryption type is enabled, even if there are no RC4 keys in use, due to how Active Directory is designed. AES128_CTS_HMAC_SHA1_96
andAES256_CTS_HMAC_SHA1_96
encryption types are enabled.NoteBy default, RHEL 9 does not allow SHA-1 encryption, which is an algorithm that AD requires. Make sure you have enabled the
AD-SUPPORT
system-wide cryptographic subpolicy to allow SHA-1 encryption in your RHEL 9 IdM servers for communication with AD Domain Controllers. See <link TBA>.
-
The
-
The IdM server establishes a secure connection to the
-
For a forest trust, verify that in-forest domains can be reached transitively with an
LSA SetInformationTrustedDomain
call. Add trust topology information about the other forest (IdM in the case of communicating with AD, AD in the case of communicating with IdM) using an
LSA RSetForestTrustInformation
call.NoteThis step might cause a conflict for one of three reasons:
-
A SID namespace conflict, reported as an
LSA_SID_DISABLED_CONFLICT
error. This conflict cannot be resolved. -
A NetBIOS namespace conflict, reported as an
LSA_NB_DISABLED_CONFLICT
error. This conflict cannot be resolved. -
A DNS namespace conflict with a top level name (TLN), reported as an
LSA_TLN_DISABLED_CONFLICT
error. The IdM server can automatically resolve a TLN conflict if it is caused by another forest.
To resolve a TLN conflict, the IdM server performs the following steps:
- Retrieve forest trust information for the conflicting forest.
- Add an exclusion entry for the IdM DNS namespace to the AD forest.
- Set forest trust information for the forest we conflict on.
- Re-try establishing the trust to the original forest.
The IdM server can only resolve these conflicts if you authenticated the
ipa trust-add
command with the privileges of an AD administrator that can change forest trusts. If you do not have access to those privileges, the administrator of the original forest must manually perform the steps above in the Active Directory Domains and Trusts section of the Windows UI.-
A SID namespace conflict, reported as an
- If it does not exist, create the ID range for the trusted domain.
- For a forest trust, query Active Directory domain controllers from the forest root for details about the forest topology. The IdM server uses this information to create additional ID ranges for any additional domains from the trusted forest.
Additional resources
- Trust controllers and trust agents
- Overview Documents (Microsoft)
- Technical Documents (Microsoft)
- Privileged Accounts and Groups in Active Directory (Microsoft)
10.2. Checklist of prerequisites for establishing an AD trust
You can use the following checklist to review the prerequisites for creating a trust with an AD domain.
Component | Configuration | Additional details |
---|---|---|
Product versions | Your Active Directory domain is using a supported version of Windows Server. | |
AD Administrator privileges | The Active Directory administration account must be a member of one of the following groups:
| |
Networking | IPv6 support is enabled in the Linux kernel for all IdM servers. | |
Date and time | Verify the date and time settings on both servers match. | |
Encryption types | The following AD accounts have AES encryption keys:
If you have recently enabled AES encryption in AD, generate new AES keys with the following steps:
| |
Firewall | You have opened all necessary ports on IdM servers and AD Domain Controllers for bidirectional communication. | |
DNS |
| |
Topology | Ensure you are attempting to establish a trust with an IdM server you have configured as a trust controller. |
10.3. Gathering debug logs of an attempt to establish an AD trust
If you are experiencing issues with establishing a trust between an IdM environment and AD domain, use the following steps to enable detailed error logging so you can gather logs of an attempt to establish a trust. You can review these logs to help with your troubleshooting efforts, or you can provide them in a Red Hat Technical Support case.
Prerequisites
- You need root permissions to restart IdM services.
Procedure
To enable debugging for the IdM server, create the file
/etc/ipa/server.conf
with the following contents.[global] debug=True
Restart the
httpd
service to load the debugging configuration.[root@trust_controller ~]# systemctl restart httpd
Stop the
smb
andwinbind
services.[root@trust_controller ~]# systemctl stop smb winbind
Set the debugging log level for the
smb
andwinbind
services.[root@trust_controller ~]# net conf setparm global 'log level' 100
To enable debug logging for Samba client code used by the IdM framework, edit the
/usr/share/ipa/smb.conf.empty
configuration file to have the following contents.[global] log level = 100
Remove previous Samba logs.
[root@trust_controller ~]# rm /var/log/samba/log.*
Start the
smb
andwinbind
services.[root@trust_controller ~]# systemctl start smb winbind
Print a timestamp as you attempt to establish a trust with verbose mode enabled.
[root@trust_controller ~]# date; ipa -vvv trust-add --type=ad ad.example.com
Review the following error log files for information about the failed request:
-
/var/log/httpd/error_log
-
/var/log/samba/log.*
-
Disable debugging.
[root@trust_controller ~]# mv /etc/ipa/server.conf /etc/ipa/server.conf.backup [root@trust_controller ~]# systemctl restart httpd [root@trust_controller ~]# systemctl stop smb winbind [root@trust_controller ~]# net conf setparm global 'log level' 0 [root@trust_controller ~]# mv /usr/share/ipa/smb.conf.empty /usr/share/ipa/smb.conf.empty.backup [root@trust_controller ~]# systemctl start smb winbind
Optional: If you are unable to determine the cause of the authentication issue:
Collect and archive the log files you recently generated.
[root@trust_controller ~]# tar -cvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*
- Open a Red Hat Technical Support case and provide the timestamp and debug logs from the attempt.
Additional resources