Bookmark this page

Guided Exercise: Establishing a Trust Relationship between IdM and AD

Create an IdM one-way trust relationship to Active Directory and use an Active Directory account to verify the trust configuration.

Back to video
Establishing a trust relationship between IdM and AD

Outcomes

  • Establish a one-way trust relationship to Active Directory.

Important

Unless specified by your instructor, this classroom does NOT include a Windows server. These instructions are provided so that you can follow along with the demonstration video.

As the student user on the workstation machine, use the lab command to prepare your environment for this exercise, and to ensure that all required resources are available:

[student@workstation ~]$ lab start ad-trust

Instructions

  1. On the Active Directory server, add the lab.example.com domain as a conditional forwarder. Verify that you can resolve services from the lab.example.com domain.

    1. Log in to the Active Directory server as the Administrator user with RedHat_2022 as the password.

    2. In Server Manager, navigate to Tools and then DNS.

    3. In DNS Manager, click DC, right click Conditional Forwarders, and then click New Conditional Forwarder.

    4. Enter lab.example.com as the DNS Domain. Add 172.25.250.8 as the IP address for the DNS domain and click OK.

      Note

      The window might show the An unknown error occurred while validating the server message. You can ignore the message and continue the procedure.

    5. Click Start, enter cmd, and then press Enter.

    6. In the Administrator: Command Prompt window, ensure that you can resolve records for the lab.example.com domain:

      C:\Users\Administrator>nslookup
      ...output omitted...
      > set type=srv
      > _ldap._tcp.lab.example.com
      ...output omitted...
      _ldap._tcp.lab.example.com    SRV service location:
                srv hostname = replica1.lab.example.com
               ...output omitted...
                srv hostname = replica2.lab.example.com
               ...output omitted...
                srv hostname = idm.lab.example.com
      ...output omitted...
      replica1.lab.example.com internet address = 172.25.250.10
      replica2.lab.example.com internet address = 172.25.250.13
      idm.lab.example.com internet address = 172.25.250.8
    7. Exit the command prompt:

      > exit
      C:\Users\Administrator>exit
  2. On the idm machine, configure a trust to the Active Directory server. Use LABEXAMPLE as the NetBIOS name. Include support for slapi-nis in trusted domains.

    1. From workstation, log in to the idm machine as student and become the root user:

      [student@workstation ~]$ ssh idm
      [student@idm ~]$ sudo -i
      [sudo] password for student: student
    2. Install the ipa-server-trust-ad package:

      [root@idm ~]# dnf install ipa-server-trust-ad
      ...output omitted...
      Is this ok [y/d/N]: y
      ...output omitted...
      Complete!
    3. Authenticate to IdM as the admin user. When prompted, use RedHat123^ as password:

      [root@idm ~]# kinit admin
      Password for admin@LAB.EXAMPLE.COM: RedHat123^
    4. Configure the idm machine to establish a trust relationship with Active Directory. Keep LAB as the NetBIOS domain name. If there are any warnings for the Samba configuration, override them:

      [root@idm ~]# ipa-adtrust-install -a RedHat123^
      
      ...output omitted...
      Do you wish to continue? [no]: yes
      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
      
      The following operations may take some minutes to complete.
      ...output omitted...
      WARNING: you MUST re-kinit admin user before using 'ipa trust-*' commands
      family in order to re-generate Kerberos tickets to include AD-specific
      information
  3. Disable DNSSEC in the IdM topology to resolve the AD domain.

    Important

    Repeat these steps in the replica1 and replica2 machines to disable DNSSEC completely.

    1. Edit the /etc/named/ipa-options-ext.conf file and disable DNSSEC validation:

      ...output omitted...
      dnssec-enable no;
      dnssec-validation no;
    2. Restart the IdM services:

      [root@idm ~]# systemctl restart ipa
    3. Restart the named service:

      [root@idm ~]# systemctl restart named.service
  4. Create a DNS forwarder for the ad.example.com domain. To avoid external DNS queries for the ad.example.com domain, add the --skip-overlap-check option.

    1. Create a DNS forwarder for the ad.example.com domain:

      [root@idm ~]# ipa dnsforwardzone-add \
        --skip-overlap-check ad.example.com \
        --forwarder=172.25.250.221 \
        --forward-policy=only
      Server will check DNS forwarder(s).
      This may take some time, please wait ...
        Zone name: ad.example.com.
        Active zone: True
        Zone forwarders: 172.25.250.221
        Forward policy: only
    2. Verify that you can resolve the LDAP AD service from the idm machine:

      [root@idm ~]# dig SRV _ldap._tcp.ad.example.com
      ...output omitted...
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3895
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
      ...output omitted...
      
      ;; ANSWER SECTION:
      _ldap._tcp.ad.example.com. 558 IN	SRV	0 100 389 dc.ad.example.com.
      
      ;; ADDITIONAL SECTION:
      dc.ad.example.com.	140	IN	A	172.25.250.221
      ...output omitted...
    3. Verify that you can resolve the Kerberos AD service from the idm machine:

      [root@idm ~]# dig SRV _kerberos._tcp.ad.example.com
      ...output omitted...
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43797
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
      ...output omitted...
      
      ;; ANSWER SECTION:
      _kerberos._tcp.ad.example.com. 600 IN	SRV	0 100 88 dc.ad.example.com.
      
      ;; ADDITIONAL SECTION:
      dc.ad.example.com.	3364	IN	A	172.25.250.221
      ...output omitted...
  5. Create the one-way trust relationship with ad.example.com Active Directory domain. When prompted, enter RedHat_2022 as the AD administrator password. Verify that the one-way trust is working.

    1. Create the one-way trust relationship with the ad.example.com Active Directory domain:

      [root@idm ~]# ipa trust-add --type=ad ad.example.com \
        --admin Administrator --password
      Active Directory domain administrator's password: RedHat_2022
      -------------------------------------------------------
      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-1851492132-63302129-2341221329
        Trust direction: Trusting forest
        Trust type: Active Directory domain
        Trust status: Established and verified
    2. Request a Kerberos ticket for the Active Directory aduser01 user. When prompted, enter RedHat_2022 as password:

      [root@idm ~]# kinit aduser01@ad.example.com
      Password for aduser01@ad.example.com: RedHat_2022
    3. Request a service ticket and print the key version number. Use the kvno command to request a Kerberos service ticket and display its version number for the host/dc.ad.example.com principal in the AD domain:

      [root@idm ~]# kvno -S host dc.ad.example.com
      host/dc.ad.example.com@: kvno = 3
    4. Use the klist command to ensure that the Kerberos tickets were successfully granted:

      [root@idm ~]# klist
      Ticket cache: KCM:0:68417
      Default principal: aduser01@AD.EXAMPLE.COM
      
      Valid starting     Expires            Service principal
      06/19/23 20:01:23  06/28/23 06:01:23  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
      	renew until 06/28/23 20:01:20
      06/19/23 20:01:33  06/28/23 06:01:23  host/dc.ad.example.com@
      	renew until 06/28/23 20:01:20
      	Ticket server: host/dc.ad.example.com@AD.EXAMPLE.COM
  6. Open a new terminal tab and log in to the client machine as the aduser05 Active Directory user. Enable the mkhomedir module to ensure that Active Directory users have a home directory created when they log in.

    1. Log in to the client machine as the aduser05 Active Directory user:

      [student@workstation ~]$ ssh aduser05@ad.example.com@client.lab.example.com
      (aduser05@ad.example.com@client.lab.example.com) Password: RedHat_2022
      ...output omitted...
      Could not chdir to home directory /home/ad.example.com/aduser05: No such file or directory
      [aduser05@ad.example.com@client /]$
    2. To automatically create home directories for remote users, become the root user and enable home directory creation. Exit the client machine:

      [aduser05@ad.example.com@client /]$ su -
      Password: redhat
      [root@client ~]# authselect select sssd with-mkhomedir
      Profile "sssd" was selected.
      The following nsswitch maps are overwritten by the profile:
      - passwd
      - group
      - netgroup
      - automount
      - services
      ...output omitted...
      [root@client ~]# exit
      logout
      [aduser05@ad.example.com@client /]$ exit
      logout
      Connection to client.lab.example.com closed.
    3. Verify the home directory of the user and the hostname of the machine:

      [student@workstation ~]$ ssh aduser05@ad.example.com@client.lab.example.com
      [aduser05@ad.example.com@client ~]$ pwd
      /home/ad.example.com/aduser05
      [aduser05@ad.example.com@client ~]$ hostname
      client.lab.example.com
    4. Exit the client machine:

      [aduser05@ad.example.com@client ~]$ exit
      logout
      Connection to client.lab.example.com closed.
  7. Verify the Active Directory trust agreements.

    1. On Server Manager on the Active Directory machine, navigate to Tools and then Active Directory Domains and Trusts.

    2. In the left pane, right-click the ad.example.com domain and then click Properties.

    3. In the example.com Properties window, click the Trusts tab.

    4. In the lower pane, click the lab.example.com domain. With the lab.example.com highlighted, click Properties.

    5. In the lab.example.com Properties window, notice that the Trust type is Forest and the direction of the trust is set to Incoming. This confirms that the trust was created successfully, and that users from the Active Directory domain are allowed to authenticate in the lab.example.com trusted domain.

    6. Close all the opened windows and log out of the Active Directory server.

    7. Close the second terminal tab and exit the idm machine:

      [root@idm ~]# exit
      logout
      [student@idm ~]$ exit
      logout
      Connection to idm closed.

Finish

On the workstation machine, change to the student user home directory and use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish ad-trust

Revision: rh362-9.1-4c6fdb8