Chapter 21. Installing trust between IdM and AD

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

  • First, read the Planning a cross-forest trust between Identity Management and Active Directory document.
  • AD is installed with a domain controller on it.
  • The IdM server is installed and running.

  • Both the AD server and the IdM server must have their clocks in sync because Kerberos requires max 5 mins delay in communication.
  • 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 NetBIOS name of an Active Directory or IdM domain is usually the first part of the corresponding DNS domain. If the DNS domain is ad.example.com, the NetBIOS name is typically AD. However, it is not required. Important is that the NetBIOS name is just one word without periods. The maximum length of a NetBIOS name is 15 characters.
  • 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.

21.1. Supported versions of Windows Server

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

Identity Management (IdM) supports the following operating systems:

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

21.2. How the trust works

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:

  • Log in to access Linux systems and resources.
  • Use single sign-on (SSO).

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.

Note

In trust environments, IdM enables you to use ID views to configure POSIX attributes for AD users on the IdM server.

21.3. AD administration rights

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:

  • Enterprise Admin group in the AD forest
  • Domain Admins group in the forest root domain for your AD forest

Related information

21.4. Ports required for communication between IdM and AD

To enable communication between Active Directory (AD) domain controllers and Identity Management (IdM) servers, you must open ports on their firewalls.

Table 21.1. Ports required for an AD trust

ServicePortProtocol

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 and UDP

Note

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:

  • Firewalld service — you can enable the particular ports or enable the following services which includes the ports:

    • FreeIPA trust setup
    • FreeIPA with LDAP
    • Kerberos
    • DNS

    For details, see Controlling ports using CLI.

  • The RHEL web console, which is a UI with firewall settings based od firewalld.

    cockpit trust ports

For details about firewall configuration through the web console, see Enabling services on firewall using the web console.

Table 21.2. Ports required by IdM servers in a trust

ServicePortProtocol

Kerberos

88, 464

TCP and UDP

LDAP

389

TCP

DNS

53

TCP and UDP

Table 21.3. Ports required by IdM clients in an AD trust

ServicePortProtocol

Kerberos

88

UDP and TCP

Note

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.

21.5. Configuring DNS and realm settings for a trust

Before 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:

  • One primary IdM server using integrated DNS server and Certification Authority.
  • One AD Domain Controller.

DNS settings require:

  • Configuring DNS zones in the IdM server
  • Configuring conditional DNS forwarding in AD
  • Verifying correctness of the DNS configuration

21.5.1. Unique primary DNS domains

In 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:

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

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.
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 following command:

$ ipa dns-update-system-records --dry-run

The 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.2

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.

21.5.2. Configuring DNS zones in the IdM Web UI

This section describes how to add a new DNS forward zone to the Identity Management (IdM) server.

DNS forward zones enables you to forward DNS queries for a specific zone to a different DNS server.

For example, on your IdM server, you want to forward queries for the Active Directory (AD) domain.

Prerequisites

  • Access to the IdM Web UI with a user account which have administrator rights.
  • Correctly configured DNS server.

Procedure

  1. Log in to the IdM Web UI with administrator privileges. For details, see Accessing the IdM Web UI in a web browser.
  2. Click on the Network Services tab.
  3. Click on the DNS tab.
  4. In the drop down menu, click on the DNS Forward Zones item.

    web ui dns tab

  5. Click on the Add button.
  6. In the Add DNS forward zone dialog box, add a zone name.
  7. In the Zone forwarders item, click on the Add button.
  8. In the Zone forwarders field, add the IP address of the server for which you want to create the new forward zone.
  9. Click on the Add button.

    web ui forward zone add

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.

You can perform the same procedure in the command line with the following command:

# ipa dnsforwardzone-add $AD_DOMAIN --forwarder=$AD_IP_ADDR --forward-policy=only
Note

The Web UI can display a warning about DNSSEC validation failure after adding a new forward zone to the configuration.

web ui forward zone dnssec valid

DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. The DNSSEC service is enabled by default in the IdM server. The warning appeared because the remote DNS server didn’t also use the DNSSEC. Now, you can:

  • Enable DNSSEC on the remote DNS server.
  • Disable the DNSSEC validation in the /etc/named.conf file saved in the IdM server:
dnssec-validation no;

After saving the configuration change, do not forget to restart the ipactl service:

# ipactl restart

The warning will not appear again.

To verify that the dns zone has been created successfully, use the nslookup command with the name of the remote DNS server:

$ nslookup ad.example.com
Server:        192.168.122.2
Address:       192.168.122.2#53

No-authoritative answer:
Name:          ad.example.com
Address:       192.168.122.3

If the domain forwarding is configured correctly, nslookup will show you an IP address of the remote DNS server.

21.5.3. Configuring DNS forwarding in AD

This section describes how to set up a DNS forwarding in Active Directory (AD) for the Identity Management (IdM) server.

Prerequisites

  • Windows Server with AD installed.
  • DNS port open on both servers.

Procedure

  1. Log in to the Windows Server.
  2. Open Server Manager.
  3. Open DNS Manager.
  4. In Conditional Forwarders, add a new conditional forwarder with:

    • The IdM server IP address
    • A fully qualified domain name, for example, server.idm.example.com
  5. Save the settings.

21.5.4. Verifying the DNS configuration

Before configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other.

Prerequisites

  • You need to be logged in with sudo permissions.

Procedure

  1. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.

    [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
    0 100 88 server.ipa.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
    0 100 389 server.idm.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 you specified when installing IdM.

    [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
    "IDM.EXAMPLE.COM"

    If the previous steps did not return all the expected records, update the DNS configuration with the missing records:

    • If your IdM environment uses an integrated DNS server, enter the ipa dns-update-system-records command without any options to update your system records:

      [admin@server ~]$ ipa dns-update-system-records
    • If your IdM environment does not use an integrated DNS server:

      1. On the IdM server, export the IdM DNS records into a file:

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        The command creates a file named dns_records_file.nsupdate with the relevant IdM DNS records.

      2. Submit a DNS update request to your DNS server using the nsupdate utility and the dns_records_file.nsupdate file. For more information, see Updating External DNS Records Using nsupdate in RHEL 7 documentation. Alternatively, refer to your DNS server documentation for adding DNS records.
  3. Verify that IdM is able to resolve service records for AD with a command that runs a DNS query for Kerberos over UDP and LDAP over TCP service records:

    [admin@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.

21.6. Setting up a trust

This section describes how to configure the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line.

Prerequisites

21.6.1. Preparing the IdM server for the trust

Before you can establish a trust with AD and if you want to set up Samba on an IdM client, you must prepare the IdM domain using the ipa-adtrust-install utility on an IdM server. However, even if both situations apply, you must run ipa-adtrust-install only once on an IdM master.

Prerequisites

  • IdM is installed.

Procedure

  1. Install the required packages:

    [root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Authenticate as the IdM administrative user:

    [root@ipaserver ~]# kinit admin
  3. Run the ipa-adtrust-install utility:

    [root@ipaserver ~]# ipa-adtrust-install

    The DNS service 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.

  4. The script prompts you that the /etc/samba/smb.conf already exists and will be rewritten:

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. The script prompts you 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]: yes
  6. When prompted, enter the NetBIOS name for the IdM domain or press Enter to accept the name suggested:

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. You are prompted to run the SID generation task to create a SID for any existing users:

    Do you want to run the ipa-sidgen task? [no]: yes

    When the directory is first installed, at least one user (the IdM administrator) exists and as this is a resource-intensive task, if you have a high number of users, you can run this at another time.

  8. Make sure that DNS is properly configured, as described in Verifying the DNS configuration for a trust.

    Important

    Every time you run ipa-adtrust-install, Red Hat strongly recommends you to verify the DNS configuration as described in Verifying the DNS configuration for a trust every time after running ipa-adtrust-install, especially if IdM or AD do not use integrated DNS servers.

  9. Restart the ipa service:

    [root@ipaserver ~]# systemctl restart ipa
  10. Use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side:

    [root@ipaserver ~]# smbclient -L server.idm.example.com -k
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.10.4)
    ...

21.6.2. Setting up a trust agreement using the command line

This section describes on 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:

  • One-way trust — default option. One-way trust enables Active Directory (AD) users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain.
  • Two-way trust — Two-way trust enables AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings.

    • To create the two-way trust, add the following option to the command: --two-way=true
  • External trust for a trust relationship between domains that are in different forests.

    • To create the external trust, add the following option to the command: --external=true

In this section, the steps below shows you how to create a one-way trust agreement.

Prerequisites

Procedure

  1. Create a trust agreement for the AD domain and the IdM domain by using the ipa trust-add command:

    [root@server ~]# ipa trust-add --type=ad ad_domain_name --admin ad_admin_username --password

The ipa trust-add command configures the IdM server as a trust controller by default.

21.6.3. Setting up a trust agreement in the IdM Web UI

This section describes how to configure the Identity Management (IdM)/Active Directory (AD) trust agreement on the IdM side using the IdM Web UI.

Prerequisites

  • DNS is correctly configured. Both IdM and AD servers must be able to resolve each other names.
  • Supported versions of AD and IdM are deployed.
  • You have obtained a Kerberos ticket
  • Before creating a trust in the Web UI, prepare the IdM server for the trust as described in: Section 21.6.1, “Preparing the IdM server for the trust”
  • You need to be logged in as an IdM administrator

Procedure

  1. Log in to the IdM Web UI with administrator privileges. For details, see Accessing the IdM Web UI in a web browser.
  2. In the IdM Web UI, click the IPA Server tab.
  3. In the IPA Server tab, click the Trusts tab.
  4. In the drop down menu, select the Trusts option.

    ipa trust trusts

  5. Click the Add button.
  6. In the Add Trust dialog box, enter the name of the Active Directory domain.
  7. In the Account and Password fields, add the administrator credentials of the Active Directory administrator.

    ipa trust add

  8. [Optional] Select Two-way trust, if you want to enable AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings.
  9. [Optional] If your domains are in different forests, select External trust.
  10. Click Add.

If the trust has been successfully added to the IdM server, you can see the green pop-up window in the IdM Web UI. It means that the:

  • Domain name exists
  • User name and password of the Windows Server has been added correctly.

idm trust added

Now you can continue to test the trust connection and Kerberos authentication.

21.6.4. Verifying the Kerberos configuration

To 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

  1. Request a ticket for an Active Directory (AD) user:

    [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
  2. Request service tickets for a service within the IdM domain:

    [root@server ~]# kvno -S host server.idm.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@server ]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00
Default principal: user@AD.EXAMPLE.COM

Valid starting       Expires              Service principal
03.05.2016 18:31:06  04.05.2016 04:31:01  host/server.idm.example.com@IDM.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:01  04.05.2016 04:31:01  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00

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.

21.6.5. Verifying the trust configuration on IdM

Before configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other.

Prerequisites

  • You need to be logged in with administrator privileges.

Procedure

  1. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.

    [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
    0 100 88 server.idm.example.com.
    
    [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
    0 100 389 server.idm.example.com.

    These commands list all IdM servers on which ipa-adtrust-install has been executed. The output is empty if ipa-adtrust-install has not been executed on any IdM server, which is typically before establishing the first trust relationship.

  2. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records to verify that IdM is able to resolve service records for AD:

    [root@server ~]# 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.

.

21.6.6. Verifying the trust configuration on AD

After configuring the trust, verify that:

  • The Identity Management (IdM)-hosted services are resolvable from the Active Directory (AD) server.
  • AD services are resolvable from the AD server.

Prerequisites

  • You need to be logged in with administrator privileges.

Procedure

  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.idm.example.com.
    _kerberos._udp.idm.example.com.       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 88
        svr hostname   = server.idm.example.com
    > _ldap._tcp.ipa.example.com
    _ldap._tcp.idm.example.com       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 389
        svr hostname   = server.idm.example.com
  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.idm.example.com.
    _kerberos.idm.example.com.        text =
    
        "IDM.EXAMPLE.COM"
  4. 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.idm.example.com.
    _kerberos._udp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 88
        svr hostname = server.idm.example.com
    > _ldap._tcp.dc._msdcs.idm.example.com.
    _ldap._tcp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 389
        svr hostname = server.idm.example.com

    The command is expected to list all IdM servers on which the ipa-adtrust-install utility has been executed. For details about ipa-adtrust-install, see Preparing the IdM server for the trust. Note that the output is empty if ipa-adtrust-install has not been executed on any IdM server, which is typically before establishing the first trust relationship.

  5. Verify that AD services are resolvable from the AD server.

    C:\>nslookup.exe
    > set type=SRV
  6. 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

21.7. Removing the trust using the IdM Web UI

This section describes how to remove the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the IdM Web UI.

Prerequisites

Procedure

  1. Log in to the IdM Web UI with administrator privileges. For details, see Accessing the IdM Web UI in a web browser.
  2. In the IdM Web UI, click the IPA Server tab.
  3. In the IPA Server tab, click the Trusts tab.
  4. Select the trust you want to remove.

    idm trust remove

  5. Click the Delete button.
  6. In the Remove trusts dialog box, click Delete.

    idm trust delete

If the trust is successfully deleted, the Web UI displays a green pop-up with the text:

idm trust deleted