Menu Close

Chapter 7. Planning a cross-forest trust between IdM and AD

Active Directory (AD) and Identity Management (IdM) are two alternative environments managing a variety of core services, such as Kerberos, LDAP, DNS, and certificate services. A cross-forest trust relationship transparently integrates these two diverse environments by enabling all core services to interact seamlessly. The following sections provide advice on how to plan and design a cross-forest trust deployment.

7.1. Cross-forest trusts between IdM and AD

In a pure Active Directory (AD) environment, a cross-forest trust connects two separate AD forest root domains. When you create a cross-forest trust between AD and IdM, the IdM domain presents itself to AD as a separate forest with a single domain. A trust relationship is then established between the AD forest root domain and the IdM domain. As a result, users from the AD forest can access the resources in the IdM domain.

IdM can establish a trust with one AD forest or multiple unrelated forests.

Note

Two separate Kerberos realms can be connected in a cross-realm trust. However, a Kerberos realm only concerns authentication, not other services and protocols involved in identity and authorization operations. Therefore, establishing a Kerberos cross-realm trust is not enough to enable users from one realm to access resources in another realm.

An external trust to an AD domain

An external trust is a trust relationship between IdM and an Active Directory domain. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to any domain within a forest.

7.2. Trust controllers and trust agents

Identity Management (IdM) provides the following types of IdM servers that support trust to Active Directory (AD):

Trust controllers

IdM servers that can perform identity lookups against AD domain controllers. They also run the Samba suite so they can establish trust with AD. AD domain controllers contact trust controllers when establishing and verifying the trust to AD. AD-enrolled machines communicate with IdM trust controllers for Kerberos authentication requests.

The first trust controller is created when you configure the trust. If you have multiple domain controllers across different geographic locations, use the ipa-adtrust-install command to designate RHEL IdM servers as trust controllers in these locations.

Trust controllers run more network-facing services than trust agents, and thus present a greater attack surface for potential intruders.

Trust agents
IdM servers that can resolve identity lookups from RHEL IdM clients against AD domain controllers. Unlike trust controllers, trust agents cannot process Kerberos authentication requests.

In addition to trust agents and controllers, the IdM domain can also include standard IdM servers. However, these servers do not communicate with AD. Therefore, clients that communicate with these standard servers cannot resolve AD users and groups or authenticate and authorize AD users.

Table 7.1. Comparing the capabilities supported by trust controllers and trust agents

CapabilityTrust agentTrust controller

Resolve AD users and groups

Yes

Yes

Enroll IdM clients that run services accessible by users from trusted AD forests

Yes

Yes

Add, modify, or remove trust agreements

No

Yes

Assign the trust agent role to an IdM server

No

Yes

When planning the deployment of trust controllers and trust agents, consider these guidelines:

  • Configure at least two trust controllers per IdM deployment.
  • Configure at least two trust controllers in each data center.

If you ever want to create additional trust controllers or if an existing trust controller fails, create a new trust controller by promoting a trust agent or a standard server. To do this, use the ipa-adtrust-install utility on the IdM server.

Important

You cannot downgrade an existing trust controller to a trust agent.

7.3. One-way trusts and two-way trusts

In one way trusts, Identity Management (IdM) trusts Active Directory (AD) but AD does not trust IdM. AD users can access resources in the IdM domain but users from IdM cannot access resources within the AD domain. The IdM server connects to AD using a special account, and reads identity information that is then delivered to IdM clients over LDAP.

In two way trusts, IdM users can authenticate to AD, and AD users can authenticate to IdM. AD users can authenticate to and access resources in the IdM domain as in the one way trust case. IdM users can authenticate but cannot access most of the resources in AD. They can only access those Kerberized services in AD forests that do not require any access control check.

To be able to grant access to the AD resources, IdM needs to implement the Global Catalog service. This service does not yet exist in the current version of the IdM server. Because of that, a two-way trust between IdM and AD is nearly functionally equivalent to a one-way trust between IdM and AD.

7.4. Kerberos FAST for trusted domains

Kerberos Flexible Authentication Secure Tunneling (FAST) is also called the Kerberos armoring in Active Directory (AD) environment. Kerberos FAST provides an additional security layer for the Kerberos communication between the clients and the Key Distribution Center (KDC). In IdM, the KDCs are running on the IdM servers and FAST is enabled by default. The Two-Factor Authentication (2FA) in IdM also requires enabling FAST.

In AD, Kerberos armoring is disabled by default on the AD Domain Controllers (DC). You can enable it on the Domain Controllers with the group policy settings below:

  • Computer Configuration,
  • Policies,
  • Administrative Templates,
  • System,
  • KDC,
  • KDC support for claims, compound authentication, and Kerberos armoring.

The policy setting allows the following options:

  • "Not supported",
  • "Supported",
  • "Always provide claims",
  • "Fail unarmored authentication requests".

Kerberos FAST is implemented in the Kerberos client libraries on the IdM clients. You can configure IdM clients either to use FAST for all trusted domains which advertise FAST or to not use Kerberos FAST at all. If you enable Kerberos armoring in the trusted AD forest the IdM client uses Kerberos FAST by default. FAST establishes a secure tunneling with the help of a cryptographic key. In order to protect a connection to the domain controllers of a trusted domain, Kerberos FAST must get a cross-realm Ticket Granting Tickets (TGTs) from the trusted domain because that keys are valid only inside Kerberos realm. Kerberos FAST uses the Kerberos hosts keys of the IdM client to request the cross-realm TGT with the help of the IdM servers. That only works when the AD forest trusts the IdM domain which means a two-way trust is required.

If AD policies require the enforcing Kerberos FAST use, you need to establish a two-way trust between IdM domain and AD forest. You must plan this before the connection is established because both IdM and AD sides must have records about direction and the type of trust.

If you already establish a one-way trust, the next time you run ipa trust-add …​ --two-way=true command removes existing trust agreement and recreates it. This requires use of the administrative credentials. Since IdM attempts to remove existing trust agreement from the AD side, that requires administrator permissions for AD access. If you establish the original trust by using a shared secret rather than an AD administrative account, it recreates the trust as a two-way and changes trusted domain objects on the IdM side only. Windows administrators must repeat the same procedure using Windows UI by choosing a bi-directional trust and use the same shared secret to recreate the trust.

If using a two-way trust is not possible, you must disable Kerberos FAST on all IdM clients. The users from the trusted AD forest can authenticate with a password or direct Smart Card. To do so, add the following setting to the sssd.conf file in the [domain] section:

krb5_use_fast = never

Note, you do not need to use this option when the authentication is based on ssh-keys, GSSAPI authentication or ssh with Smart Cards from remote Windows clients. These methodes do not use Kerberos FAST because the IdM client does not have to communicate with a DC. Additionally, after disabling FAST on the IdM client, the two-factor authentication IdM feature is also unavailable.

7.5. POSIX and ID mapping ID range types for AD users

Identity Management (IdM) enforces access control rules based on the POSIX User ID (UID) and Group ID (GID) of a user. Active Directory (AD) users, however, are identified by Security Identifiers (SIDs). AD administrators can configure AD to store POSIX attributes for your AD users and groups, such as uidNumber, gidNumber, unixHomeDirectory, or loginShell.

You can configure a cross-forest trust to reference this information by establishing a trust with the ipa-ad-trust-posix ID range:

[server ~]# ipa trust-add --type=ad ad.example.com --admin administrator --password  --range-type=ipa-ad-trust-posix

If you do not store POSIX attributes in AD, the System Security Services Daemon (SSSD) can consistently map a unique UID based on a user’s SID in a process called ID mapping. You can explicitly choose this behavior by creating a trust with the ipa-ad-trust ID range:

[server ~]# ipa trust-add --type=ad ad.example.com --admin administrator --password  --range-type=ipa-ad-trust
Warning

If you do not specify an ID Range type when creating a trust, IdM attempts to automatically select the appropriate range type by requesting details from AD domain controllers in the forest root domain. If IdM does not detect any POSIX attributes, the trust installation script selects the Active Directory domain ID range.

If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the Active Directory domain with POSIX attributes ID range and assumes that UIDs and GIDs are correctly defined in AD. If POSIX attributes are not correctly set in AD, you will not be able to resolve AD users.

For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script may not detect the POSIX attributes defined in the child AD domain. In this case, Red Hat recommends that you explicitly choose the POSIX ID range type when establishing the trust.

7.6. Options for automatically mapping private groups for AD users: POSIX trusts

Each user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG.

If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range.

By default, the auto_private_groups option is set to false for ipa-ad-trust-posix ID ranges used in a POSIX trust. With this configuration, SSSD retrieves the uidNumber and gidNumber from each AD user entry.

auto_private_groups = false

SSSD assigns the uidNumber value to the user’s UID, the gidNumber to the user’s GID. A group with that GID must exist in AD, or you will not be able to resolve that user. The following table demonstrates whether you will be able to resolve AD users, depending on different AD configurations.

Table 7.2. SSSD behavior when the auto_private_groups variable is set to false for a POSIX ID range

User configuration in ADOutput of id username

AD user entry has:

  • uidNumber = 4000
  • gidNumber is not defined
  • No group in AD with gidNumber = 4000.

SSSD cannot resolve the user.

AD user entry has:

  • uidNumber = 4000
  • gidNumber = 4000
  • No group in AD with gidNumber = 4000.

SSSD cannot resolve the user.

AD user entry has:

  • uidNumber = 4000
  • gidNumber = 4000
  • AD has a group with gidNumber = 4000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(adgroup@ad-domain.com) groups=4000(adgroup@ad-domain.com), …​

If an AD user does not have a primary group configured in AD, or its gidNumber does not correspond to an existing group, the IdM server is unable to resolve that user correctly because it cannot look up all the groups the user belongs to. To work around this issue, you can enable automatic private group mapping in SSSD by setting the auto_private_groups option to true or hybrid:

auto_private_groups = true

SSSD always maps a private group with the gidNumber set to match the uidNumber from the AD user entry.

Table 7.3. SSSD behavior when the auto_private_groups variable is set to true for a POSIX ID range

User configuration in ADOutput of id username

AD user entry has:

  • uidNumber = 4000
  • gidNumber is not defined
  • AD does not have a group with GID=4000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

AD user entry has:

  • uidNumber = 4000
  • gidNumber = 5000
  • AD does not have a group with gidNumber = 5000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

AD user entry has:

  • uidNumber = 4000
  • gidNumber = 4000
  • AD does not have a group with gidNumber = 4000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

AD user entry has:

  • uidNumber = 4000
  • gidNumber = 5000
  • AD has a group with gidNumber = 5000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

auto_private_groups = hybrid

If the uidNumber value matches gidNumber, but there is no group with this gidNumber, SSSD maps a private group as the user’s primary user group with a gidNumber that matches the uidNumber. If the uidNumber and gidNumber values differ, and there is a group with this gidNumber, SSSD uses the value from gidNumber.

Table 7.4. SSSD behavior when the auto_private_groups variable is set to hybrid for a POSIX ID range

User configuration in ADOutput of id username

AD user entry with:

  • uidNumber = 4000
  • gidNumber is not defined
  • AD does not have a group with gidNumber = 4000.

SSSD cannot resolve the user.

AD user entry with:

  • uidNumber = 4000
  • gidNumber = 5000
  • AD does not have a group with gidNumber = 5000.

SSSD cannot resolve the user.

AD user entry with:

  • uidNumber = 4000
  • gidNumber = 4000
  • AD does not have a group with gidNumber = 4000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

AD user entry with:

  • uidNumber = 4000
  • gidNumber = 5000
  • AD has a group with gidNumber = 5000.

# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=5000(aduser@ad-domain.com) groups=5000(adgroup@ad-domain.com), …​

7.7. Options for automatically mapping private groups for AD users: ID mapping trusts

Each user in a Linux environment has a primary user group. Red Hat Enterprise Linux (RHEL) uses a user private group (UPG) scheme: a UPG has the same name as the user for which it was created and that user is the only member of the UPG.

If you have allocated UIDs for your AD users, but GIDs were not added, you can configure SSSD to automatically map private groups for users based on their UID by adjusting the auto_private_groups setting for that ID range.

By default, the auto_private_groups option is set to true for ipa-ad-trust ID ranges used in an ID mapping trust. With this configuration, SSSD computes the UID and GID for an AD user based on its Security Identifier (SID). SSSD ignores any POSIX attributes in AD, such as uidNumber, gidNumber, and also ignores the primaryGroupID.

auto_private_groups = true

SSSD always maps a private group with the GID set to match the UID, which is based on the SID of the AD user.

Table 7.5. SSSD behavior when the auto_private_groups variable is set to true for an ID mapping ID range

User configuration in ADOutput of id username

AD user entry where:

  • SID maps to 7000
  • primaryGroupID maps to 8000

# id aduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=7000(aduser@ad-domain.com) groups=7000(aduser@ad-domain.com), 8000(adgroup@ad-domain.com), …​

auto_private_groups = false

If you set the auto_private_groups option to false, SSSD uses the primaryGroupID set in the AD entry as the GID number. The default value for primaryGroupID corresponds to the Domain Users group in AD.

Table 7.6. SSSD behavior when the auto_private_groups variable is set to false for an ID mapping ID range

User configuration in ADOutput of id username

AD user entry where:

  • SID maps to 7000
  • primaryGroupID maps to 8000

# id aduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=8000(adgroup@ad-domain.com) groups=8000(adgroup@ad-domain.com), …​

7.8. Enabling automatic private group mapping for a POSIX ID range on the CLI

By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them.

This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid option for the auto_private_groups SSSD parameter on the command line. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD.

Prerequisites

  • You have successfully established a POSIX cross-forest trust between your IdM and AD environments.

Procedure

  1. Display all ID ranges and make note of the AD ID range you want to modify.

    [root@server ~]# ipa idrange-find
    ----------------
    2 ranges matched
    ----------------
      Range name: IDM.EXAMPLE.COM_id_range
      First Posix ID of the range: 882200000
      Number of IDs in the range: 200000
      Range type: local domain range
    
      Range name: AD.EXAMPLE.COM_id_range
      First Posix ID of the range: 1337000000
      Number of IDs in the range: 200000
      Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309
      Range type: Active Directory trust range with POSIX attributes
    ----------------------------
    Number of entries returned 2
    ----------------------------
  2. Adjust the automatic private group behavior for the AD ID range with the ipa idrange-mod command.

    [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range
  3. Reset the SSSD cache to enable the new setting.

    [root@server ~]# sss_cache -E

7.9. Enabling automatic private group mapping for a POSIX ID range in the IdM WebUI

By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them.

This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid option for the auto_private_groups SSSD parameter in the Identity Management (IdM) WebUI. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD.

Prerequisites

  • You have successfully established a POSIX cross-forest trust between your IdM and AD environments.

Procedure

  1. Log into the IdM Web UI with your user name and password.
  2. Open the IPA ServerID Ranges tab.
  3. Select the ID range you want to modify, such as AD.EXAMPLE.COM_id_range.
  4. From the Auto private groups drop down menu, select the hybrid option.

    Screenshot of the ID Ranges tab of the IPA Server section of the IdM WebUI. A user selects the hybrid option from the Auth private groups dropdown menu.

  5. Click the Save button to save your changes.

7.10. Non-POSIX External Groups and SID Mapping

Identity Management (IdM) uses LDAP for managing groups. Active Directory (AD) entries are not synchronized or copied over to IdM, which means that AD users and groups have no LDAP objects in the LDAP server, so they cannot be directly used to express group membership in the IdM LDAP. For this reason, administrators in IdM need to create non-POSIX external groups, referenced as normal IdM LDAP objects to signify group membership for AD users and groups in IdM.

Security IDs (SIDs) for non-POSIX external groups are processed by SSSD, which maps the SIDs of groups in Active Directory to POSIX groups in IdM. In Active Directory, SIDs are associated with user names. When an AD user name is used to access IdM resources, SSSD uses the user’s SID to build up a full group membership information for the user in the IdM domain.

7.11. Setting up DNS

These guidelines can help you achieve the right DNS configuration for establishing a cross-forest trust between Identity Management (IdM) and Active Directory (AD).

Unique primary DNS domains

Ensure both AD and IdM have their own unique primary DNS domains configured. For example:

  • ad.example.com for AD and idm.example.com for IdM
  • example.com for AD and idm.example.com for IdM

The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but you can also use any other standard-compliant DNS server.

IdM and AD DNS Domains
Systems joined to IdM can be distributed over multiple DNS domains. Red Hat recommends that you deploy IdM clients in a DNS zone different to the ones owned by Active Directory. 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. See Configuring IdM clients in an Active Directory DNS domain for more details.

Proper SRV records

Ensure the primary IdM DNS domain has proper SRV records to support AD trusts.

For other DNS domains that are part of the same IdM realm, the SRV records do not have to be configured when the trust to AD is established. The reason is that AD domain controllers do not use SRV records to discover Kerberos key distribution centers (KDCs) but rather base the KDC discovery on name suffix routing information for the trust.

DNS records resolvable from all DNS domains in the trust

Ensure all machines can resolve DNS records from all DNS domains involved in the trust relationship:

Kerberos realm names as upper-case versions of primary DNS domain names
Ensure Kerberos realm names are 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 must be AD.EXAMPLE.COM and IDM.EXAMPLE.COM.

7.12. NetBIOS names

The NetBIOS name is usually the far-left component of the domain name. For example:

  • In the domain name linux.example.com, the NetBIOS name is linux.
  • In the domain name example.com, the NetBIOS name is example.

    Different NetBIOS names for the Identity Management (IdM) and Active Directory (AD) domains

    Ensure the IdM and AD domains have different NetBIOS names.

    The NetBIOS name is critical for identifying the AD domain. If the IdM domain is within a subdomain of the AD DNS, the NetBIOS name is also critical for identifying the IdM domain and services.

    Character limit for NetBIOS names
    The maximum length of a NetBIOS name is 15 characters.

7.13. Supported versions of Windows Server

Identity Management (IdM) does not support establishing trust to Active Directory with Active Directory domain controllers running Windows Server 2008 R2 or earlier versions. RHEL IdM requires SMB encryption when establishing the trust relationship, which is only supported in Windows Server 2012 or later.

You can establish a trust relationship with Active Directory (AD) forests that use the following forest and domain functional levels:

  • Forest functional level range: Windows Server 2012 — Windows Server 2016
  • Domain functional level range: Windows Server 2012 — Windows Server 2016

Identity Management (IdM) supports establishing a trust with Active Directory domain controllers running the following operating systems:

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

7.14. Configuring AD server discovery and affinity

Server discovery and affinity configuration affects which Active Directory (AD) servers an Identity Management (IdM) client communicates with. This section provides an overview of how discovery and affinity work in an environment with a cross-forest trust between IdM and AD.

Configuring clients to prefer servers in the same geographical location helps prevent time lags and other problems that occur when clients contact servers from another, remote data center. To make sure clients communicate with local servers, you must ensure that:

  • Clients communicate with local IdM servers over LDAP and over Kerberos
  • Clients communicate with local AD servers over Kerberos
  • Embedded clients on IdM servers communicate with local AD servers over LDAP and over Kerberos

Options for configuring LDAP and Kerberos on the IdM client for communication with local IdM servers

When using IdM with integrated DNS

By default, clients use automatic service lookup based on the DNS records. In this setup, you can also use the DNS locations feature to configure DNS-based service discovery.

To override the automatic lookup, you can disable the DNS discovery in one of the following ways:

  • During the IdM client installation by providing failover parameters from the command line
  • After the client installation by modifying the System Security Services Daemon (SSSD) configuration
When using IdM without integrated DNS

You must explicitly configure clients in one of the following ways:

  • During the IdM client installation by providing failover parameters from the command line
  • After the client installation by modifying the SSSD configuration

Options for configuring Kerberos on the IdM client for communication with local AD servers

IdM clients are unable to automatically discover which AD servers to communicate with. To specify the AD servers manually, modify the krb5.conf file:

  • Add the AD realm information
  • Explicitly list the AD servers to communicate with

For example:

[realms]
AD.EXAMPLE.COM = {
kdc = server1.ad.example.com
kdc = server2.ad.example.com
}

Options for configuring embedded clients on IdM servers for communication with local AD servers over Kerberos and LDAP

The embedded client on an IdM server works also as a client of the AD server. It can automatically discover and use the appropriate AD site.

When the embedded client performs the discovery, it might first discover an AD server in a remote location. If the attempt to contact the remote server takes too long, the client might stop the operation without establishing the connection. Use the dns_resolver_timeout option in the sssd.conf file on the client to increase the amount of time for which the client waits for a reply from the DNS resolver. See the sssd.conf(5) man page for details.

Once the embedded client has been configured to communicate with the local AD servers, the SSSD remembers the AD site the embedded client belongs to. Thanks to this, SSSD normally sends an LDAP ping directly to a local domain controller to refresh its site information. If the site no longer exists or the client has meanwhile been assigned to a different site, SSSD starts querying for SRV records in the forest and goes through a whole process of autodiscovery.

Using trusted domain sections in sssd.conf, you can also explicitly override some of the information that is discovered automatically by default.

7.15. Operations performed during indirect integration of IdM to AD

This section provides details on which operations and requests are performed during indirect integration of IdM to AD.

Read the table to learn about operations and requests performed during the creation of an Identity Management (IdM) to Active Directory (AD) trust from the IdM trust controller towards AD domain controllers.

Table 7.7. Operations performed from an IdM trust controller towards AD domain controllers

OperationProtocol usedPurpose

DNS resolution against the AD DNS resolvers configured on an IdM trust controller

DNS

To discover the IP addresses of AD domain controllers

Requests to UDP/UDP6 port 389 on an AD DC

Connectionless LDAP (CLDAP)

To perform AD DC discovery

Requests to TCP/TCP6 ports 389 and 3268 on an AD DC

LDAP

To query AD user and group information

Requests to TCP/TCP6 ports 389 and 3268 on an AD DC

DCE RPC and SMB

To set up and support cross-forest trust to AD

Requests to TCP/TCP6 ports 135, 139, 445 on an AD DC

DCE RPC and SMB

To set up and support cross-forest trust to AD

Requests to dynamically opened ports on an AD DC as directed by the Active Directory domain controller, likely in the range of 49152-65535 (TCP/TCP6)

DCE RPC and SMB

To respond to requests by DCE RPC End-point mapper (port 135 TCP/TCP6)

Requests to ports 88 (TCP/TCP6 and UDP/UDP6), 464 (TCP/TCP6 and UDP/UDP6), and 749 (TCP/TCP6) on an AD DC

Kerberos

To obtain a Kerberos ticket; change a Kerberos password; administer Kerberos remotely

Read the table to learn about operations and requests performed during the creation of an IdM to AD trust from the AD domain controller towards IdM trust controllers.

Table 7.8. Operations performed from an AD domain controller towards IdM trust controllers

OperationProtocol usedPurpose

DNS resolution against the IdM DNS resolvers configured on an AD domain controller

DNS

To discover the IP addresses of IdM trust controllers

Requests to UDP/UDP6 port 389 on an IdM trust controller

CLDAP

To perform IdM trust controller discovery

Requests to TCP/TCP6 ports 135, 139, 445 on an IdM trust controller

DCE RPC and SMB

To verify the cross-forest trust to AD

Requests to dynamically opened ports on an IdM trust controller as directed by the IdM trust controller, likely in the range of 49152-65535 (TCP/TCP6)

DCE RPC and SMB

To respond to requests by DCE RPC End-point mapper (port 135 TCP/TCP6)

Requests to ports 88 (TCP/TCP6 and UDP/UDP6), 464 (TCP/TCP6 and UDP/UDP6), and 749 (TCP/TCP6) on an IdM trust controller

Kerberos

To obtain a Kerberos ticket; change a Kerberos password; administer Kerberos remotely