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

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.com for IdM and ad.example.com for 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.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
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-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 AD domain and, if the IdM domain is within a subdomain of Active Directory DNS, for identifying the IdM domain and services. The IdM domain and Active Directory domain must have different NetBIOS names.

Note

The NetBIOS name is usually the far-left component of the domain name. For example, if the domain is linux.example.com, the NetBIOS name is linux. If the domain name is example.com, the NetBIOS name is example.
The maximum length of the 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 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

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. Supported User Name Formats

IdM performs user name mapping in the local SSSD client. The default user name format supported by SSSD is name@domain. Active Directory supports several different kinds of name formats: username, username@DOMAIN.NAME, and DOMAIN\username.
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.
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:
    1. Run the ipa-adtrust-install utility. 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 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 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 daemon and use the smbclient utility 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
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. 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.
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.1, “Using SSH Without Passwords”.

5.2.2.2. Creating a Two-Way Trust with 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 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 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.

Note

The shared secret can only be used to create a two-way trust. To establish a one-way trust, use administrator credentials.
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. 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.
  3. 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
  4. 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

    Note

    Before running ipa trust-show, you might be required to run the ipa trust-fetch-domains ad_domain command to ensure you obtain a Common Internet File System (CIFS) ticket-granting ticket.
  5. Verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.

5.2.2.3. 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.4. 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.5. 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 corresponding section of 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

To configure a normal IdM master to serve as a trust agent:
  1. Run the ipa-adtrust-install --add-agents command 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-agents option, see the ipa-adtrust-install(1) man page.
  2. Restart the LDAP service.
For more information about trust agents, see Section 5.1.6, “Trust Controllers and Trust Agents”.