Hello can someone please help me with the following questions as I am learning trying to understand the finer details of Kerberos Trust relationships (e.g. forest, domain, realm, external, shortcut). I am reading some Microsoft documentation but it does not always make things 100% clear or seems to contradict itself (or perhaps it’s just me being thick J ) Show
Scenario One If I have two (AD 2012 R2) Forests whereby the forest root domain on each is called ADF1 and XDF2 respectively. Under ADF1 (root domain) I have a sub-domain called SD1 then user SD1 I have a sub-domain called SD2 and under SD2 I have a sub-domain called SD3. Under XDF2 (root domain) I have a sub-domain called XD1 then user XD1 I have a sub-domain called XD2 and under XD2 I have a sub-domain called XD3. Question 1 Am I correct in saying you can only have a ‘domain’ trust between domains in the ‘same’ forest. In other words, although you can set up a trust between two domains in separate forests this would not be called a ‘domain’ trust but rather an ‘external trust’ or a ‘forest trust’ but it would only be called a ‘forest trust’ if the two domains in question where the two root domains (ADF1 and XDF1 in this case)? Question 2 If I create a trust relationship between SD1 and XD1 (e.g. non-root domains) between the two forests (as above I believe this is called an ‘external trust’) and let’s say SD1 is the ‘trusted domain’ then users in SD1 can access resources in XD1 (providing the ACL on the resource allows them to). However if my understanding is correct, I believe it is true to say (from what I have read) users in ‘SD3’ domain will not be able to access the trust setup on SD1 (as domain SD1 is not a direct parent or child of SD3) and therefore will not be able to access resources in XD1 domain? I say this because from what I have read it keep referring to must be a parent or child (not a grandparent of grandchild etc.) domain in order for the trust to be visible (and therefore accessible) despite the forest wide DTO (domain trust objects in AD). I would be most grateful for clarification on the above points Thanks in advance __AAnotherUser AAnotherUser__
An Active Directory network may contain several domains in a hierarchical fashion. All the resources of one domain are not directly available to every other domain. The availability of resource sharing is governed by Active Directory trusts. In this article, we will take a look at what are trusts in Active Directory, how they are categorized, and the different types of trusts that can be established. Active Directory trustsActive Directory trusts are communication bridges established between one domain and another domain in the Active Directory (AD) network. When one domain trusts another domain in an AD network, resources from the trusted domain can be shared with the trusting domain. Thus, AD trusts are also a way for a user in the network to gain access to resources from other domains. AD trust typesThere are two ways of classifying AD trusts. They are as follows:
Based on their characteristics, AD trusts are classified into two categories, they are as follows:
Transitive trustsTransitive trusts are trusts that can extend beyond the two domains that the trust connects. When a domain has a transitive trust with another domain, it can also trust and communicate between other domains that the trusted domain has established trust with. Non-transitive trustsNon-transitive trusts do not extend beyond the two domains that the trust connects. So, when a domain trusts another domain, it cannot communicate with the other domains that the trusted domain has communications with. To understand transitive and non-transitive trusts better, consider three domains A, B, and C in two cases. In the first case, domain A trusts domain B, and domain B has a transitive trust with domain C. Therefore, domain A will automatically trust domain C thanks to its trust in domain B. In the second case, domain A trusts domain B, and domain B has a non-transitive trust with domain C. In this case, even though domain A has an indirect link to domain C through domain B, domain A does not trust domain C because the trust is non-transitive. Based on the direction, AD trusts are classified into two categories. They are as follows:
One-way trustsOne-way trusts mean that when a domain trusts another domain, that trust doesn’t replicate vice versa. Hence, the trust flows only one way. Two-way trustsIn two-way trusts, when one domain trusts another domain, the other way is also trust. So, both domains can access the resources of the other. To understand one-way and two-way trusts better, consider two domains, A and B. If domain A has a one-way trust with domain B, then domain A trusts domain B and can access resources from domain B. However, domain B does not trust domain A and cannot access resources from domain A. Now, if domain A has a two-way trust with domain B, it automatically means that domain B also trusts domain A, and both these domains can share resources between themselves. With these two bases for categorizing trusts, there are five trust types in AD, which are as follows:
Parent-child trustA parent-child trust is a two-way transitive trust. A parent-child trust is automatically established when a child domain is added to a parent domain. When new child domains are added, the trust path flows upward through the domain hierarchy. Tree-root trustTree-root trusts are also two-way transitive trusts similar to parent-child trusts. When a new domain tree is created within a forest, a tree-root trust is automatically created between the new domain tree and all existing domain trees. For example, domain A is an existing domain with child domains B and C within a forest X. When a new domain D with child domains E and F are created since they come under the same forest X, domains D, E, and F will automatically be trusted by domains A, B, and C. Forest trustForest trusts are transitive, and they can either be one-way or two-way trusts. Forest trusts are ones that occur between forests, and these trusts are manually created. When one forest trusts another forest, all the domains within the two forests will automatically trust each other. Shortcut trustShortcut trusts are one-way transitive trusts. These trusts are created manually. These trusts are created when one domain needs to trust another domain by bypassing the hierarchy of trusts such as parent-child trusts or forest-root trusts. A shortcut trust is usually established to shorten what is called a trust path. A trust path is a path that an authentication process must take if two domains do not directly trust each other. So, direct trust is established. Hence, shortcut trust is used to make the authentication process between two domains simpler. External trustAn external trust is a one-way non-transitive trust. These trusts are manually established. An external trust is established with an external domain outside the forest of the trusting domain. Realm trustReal trust is trust between a domain or a forest with another domain or a forest that is not based on Windows Active Directory. Realm-trusts allow for cross-platform communication between domains. This trust is one-way by default. To create a two-way trust, one must create trust in the other way. This chapter aims to help you create a trust between the Identity Management IdM server and Active Directory (AD), where both servers are located in the same forest. Prerequisites The IdM server is installed and running. Unique NetBIOS names for each of the servers placed in the trust because the NetBIOS names are critical for identifying the Active Directory domain. The IdM system must have the IPv6 protocol enabled in the kernel. You can establish a trust relationship with Active Directory (AD) forests that use the following forest and domain functional levels: Identity Management (IdM) supports establishing a trust with Active Directory domain controllers running the following operating systems: In RHEL 8.4,
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 now requires SMB encryption when establishing the trust relationship, which is only supported in Windows Server 2012 or later. The trust between
Identity Management IdM and Active Directory (AD) is established on the Cross-realm Kerberos trust. This solution uses the Kerberos capability to establish trusts between different identity sources. Therefore, all AD users can: All IdM objects are managed in IdM in the trust. All AD objects are managed in AD in the trust. In complex
environments, a single IdM forest can be connected to multiple AD forests. This setup enables better separation of duties for different functions in the organization. AD administrators can focus on users and policies related to users while Linux administrators have full control over the Linux infrastructure. In such a case, the Linux realm controlled by IdM is analogous to an AD resource domain or realm but with Linux systems in it. From the perspective of AD, Identity Management
represents a separate AD forest with a single AD domain. When cross-forest trust between an AD forest root domain and an IdM domain is established, users from the AD forest domains can interact with Linux machines and services from the IdM domain. In trust environments, IdM enables you to use ID views to configure POSIX attributes for AD users on the IdM server. When you want to build a trust between AD (Active Directory) and IdM (Identity Management), you will need to use an AD administrator account with appropriate AD privileges. Such an AD administrator must be a member of one of the following groups: By default, Identity Management establishes a cross-realm trust with support for RC4, AES-128, and AES-256 Kerberos encryption types. RC4 encryption has been deprecated and disabled by default, as it is considered less secure than the newer AES-128 and AES-256 encryption types. In
contrast, Active Directory (AD) user credentials and trusts between AD domains support RC4 encryption and they might not support AES encryption types. Without any common encryption types, communication between IdM and AD child domains might not work, or some AD accounts might not be able to authenticate. To remedy this situation, modify one of the following configurations: Enable AES encryption support in Active Directory (recommended option) To
ensure trusts between AD domains in an AD forest support strong AES encryption types, see the following Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domainEnable RC4 support in RHEL On every IdM trust controller, trust agent, and client where
authentication against AD Domain Controllers takes place: Use the update-crypto-policies command to enable the AD-SUPPORT cryptographic subpolicy in addition to the DEFAULT cryptographic policy. The AD-SUPPORT cryptographic subpolicy is only available on RHEL 8.3 and newer. To enable support for RC4 in RHEL 8.0 and RHEL 8.1, add
+rc4 to the permitted_enctypes option in the /etc/crypto-policies/back-ends/krb5.config file: To enable communication between your Active Directory (AD) and Identity Management (IdM) environments, open the following ports on the firewalls of your AD Domain Controllers and IdM
servers. Table 33.1. Ports required for an AD trust
Endpoint resolution portmapper 135 TCP NetBIOS-DGM 138 TCP and UDP NetBIOS-SSN 139 TCP and UDP Microsoft-DS 445 TCP and UDP Dynamic RPC 49152-65535 TCP AD Global Catalog 3268 TCP LDAP 389 TCP and UDP 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. To open ports, you can use the following methods:
Table 33.2. Ports required by IdM servers in a trust
Table 33.3. Ports required by IdM clients in an AD trust
The libkrb5 library uses UDP and falls back to the TCP protocol if the data sent from the Key Distribution Centre (KDC) is too large. Active Directory attaches a Privilege Attribute Certificate (PAC) to the Kerberos ticket, which increases the size and requires 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. If you want 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. The following diagram shows the ports and protocols that IdM clients, IdM servers, and AD Domain Controllers use when communicating with each other.
Additional resources
33.6. Configuring DNS and realm settings for a trustBefore you connect Identity Management (IdM) and Active Directory (AD) in a trust, you need to ensure that servers see each other and resolve domain names correctly. This scenario describes configuring DNS to allow using domain names between:
DNS settings require:
33.6.1. Unique primary DNS domainsIn Windows, every domain is a Kerberos realm and a DNS domain at the same time. Every domain managed by the domain controller needs to have its own dedicated DNS zone. The same applies when Identity Management (IdM) is trusted by Active Directory (AD) as a forest. AD expects IdM to have its own DNS domain. For the trust setup to work, the DNS domain needs to be dedicated to the Linux environment. Each system must have its own unique primary DNS domain configured. For example:
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. 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. 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. 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. You can acquire a list of the required SRV records specific to your system setup by running the following command: $ ipa dns-update-system-records --dry-runThe generated list can look for example like this: IPA DNS records: _kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com. _kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com. _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com. _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com. _kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM" _kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com. _kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com. _ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com. _ipa-ca.idm.example.com. 86400 IN A 192.168.122.2For 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. 33.6.2. Configuring a DNS forward zone in the IdM Web UIThis section describes how to add a DNS forward zone to the Identity Management (IdM) server by using the IdM Web UI. With DNS forward zones, you can forward DNS queries for a specific zone to a different DNS server. For example, you can forward DNS queries for the Active Directory (AD) domain to an AD DNS server. Prerequisites
Procedure
The forwarded zone has been added to the DNS settings and you can verify it in the DNS Forward Zones settings. The Web UI informs you about success with the following pop-up message: DNS Forward Zone successfully added. The Web UI might display a warning about a DNSSEC validation failure after adding a forward zone to the configuration.
DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. This service is enabled by default in the IdM server. The warning appears because the remote DNS server does not use DNSSEC. Red Hat recommends that you enable DNSSEC on the remote DNS server. If you cannot enable DNSSEC validation on the remote server, you can disable DNSSEC in the IdM server:
Verification steps
33.6.3. Configuring a DNS forward zone in the CLIThis section describes how to add a new DNS forward zone to the Identity Management (IdM) server using the command line interface (CLI). With DNS forward zones, you can forward DNS queries for a specific zone to a different DNS server. For example, you can forward DNS queries for the Active Directory (AD) domain to an AD DNS server. Prerequisites
Procedure
You might see a warning about a DNSSEC validation failure in the /var/log/messages system logs after adding a new forward zone to the configuration: named-pkcs11[2572]: no valid DS resolving 'host.ad.example.com/A/IN': 192.168.100.25#53DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. This service is enabled by default in the IdM server. The warning appears because the remote DNS server does not use DNSSEC. Red Hat recommends that you enable DNSSEC on the remote DNS server. If you cannot enable DNSSEC validation on the remote server, you can disable DNSSEC in the IdM server:
Verification steps
33.6.4. Configuring DNS forwarding in ADThis section describes how to set up a DNS forwarding in Active Directory (AD) for the Identity Management (IdM) server. Prerequisites
Procedure
33.6.5. Verifying the DNS configurationBefore configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other. Prerequisites
Procedure
33.7. Configuring IdM clients in an Active Directory DNS domainIf you have client systems in a DNS domain controlled by Active Directory and you require those clients to be able to join the IdM Server to benefit from its RHEL features, you can configure users to access a client using a host name from the Active Directory DNS domain. 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. Your IdM client configuration depends on whether you require single sign-on with Kerberos. 33.7.1. Configuring an IdM client without Kerberos single sign-onPassword authentication is the only authentication method that is available for users to access resources on IdM clients if the IdM clients are in an Active Directory DNS domain. This procedure describes how to configure your client without Kerberos single sign-on. Procedure
33.7.2. Requesting SSL certificates without single sign-onSSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database. In the described setup without single sign-on available, IdM already has a host object for the FQDN in the database, and certmonger can request a certificate using this name. Prerequisites
Procedure
The certmonger service uses the default host key stored in the /etc/krb5.keytab file to authenticate to the IdM Certificate Authority (CA). 33.7.3. Configuring an IdM client with Kerberos single sign-onIf you require Kerberos single sign-on to access resources on the IdM client, the client must be within the IdM DNS domain, for example idm-client.idm.example.com. You must create a CNAME record idm-client.ad.example.com in the Active Directory DNS domain pointing to the A/AAAA record of the IdM client. For Kerberos-based application servers, MIT Kerberos supports a method to allow the acceptance of any host-based principal available in the application’s keytab. Procedure
33.7.4. Requesting SSL certificates with single sign-onSSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database. This procedure describes how to to create a host object for ipa-client.example.com in IdM and make sure the real IdM machine’s host object is able to manage this host. Prerequisites
Procedure
33.8. Setting up a trustThis section describes how to configure the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line. Prerequisites
33.8.1. Preparing the IdM server for the trustBefore you can establish a trust with AD, you must prepare the IdM domain using the ipa-adtrust-install utility on an IdM server. Any system where you run the ipa-adtrust-install command automatically becomes an AD trust controller. However, you must run ipa-adtrust-install only once on an IdM server. Prerequisites
Procedure
33.8.2. Setting up a trust agreement using the command lineThis section describes how to set up the trust agreement using the command line. The Identity Management (IdM) server allows you to configure three types of trust agreements:
In this section, the steps below shows you how to create a one-way trust agreement. Procedure
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. 33.8.3. Setting up a trust agreement in the IdM Web UIThis section describes how to configure the Identity Management (IdM)/Active Directory (AD) trust agreement on the IdM side using the IdM Web UI. Prerequisites
Procedure
Verification steps
Now you can continue to test the trust connection and Kerberos authentication. 33.8.4. Setting up a trust agreement using AnsibleThis section describes how to set up a one-way trust agreement between Identity Management (IdM) and Active Directory (AD) by using an Ansible playbook. You can configure three types of trust agreements:
Prerequisites
Procedure
Additional resources
33.8.5. Verifying the Kerberos configurationTo verify the Kerberos configuration, test if it is possible to obtain a ticket for an Identity Management (IdM) user and if the IdM user can request service tickets. Procedure
The localauth plug-in maps Kerberos principals to local System Security Services Daemon (SSSD) user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly. 33.8.6. Verifying the trust configuration on IdMBefore configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other. Prerequisites
Procedure
. 33.8.7. Verifying the trust configuration on ADAfter configuring the trust, verify that:
Prerequisites
Procedure
33.8.8. Creating a trust agentA trust agent is an IdM server that can perform identity lookups against AD domain controllers. For example, if you are creating a replica of an IdM server that has a trust with Active Directory, you can set up the replica as a trust agent. A replica does not automatically have the AD trust agent role installed. Prerequisites
Procedure
Additional resources
33.8.9. Enabling automatic private group mapping for a POSIX ID range on the CLIBy 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
Procedure
33.8.10. Enabling automatic private group mapping for a POSIX ID range in the IdM WebUIBy 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
Procedure
33.9. Troubleshooting setting up a cross-forest trustThis chapter discusses troubleshooting the process of configuring a cross-forest trust between your Identity Management (IdM) environment and an Active Directory (AD) forest. 33.9.1. Sequence of events when establishing a cross-forest trust with ADWhen you use the ipa trust-add command to establish a cross-forest trust with an Active Directory (AD) Domain Controller (DC), the command operates on behalf of the user who ran the command and performs the following actions on the IdM server. If you have trouble establishing a cross-forest trust, you can use this list to help narrow down and troubleshoot your issue. Part 1: The command verifies settings and inputs
Part 2: The command attempts to establish a trust to an Active Directory domain
33.10. Troubleshooting client access to services in the other forestAfter configuring a trust between your Identity Management (IdM) and Active Directory (AD) environments, you might experience issues where a client in one domain is not able to access a service in the other domain. Use the following diagrams to troubleshoot the issue. 33.10.1. Flow of information when a host in the AD forest root domain requests services from an IdM serverThe following diagram explains the flow of information when an Active Directory (AD) client requests a service in the Identity Management (IdM) domain. If you have trouble accessing IdM services from AD clients, you can use this information to narrow your troubleshooting efforts and identify the source of the issue.
33.10.2. Flow of information when a host in an AD child domain requests services from an IdM serverThe following diagram explains the flow of information when an Active Directory (AD) host in a child domain requests a service in the Identity Management (IdM) domain. In this scenario, the AD client contacts the Kerberos Distribution Center (KDC) in the child domain, then contacts the KDC in the AD forest root, and finally contacts the IdM KDC to request access to the IdM service. If you have trouble accessing IdM services from AD clients, and your AD client belongs to a domain that is a child domain of an AD forest root, you can use this information to narrow your troubleshooting efforts and identify the source of the issue.
33.11. Removing the trust using the command lineThis section describes how to remove the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line interface. Prerequisites
Procedure
Verification steps
33.12. Removing the trust using the IdM Web UIThis section describes how to remove the Identity Management (IdM)/Active Directory (AD) trust using the IdM Web UI. Procedure
Verification steps
33.13. Removing the trust using AnsibleThis section describes how to remove the Identity Management (IdM)/Active Directory (AD) trust on the IdM side by using an Ansible playbook. Prerequisites
Procedure
Verification steps
Additional resources
Transitive trust is a two-way relationship automatically created between parent and child domains in a Microsoft Active Directory forest. In a two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This configuration means that authentication requests can be passed between the two domains in both directions. Some two-way relationships can be non-transitive or transitive depending on the type of trust being created. The tree-root trust is a trust that is created between any child domain and the root domain. This provides a shortcut to the root. This trust relationship is also automatically created when a new domain tree is created. Overview. An Active Directory trust (AD trust) is a method of connecting two distinct Active Directory domains (or forests) to allow users in one domain to authenticate against resources in the other. |