Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

5.2. Creating Cross-forest Trusts

5.2.1. Environment and Machine Requirements

Before configuring a trust agreement, make sure that both the Active Directory and Identity Management servers, machines, and environments meet the requirements and settings described in this section.

5.2.1.1. Supported Windows Platforms

You can establish a trust relationship with Active Directory 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
The following operating systems are supported and tested for establishing a trust using the mentioned functional levels:
  • Windows Server 2012 R2
  • Windows Server 2016
Previous versions of Windows Server are not supported for establishing a trust.

5.2.1.2. DNS and Realm Settings

To establish a trust, Active Directory and Identity Management require specific DNS configuration:
Unique primary DNS domains
Each system must have its own unique primary DNS domain configured. For example:
  • ad.example.com for AD and idm.example.com for IdM
  • example.com for AD and idm.example.com for IdM
  • ad.example.com for AD and example.com for IdM

    Important

    If the IdM domain is the parent domain of the AD domain, the IdM servers must run on Red Hat Enterprise Linux 7.5 or later.
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.com for AD and idm.example.com for IdM, the Kerberos realm names are required to be AD.EXAMPLE.COM and IDM.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:
No overlap between IdM and AD DNS domains
Systems 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.

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. Red Hat recommends to always deploy IdM clients in a DNS zone different from the ones owned by Active Directory and access IdM clients through their IdM host names.
You can acquire a list of the required SRV records specific to your system setup by running the $ ipa dns-update-system-records --dry-run command.
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

Before configuring trust, verify that the Identity Management and Active Directory servers can resolve themselves and also each other.
If running the commands described below does not display the expected results, inspect the DNS configuration on the host where the commands were executed. If the host configuration seems correct, make sure that DNS delegations from the parent to child domains are set up correctly.
Note that AD caches the results of DNS lookups, and changes you make in DNS are therefore sometimes not visible immediately. You can delete the current cache by running the ipconfig /flushdns command.
Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust
  1. 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.
  2. 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
  3. After you execute the ipa-adtrust-install utility, 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 which ipa-adtrust-install has been executed. Note that the output is empty if ipa-adtrust-install has 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
  1. On the AD server, set the nslookup.exe utility to look up service records. 
    C:\>nslookup.exe
> set type=SRV
  2. 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.com
    The 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.
  3. 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.
  4. After you execute the ipa-adtrust-install utility, 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.com
    The command is expected to list all IdM servers on which the ipa-adtrust-install utility has been executed. Note that the output is empty if ipa-adtrust-install has 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
  1. On the AD server, set the nslookup.exe utility to look up service records. 
    C:\>nslookup.exe
> set type=SRV
  2. 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.com
    The 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

The NetBIOS name is critical for identifying the Active Directory (AD) domain and, if IdM has a trust configured with AD, for identifying the IdM domain and services. As a consequence, you must use a different NetBIOS name for the IdM domain than the NetBIOS names used in the AD domains to which you want to establish the forest trust.
The NetBIOS name of an Active Directory or IdM domain is usually the far-left component of the corresponding DNS domain. For example, if the DNS domain is ad.example.com, the NetBIOS name is typically AD.

Note

The maximum length of a NetBIOS name is 15 characters.

5.2.1.4. Firewalls and Ports

To enable communication between AD domain controllers and IdM servers, make sure you meet the following port requirements:

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
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 libkrb5 library uses UDP and falls-back to the TCP protocol if the data sent from the Kerberos Distribution Center (KDC) is too large. Active Directory attaches a Privilege Attribute Certificate (PAC) to the Kerberos ticket, which increases the size and requires in most cases to use the TCP protocol. To avoid the fall-back and resending the request, by default, SSSD in Red Hat Enterprise Linux 7.4 and later uses TCP for user authentication. To configure the size before libkrb5 uses TCP, set the udp_preference_limit in the /etc/krb.5.conf file. For details, see the krb5.conf(5) man page.

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

The IdM system must have the IPv6 protocol enabled in the kernel. If IPv6 is disabled, then the CLDAP plug-in used by the IdM services fails to initialize.

5.2.1.6. Clock Settings

Both the Active Directory server and the IdM server must have their clocks in sync.

5.2.1.7. Creating a Conditional Forwarder for the IdM Domain in AD

Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server:
  1. On a Windows AD domain controller, open the Active Directory (AD) DNS console.
  2. Right-click Conditional Forwarders, select New Conditional Forwarder.
  3. Enter the IdM DNS domain name and the IP address of the IdM DNS server
  4. Select Store this conditional forwarder in Active Directory, and replicate it as follows, and select the replication setting that matches your environment.
  5. Click OK.
  6. To verify that the AD domain controller (DC) can resolve DNS entries from the IdM domain, open a command prompt and enter: 
    C:\> nslookup server.idm.example.com
    If the command returns the IP address of the IdM server, the conditional forwarder is working correctly.

5.2.1.8. Creating a Forward Zone for the AD Domain in IdM

Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server:
  1. On the IdM server, create a forward zone entry for the AD DNS domain. For further details about creating a DNS forward zone in IdM see the Configuring Forward Zones section in the Linux Domain Identity, Authentication, and Policy Guide.
  2. If the AD DNS server does not support DNSSEC, disable DNSSEC validation on the IdM server:
    1. Edit the /etc/named.conf file and set the dnssec-validation parameter to no: 
      dnssec-validation no;
    2. Restart the named-pkcs11 service: 
      # systemctl restart named-pkcs11
  3. To verify that the IdM server can resolve DNS entries from the AD domain, enter: 
    # host server.ad.example.com
    If the command returns the IP address of the AD DC, the forward zone is working correctly.

5.2.1.9. Supported User Name Formats

IdM performs user name mapping in the local SSSD client. The default output user name format for users from trusted domains supported by SSSD is user_name@domain. Active Directory supports several different kinds of name formats: user_name, user_name@DOMAIN_NAME, and DOMAIN_NAME\user_name.
Users can use either only their user name (user_name) or their fully-qualified user name (user_name@domain_name), for example, to authenticate to the system.

Warning

Preferably, use the fully-qualified user name to avoid conflicts if the same user name exists in multiple domains.
If a user specifies only the user name with out the domain, SSSD searches the account in all domains configured in the /etc/sssd/sssd.conf file and in trusted domains. If you configured a domain resolution order as described in Section 8.5.3, “Configuring the Domain Resolution Order on an IdM Client”, SSSD searches for the user in the defined order. In any case, SSSD uses the first entry found. This can lead to problems or confusion if the same user name exists in multiple domains and the first entry found is not the expected one.
By default, SSSD displays user names always in the fully-qualified format. For details about changing the format, see Section 5.5, “Changing the Format of User Names Displayed by SSSD”.
To identify the user name and the domain to which the user name belongs, SSSD uses a regular expression defined in the 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

The following sections describe creating trusts in various configuration scenarios. Section 5.2.2.1, “Creating a Trust from the Command Line” contains the full procedure for configuring a trust from the command line. The other sections describe the steps which are different from this basic configuration scenario and reference the basic procedure for all other steps.

Note

If you set up a replica in an existing trust environment, the replica is not automatically configured as a trust controller. To configure the replica as an additional trust controller, follow the procedures in this section.
After creating a trust, see Section 5.2.3, “Post-installation Considerations for Cross-forest Trusts”.

5.2.2.1. Creating a Trust from the Command Line

Creating a trust relationship between the IdM and Active Directory Kerberos realms involves the following steps:
  1. Preparing the IdM server for the trust, described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”
  2. Creating a trust agreement, described in Section 5.2.2.1.2, “Creating a Trust Agreement”
  3. 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
To set up the IdM server for a trust relationship with AD, follow these steps:
  1. Install the required IdM, trust, and Samba packages: 
    [root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Configure the IdM server to enable trust services. You can skip this step if you installed the server with the ipa-replica-install --setup-adtrust command.
    1. Run the ipa-adtrust-install utility: 
      [root@ipaserver ]# ipa-adtrust-install
      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-install prints a list of service records that you must manually add to the 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 running ipa-adtrust-install, especially if IdM or AD do not use integrated DNS servers.
    2. The script prompts to configure the slapi-nis plug-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
    3. 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
  3. Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
  4. Start the smb service: 
    [root@ipaserver ~]# systemctl start smb
  5. Optionally, configure that the smb service starts automatically when the system boots: 
    [root@ipaserver ~]# systemctl enable smb
  6. Optionally, use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side. 
    [root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k
lp_load_ex: changing to config backend registry

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       IPC Service (Samba 4.9.1)
Reconnecting with SMB1 for workgroup listing.

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------
5.2.2.1.2. Creating a Trust Agreement
Create a trust agreement for the Active Directory domain and the IdM domain by using the ipa trust-add command: 
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
The ipa trust-add command sets up a one-way trust by default. It is not possible to establish a two-way trust in RHEL 7.
To establish an external trust, pass the --external=true option to the ipa trust-add command. See Section 5.1.5, “External Trusts to Active Directory” for details.

Note

The 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.
The following example establishes a two-way trust by using the --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 verified
5.2.2.1.3. Verifying the Kerberos Configuration
To verify the Kerberos configuration, test if it is possible to obtain a ticket for an IdM user and if the IdM user can request service tickets.
To verify a two-way trust:
  1. Request a ticket for an IdM user: 
    [root@ipaserver ~]# kinit user
  2. Request service tickets for a service within the IdM domain: 
    [root@ipaserver ~]# kvno -S host ipaserver.example.com
  3. 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 named krbtgt/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
To verify a one-way trust from the IdM side:
  1. Request a ticket for an Active Directory user: 
    [root@ipaserver ~]# kinit user@AD.DOMAIN
  2. 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 named krbtgt/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
The 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

For more information about the plug-in, see Section 5.3.7.2, “Using SSH Without Passwords”.

5.2.2.2. Creating a Trust Using a Shared Secret

A shared secret is a password that is known to trusted peers and can be used by other domains to join the trust. The shared secret can configure both one-way and two-way trusts within Active Directory (AD). In AD, the shared secret is stored as a trusted domain object (TDO) within the trust configuration.
IdM supports creating a one-way or two-way trust using a shared secret instead of the AD administrator credentials. Setting up such a trust requires the administrator to create the shared secret in AD and manually validate the trust on the AD side.
5.2.2.2.1. Creating a Two-Way Trust Using a Shared Secret
To create a two-way trust with a shared secret with a Microsoft Windows Server 2012, 2012 R2, or 2016:
  1. Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
  2. If the IdM and AD hosts use a DNS server that cannot resolve both domains, set up forwarding for the DNS zones:
    1. Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server. For details, see Section 5.2.1.7, “Creating a Conditional Forwarder for the IdM Domain in AD”.
    2. Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server. For details, see Section 5.2.1.8, “Creating a Forward Zone for the AD Domain in IdM”.
  3. Configure a trust in the Active Directory Domains and Trusts console. In particular:
    • Create a new trust.
    • Give the trust the IdM domain name, for example idm.example.com.
    • Specify that this is a forest type of trust.
    • Specify that this is a two-way type of trust.
    • Specify that this is a forest-wide authentication.
    • Set the trust password.

      Note

      The same password must be used when configuring the trust in IdM.
    When asked to confirm the incoming trust, select No.
  4. Create a trust agreement, as described in Section 5.2.2.1.2, “Creating 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. For example: 
    [root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --trust-secret --two-way=True
Shared secret for the trust:
-------------------------------------------------------
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: Trusting forest
  Trust type: Active Directory domain
  Trust status: Waiting for confirmation by remote side
  5. Retrieve the list of domains: 
    [root@ipaserver ~]# ipa trust-fetch-domains ad_domain
  6. On the IdM server, verify that the trust relationship is established by using the ipa trust-show command. 
    [root@ipaserver ~]# ipa trust-show ad.example.com

  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  7. Optionally, search for the trusted domain: 
    [root@ipaserver ~]# ipa trustdomain-find ad.example.com
Domain name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Domain enabled: True
  8. Verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.
5.2.2.2.2. Creating a One-Way Trust Using a Shared Secret
To create a one-way trust using a shared secret with a Microsoft Windows Server 2012, 2012 R2 or 2016:
  1. Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
  2. If the IdM and AD hosts use a DNS server that cannot resolve both domains, set up forwarding for the DNS zones:
    1. Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server. For details, see Section 5.2.1.7, “Creating a Conditional Forwarder for the IdM Domain in AD”.
    2. Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server. For details, see Section 5.2.1.8, “Creating a Forward Zone for the AD Domain in IdM”.
  3. Configure a trust in the Active Directory Domains and Trusts console:
    1. Right click to the domain name, and select Properties.
    2. On the Trusts tab, click New Trust.
    3. Enter the IdM domain name, and click Next.
    4. Select Forest trust, and click Next.
    5. Select One-way: incoming, and click Next.
    6. Select This domain only, and click Next.
    7. Enter a shared secret (trust password), and click Next.
    8. Verify the settings, and click Next.
    9. When the system asks if you want to confirm the incoming trust, select No, do not confirm the incoming trust, and click Next.
    10. Click Finish.
  4. Create a trust agreement: 
    [root@ipaserver ~]# ipa trust-add --type=ad --trust-secret ad.example.com
Shared secret for the trust: 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-1762709870-351891212-3141221786
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Waiting for confirmation by remote side
    Enter the shared secret you set in the AD Domains and Trusts console.
  5. Validate the trust in the Active Directory Domains and Trusts console:
    1. Right click to the domain name, and select Properties.
    2. On the Trusts tab, select the domain in the Domains that trust this domain (incoming trusts) pane, and click Properties.
    3. Click the Validate button.
    4. Select Yes, validate the incoming trust, and enter the credentials of the IdM admin user.
  6. Update the list of trusted domains: 
    [root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
----------------------------------------------------------------------------------------
List of trust domains successfully refreshed. Use trustdomain-find command to list them.
----------------------------------------------------------------------------------------
----------------------------
Number of entries returned 0
----------------------------
  7. List the trusted domains: 
    [root@ipaserver ~]# ipa trustdomain-find ad.example.com
  Domain name: ad.example.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786
  Domain enabled: True
----------------------------
Number of entries returned 1
----------------------------
  8. Optionally, verify that the IdM server can retrieve user information from AD domain: 
    [root@ipaserver ~]# getent passwd administrator@ad.example.com
administrator@ad.example.com:*:610600500:610600500:Administrator:/home/ad.example.com/administrator:

5.2.2.3. Verifying the ID Mapping

To verify the ID mapping:
  1. Run the following command on a Windows Active Directory domain controller (DC) to list the highest ID: 
    C:\> dcdiag /v /test:ridmanager /s:ad.example.com
...
Available RID Pool for the Domain is 1600 to 1073741823
...
  2. List the ID ranges on an IdM server: 
    [root@ipaserver ~]# ipa idrange-find
----------------
1 range matched
----------------
  Range name: AD.EXAMPLE.COM_id_range
  First Posix ID of the range: 610600000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912
  Range type: Active Directory domain range
----------------------------
Number of entries returned 1
----------------------------
    You require the first POSIX ID value in a later step.
  3. On the Active Directory DC, display the security identifier (SID) or a user. For example, to display the SID of administrator: 
    C:\> wmic useraccount where name="administrator" get sid
S-1-5-21-796215754-1239681026-23416912-500
    The last part of the SID is the relative identifier (RID). You require the user's RID in the next step.

    Note

    If the RID is higher than the default ID range (200000), use the ipa idrange-mod command to extend the range. For example: 
    # ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
  4. Display the user ID of the same user on the IdM server: 
    [root@ipaserver ~]# id ad\\administrator
uid=610600500(administrator@ad.example.com)...
  5. If you add the first POSIX ID value (610600000) to the RID (500), it must match the user ID displayed on the IdM server (610600500).

5.2.2.4. Creating a Trust on an Existing IdM Instance

When configuring a trust for an existing IdM instance, certain settings for the IdM server and entries within its domain are already configured. However, you must set the DNS configuration for the Active Directory domain and assign Active Directory SIDs to all existing IdM users and groups.
  1. Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
  2. Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.
  3. Generate SIDs for each IdM user.

    Note

    Do not perform this step if the SIDs were generated when the ipa-adtrust-install utility was used to establish the trust.
    1. Add a new ipaNTSecurityIdentifier attribute, containing a SID, automatically for each entry by running the ipa-sidgen-task operation 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"
    2. 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].
  4. Verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.

5.2.2.5. Adding a Second Trust

When adding a trust on an IdM server that already has one or more trust agreements configured, certain general IdM trust settings, such as installing the trust-related packages or configuring SIDs, is no longer required. To add an additional trust, you only must configure DNS and establish a trust agreement.
  1. Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
  2. Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.

5.2.2.6. Creating a Trust in the Web UI

Before creating a trust in the web UI, prepare the IdM server for the trust. This trust configuration is easiest to perform from the command line, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
Once the initial configuration is set, a trust agreement can be added in the IdM web UI:
  1. Open the IdM web UI: 
    https://ipaserver.example.com
  2. Open the IPA Server main tab, and select the Trusts subtab.
  3. In the Trusts subtab, click Add to open the new trust configuration window.
  4. Fill in the required information about the trust:
    1. Provide the AD domain name in the Domain field.
    2. 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”.
    3. 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”.
    4. 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.
    5. 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”.
    Adding a Trust in the Web UI

    Figure 5.5. Adding a Trust in the Web UI

  5. Click Add to save the new trust.
After this, verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.

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
Currently, Active Directory (AD) users and administrators can only see their self-service page after logging into the IdM Web UI. AD administrators cannot access the administrator's view of IdM Web UI. For details, see the Authenticating to the IdM Web UI as an AD User section in the Linux Domain Identity, Authentication, and Policy Guide.
Additionally, AD users currently cannot manage their own ID overrides. Only IdM users can add and manage ID overrides.
5.2.3.1.2. Authenticating Deleted Active Directory Users
By default, every IdM client uses the SSSD service to cache user identities and credentials. If the IdM or AD back-end provider is temporarily unavailable, SSSD enables the local system to reference identities for users who have already logged in successfully once.
Because SSSD maintains a list of users locally, changes that are made on the back end might not be immediately visible to clients that run SSSD offline. On such clients, users who have previously logged into IdM resources and whose hashed passwords are stored in the SSSD cache are able to log in again even if their user accounts have been deleted in AD.
If the above conditions are met, the user identity is cached in SSSD, and the AD user is able to log into IdM resources even if the user account is deleted AD. This problem will persist until SSSD becomes online and is able to verify AD user logon against AD domain controllers.
If the client system runs SSSD online, the password provided by the user is validated by an AD domain controller. This ensures that deleted AD users are not allowed to log in.
5.2.3.1.3. Credential Cache Collections and Selecting Active Directory Principals
The Kerberos credentials cache attempts to match a client principal to a server principal based on the following identifiers in this order:
  1. service name
  2. host name
  3. realm name
When the client and server mapping is based on the host name or real name and credential cache collections are used, unexpected behavior can occur in binding as an AD user. This is because the realm name of the Active Directory user is different than the realm name of the IdM system.
If an AD user obtains a ticket using the 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.
For example, if the AD user is 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
This is set as the default principal in the Active Directory ticket cache. However, if any IdM user also has a Kerberos ticket (such as 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:0
Default 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.COM
27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM >>>>> host principal
This is because the realm name of the IdM principal matches the realm of the IdM resource.
5.2.3.1.4. Resolving Group SIDs

Losing Kerberos Tickets

Running a command to obtain a SID from the Samba service, such as net getlocalsid or net getdomainsid, removes any existing admin ticket from the Kerberos cache.

Note

You are not required to run commands such as net getlocalsid or net getdomainsid in order to use Active Directory trusts.

Cannot Verify Group Membership for Users

It is not possible to verify that a specific trusted user is associated with a specific IdM group, external or POSIX.

Cannot Display Remote Active Directory Group Memberships for an Active Directory User

Important

Note that this problem no longer occurs if the IdM server and client run on Red Hat Enterprise Linux 7.1 or later.
The 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.
To work around this, you can use the 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

After you set up a new replica in a trust environment, the replica does not automatically have the AD trust agent role installed. To configure the replica as a trust agent:
  1. On an existing trust controller, run the ipa-adtrust-install --add-agents command: 
    [root@existing_trust_controller]# ipa-adtrust-install --add-agents
    The command starts an interactive configuration session and prompts you for the information required to set up the agent.
    For further information about the --add-agents option, see the ipa-adtrust-install(1) man page.
  2. On the new replica:
    1. Restart the IdM service: 
      [root@new_trust_controller]# ipactl restart
    2. Remove all entries from the SSSD cache: 
      [root@new_trust_controller]# sssctl cache-remove

      Note

      To use the sssctl command, the sssd-tools package must be installed.
    3. Optionally, verify that the replica has the AD trust agent role installed: 
      [root@new_trust_controller]# ipa server-show new_replica.idm.example.com
...
Enabled server roles: CA server, NTP server, AD trust agent