How to Establish Trust Between IPA and Active Directory

Looking to learn how to establish trust between IPA and Active Directory (AD)?

Then we’ve got you covered.

For beginners, IPA (Identity Policy and Audit) provides a framework for managing and monitoring user identities, access policies, and organizational compliance.

On the other hand, AD (Active Directory) is a centralized database and directory service for managing network resources, user authentication, and group policies in a Windows domain.

We will go over how to establish trust between IPA and Active Directory. We will also learn how to configure IPA and AD and gain cross-forest trust easily.

Let’s begin!

Why Establish Trust Between IPA and Active Directory?

Establishing trust between IPA and AD helps enable seamless integration and interoperability between the systems. One common reason for integrating the two together is to share user and group information and authenticate users.

Here are some of the other benefits that can be achieved by understanding how to establish trust between IPA and Active Directory:

• Single Sign-On (SSO)
• User Synchronization
• Access Management
• Resource Sharing
• Policy Enforcement
• Interoperability

What You’ll Need

Before learning how to establish trust between IPA and Active Directory, it’s important to understand the prerequisites needed: 

• FreeIPA 3.3.3 or later is recommended.
• Windows Server 2019 or later with configured Active Directory Domain Controller (AD DC) configured. Ensure that DNS is also installed locally on the domain controller.
• Network Connectivity
• Administrative Privileges.

How to Establish Trust Between IPA and Active Directory: Step-by-Step

Step 1: Install and Configure the IPA Server

1. Begin by creating a hostname using the below command for your system, and make sure to use FreeIPA 3.3.3 or above for this: 

sudo hostnamectl set-hostname <your_host_name>

The command doesn’t generate any output (as shown in the screenshot below), but you can check if it has updated by entering the command – hostnamectl 

2. Now disable the IPv6 for Samba on the IPA. To achieve this, create or modify “/etc/sysctl.d/ipv6.conf” and add the following lines:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.<interface0>.disable_ipv6 = 1

AAfter incorporating the provided lines into the IPv6 config file, the interface will be replaced with your specified configuration; however, it will not assign IPv6 addresses to your network devices. To accomplish this, follow these steps:

1. Execute the command sudo vim /etc/sysctl.d/ipv6.conf to open the configuration file using the vim editor.
2. Once the vim editor opens the config file, add the aforementioned two lines as provided.
3. After making the changes, save the file by pressing the Escape (Esc) key and entering ‘:wq‘.

By following these instructions and saving the modified IPv6 config file, you will be able to customize the interface while ensuring that IPv6 addresses are assigned to your network devices according to your desired configuration.

3. After disabling IPv6 on your RHEL-based system, install IPA server packages using the below command. Ensure in the below command that the ipa-server-trust-ad module is added:

sudo yum install -y "*ipa-server" "*ipa-server-trust-ad" ipa-server-dns bind bind-dyndb-ldap

4. To obtain a ticket, setup the IPA server using the below command:

sudo ipa-server-install --domain <your_domain_name> --realm <your_realm_name>\
--reverse-zone=205.168.192.in-addr.arpa. \ 
--no-forwarders \
--no-ntp \
--setup-dns \
--ds-password StrongDMPassw0rd \
--admin-password StrongDMPassw0rd \
--unattended

By running this command, the IPA server will be installed and configured with the provided options. The ticket obtained will serve as a security credential, granting access to various resources within the IPA server.

5. After setting up the IPA Server, ensure the admin user is available using any of the below commands:

id admin 
getent passwd admin

6. If the admin user isn’t available, create one, and once done, generate the ticket using the below command:

kinit admin

The above command doesn’t generate any output. However, you can check the generated token using the command – klist.

Step 2: Install and Configure Active Directory Domain Services 

You need Active Directory Domain Services installed on Windows Server 2019/22 to understand how to establish trust between IPA and Active Directory further. I

If you haven’t done yet, here are the steps you should consider checking out:

How to Install Active Directory Domain Services: 

1. Assign a static IP address to the server hosting Active Directory Domain Services.
2. Make the server a member server by joining it to the network domain.
3. Once done, navigate to the “Manage” menu on the Server Manager.
4. Launch the wizard by selecting the “Add Roles and Features” option.
5. In the wizard, select the appropriate server and role-based installation.
6. After successfully proceeding through the wizard, choose the “Active Directory Domain Services” role on the “Server Roles” page.
7. Continue further by reviewing the role’s features and allowing any required dependencies to be installed. 
8. Now create, join, and modify a new or existing forest through the “Active Directory Domain Services” configuration page.
9. Once done, specify the NetBIOS name and FQDN for the domain. Also, choose the AD DS database location, log files, and SYSVOL folder.
10. Review the summary, and once you’re satisfied, click “Install” to begin the installation process.

---

 Steps to Configure AD DS

1. After successfully installing AD DS on Windows Server 2019/22, restart the server.
2. Once the server restarts, open the “Active Directory Users and Computers” tool to manage users, groups, and organizational units (OUs).
3. Configure the DNS settings to ensure proper name resolution for the AD DS domain.

Note: The above steps are general guidelines and not detailed steps. Hence, consider the steps as references and implement them carefully to learn how to establish trust between IPA and Active Directory. 

Step 3: Prepare Active Directory and IPA for Cross-Forest Trust

After successfully installing and configuring Active Directory (AD) and IPA, you must prepare them for the Cross-Forest Trust. 

Before we proceed with the steps, there’s a few factors to check out to prepare Active Directory  and IPA for Cross-Forest Trust:

1. Perform Date and Time Synchronization 

The first and foremost thing to perform is synchronizing the date and time on both the IPA and Active Directory. For Active Directory, you can adjust it from the local server properties. However, you need the below command to set the time on IPA:

sudo timedatectl set-timezone <COUNTRY/CITY>

2. Manage Firewall Configuration

IPA uses the TCP and UDP ports below to communicate with its services, so ensure that they are open and available.

The ports 88/udp, 88/tcp, and 389/udp are more crucial than the rest, allowing AD clients to obtain cross-realm ticket-granting tickets.

Use the below commands to permanently enable the above TCP and UDP ports:

sudo firewall-cmd --add-service={dns,http,https,ntp,freeipa-ldap,freeipa-ldaps,freeipa-trust} –permanent
sudo firewall-cmd --reload

Continue further only if you’re displayed ‘Success’ for both outputs.

3. Modify DNS Configuration

This step is crucial in understanding how to establish trust between IPA and Active Directory. The reason for modifying the DNS configuration is that both Active Directory and IPA domains need to be visible.

Usually, normal DNS configuration doesn’t require any changes. However, while testing DNS domains not part of the shared DNS tree visible to both IPA and Active Directory, the customer DNS zone forwarders must be created. 

Here are the commands to add a conditional forwarder for the IPA domain on Active Directory:

dnscmd 127.0.0.1 /ResetForwarders ipa_ip_address /Slave
dnscmd 127.0.0.1 /ZoneAdd ipa_domain /Secondary ipa_ip_address

Similar to Active Directory, you need to add a conditional forwarder for the Active Directory domain on the IPA server. Here are the commands to do so for IPA v4.x:

ipa dnsforwardzone-add ad_domain --forwarder=ad_ip_address --forward-policy=only
ipa dnszone-mod [IPA domain name] --allow-transfer=[AD IP address]

4. Verify DNS Configuration

Once you have created a conditional forwarder for both IPA and Active Directory, verify if the check if SRV records are being properly resolved. The below commands help us ensure both Active Directory and IPA servers can see each other.

Here are the commands to verify the changes on Active Directory:

> nslookup
> set type=srv
> _ldap._tcp.ad_domain
> _ldap._tcp.ipa_domain 
> quit

Here are the commands to verify the changes on IPA Server:

dig SRV _ldap._tcp.ipa_domain

dig SRV _ldap._tcp.ad_domain

You can see for both commands on the IPA server, the “ANSWER: 1”: is generated. In case the answer isn’t generated, edit the “/etc/resolv.conf” file, add the below lines, and make sure to make these changes permanent:

search <IPA_DOMAIN>
nameserver <AD DC IP Address>

Step 4: Establish and Verify the Cross-Forest trust

After successfully configuring DNS, it is time to establish and verify the cross-forest trust. The first and foremost thing to do is ensure that the ipa-adtrust-install command on the IPA master runs as IPA clients connect to it (as shown in the screenshot below).

Now establish the cross-forest trust between the Active Directory and IPA servers using the Active Directory administrator credentials, and here is the command for it.

ipa trust-add --two-way=true --type=ad ad_domain --admin Administrator --password

The above command generates a two-way forest trust on the IPA side, and the “–admin” is a member of the Domain Admins group. However, you can generate a one-way forest trust by removing the “–two-way=true” option from the command.

If you don’t have the AD Admin credentials, you can achieve the two-way forest trust on the IPA side using the below command. However, this command requires manual trust validation on the AD side, and you need to enter the trust shared secret when prompted:

ipa trust-add --two-way=true --type=ad "ad_domain" --trust-secret

Step 5: Configure Kerberos on IPA 

Many applications query the Kerberos library to confirm that a POSIX account may be mapped to the Kerberos principal. Some applications go one step further and request the OS’s canonical name for the POSIX account that the Kerberos library returned.

When logging on using a Kerberos ticket over SSH, note that OpenSSH compares the principal’s name untouched. At the same time, SSSD lowercase the realm part, resulting in the real user name being Administrator@realm rather than Administrator@realm.

We need to define some rules for mapping Kerberos principals to system user names as follows:

• Kerberos principals use the format name@REALM, where REALM must be capitalized in Linux. 
• SSSD always gives AD users fully qualified (name@domain) POSIX accounts. 
• When SSSD is asked to return POSIX account names, it normalizes all POSIX accounts to lowercase (name@domain).

To map the Kerberos principals to system user names, the “/etc/krb5.conf” on the IPA server must be manually edited to permit Kerberos authentication.

Here are the lines that are needed to be added in the krb5 config file, and the command for opening the file on the vim editor is as follows:

sudo vim /etc/krb5.conf
[realms]
IPA_DOMAIN = {
....
auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/ auth_to_local = DEFAULT
 }  

Once you have made changes to the krb5 config file, restart the KDC and SSSD service using the below commands for the changes to take effect:

service krb5kdc restart
service sssd restart 

Step 6: Allow Access for Users From the AD Domain to Protected Resources

Users from trusted domains must be explicitly mapped to the IPA groups to access the protected resources in the IPA realm. For this purpose, we can achieve the mapping in two steps.

1. Create External and POSIX Groups for Trusted Domain Users

• Here is the command to create an external group in IPA for trusted domain admins;

ipa group-add --desc='ad_domain admins external map' ad_admins_external --external

• Now create a POSIX group for the external ad_admins_external group using the below command;

ipa group-add --desc='ad_domain admins' ad_admins

• The final step in this approach is to add the trusted domain users to the external group, and here is the command for it;

ipa group-add-member ad_admins_external --external 'ad_netbios\Domain Admins'

The above commands summarize everything needed to map trusted domain users to the IPA groups explicitly.

2. Add External Group to POSIX Group

Coming to the second mapping step, the “ad_admins_external group” members must be associated with the ad_admins POSIX group. Here is the command to achieve it.

 ipa group-add-member ad_admins --groups ad_admins_external

After following the two mapping steps, you can see all the users on the IPA console. If you don’t find any, try to refresh the IPA server, and if there are not yet displayed, repeat both mapping steps.

Step 7: Testing the Cross-Forest Trust

With mapping trusted domain users to the IPA group, the only thing left to do is check if the trust is established successfully between the IPA and AD. For this purpose, consider a user from the AD server – [email protected].

Once done, try using the mentioned user to log in to any server connected to IPA. If there are no errors and the login is successful, you have learned how to establish trust between IPA and Active Directory.

Here are the commands to perform the above test:

ssh [email protected]@localhost
whoami  

That brings us to the end of this guide. Through this article we have covered how to establish trust between IPA and Active Directory and the importance of doing so. Additionally, we have divided the process into multiple sections and provided a detailed guide for each to make it easier for you to follow.

With this process, you can achieve seamless integration and efficient identity and access management. Also, you can streamline processes, enhance security, and enable your organization to manage identities and access across its systems effectively.

If this guide helped you, please share it.