RedHat IDM (FreeIPA) Integration with Active Directory

This tutorial explains the procedure to create a trust between the Identity?Management IdM server and Active Directory (AD), where both servers are located in the same forest.

Prerequisites

  • AD is installed with a domain controller on it.
  • The IdM server is installed and running with integrated DNS.
  • 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.

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.

 

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.

 

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.

 

Configuring a DNS forward zone in the IdM Web UI

This section describes how to add a new DNS forward zone to the Identity?Management (IdM) server 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.

Procedure

  1. Log in to the IdM Web UI with administrator privileges.
  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.
  1. Click on the?Add?button.
  2. In the?Add DNS forward zone?dialog box, add a zone name.
  3. In the?Zone forwarders?item, click on the?Add?button.
  4. In the?Zone forwarders?field, add the IP address of the server for which you want to create the new forward zone.
  5. Click on the?Add?button.

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.

Note

The Web UI might display a warning about a DNSSEC validation failure after adding a new 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:

  1. Choose the appropriate configuration file to edit:
    • If your IdM server is using RHEL 8.0 or RHEL 8.1, open the?/etc/named.conf?file.
    • If your IdM server is using RHEL 8.2 or later, open the?/etc/named/ipa-options-ext.conf?file.
  2. Add the following DNSSEC parameters:
  1. dnssec-enable no;

dnssec-validation no;

  1. Save and close the configuration file.
  2. Restart the DNS service:

# systemctl restart named-pkcs11

 

Verification steps

  • Use the?nslookup?command with the name of the remote DNS server:
  • $ nslookup ad.example.com
  • Server: 168.122.2
  • Address: 168.122.2#53
  • No-authoritative answer:
  • Name: example.com

Address:?????? 192.168.122.3

If the domain forwarding is configured correctly, the?nslookup?request displays an IP address of the remote DNS server.

 

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.

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? (not the server name), for example,?idm.example.com
  5. Save the settings.

 

Verifying the DNS configuration

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

Procedure

  1. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.
  1. [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
  2. 0 100 88 server.idm.example.com.
  3. [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.

 

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.

?

Preparing the IdM server for the trust

Before you can establish a trust with AD, you must prepare the IdM domain using the?ipa-adtrust-install?utility on an IdM server.

Note

Any system where you run the?ipa-adtrust-install?command automatically becomes an AD trust controller.

?Procedure

  1. Install the required packages:

[root@ipaserver ~]# yum install ipa-server-trust-ad samba-client

  1. Authenticate as the IdM administrative user:

[root@ipaserver ~]# kinit admin

  1. 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.

  1. The script prompts you that the?/etc/samba/smb.conf?already exists and will be rewritten:
  1. WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.

Do you wish to continue? [no]: yes

  1. 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:
  2. Do you want to enable support for trusted domains in Schema Compatibility plugin?
  3. 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

  1. When prompted, enter the NetBIOS name for the IdM domain or press?Enter?to accept the name suggested:
  1. Trust is configured but no NetBIOS domain name found, setting it now.
  2. Enter the NetBIOS name for the IPA domain.
  3. Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
  4. Example: EXAMPLE.
  5. NetBIOS domain name [IDM]:
  1. 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

This is a resource-intensive task, so if you have a high number of users, you can run this at another time.

  1. Restart the?ipa?service:

[root@ipaserver ~]# ipactl restart

 

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.

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.
  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.
  8. Click?Add.

 

Verification steps

  • 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.

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

 

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

  1. 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.

 

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.

Procedure

  1. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.
  1. [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
  2. 0 100 88 server.idm.example.com.
  3. [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.

  1. Run a DNS query for the Kerberos and LDAP over TCP service records to verify that IdM is able to resolve service records for AD:
  1. [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
  2. 0 100 88 addc1.ad.example.com.
  3. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.

0 100 389 addc1.ad.example.com.

.

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.

Procedure

  1. On the AD server, set the?nslookup.exe?utility to look up service records.
  1. C:\>nslookup.exe

> set type=SRV

  1. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
  1. > _kerberos._udp.idm.example.com.
  2. _udp.idm.example.com. SRV service location:
  3. priority??????????????? = 0
  4. weight????????????????? = 100
  5. port??????????????????? = 88
  6. svr hostname?? = server.idm.example.com
  7. > _ldap._tcp.idm.example.com
  8. _tcp.idm.example.com SRV service location:
  9. priority = 0
  10. weight = 100
  11. port = 389

svr hostname?? = server.idm.example.com

  1. Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name.
  1. C:\>nslookup.exe

> set type=TXT

> _kerberos.idm.example.com.

idm.example.com. text =

“IDM.EXAMPLE.COM”

  1. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.
  1. C:\>nslookup.exe

> set type=SRV

> _kerberos._udp.dc._msdcs.idm.example.com.

_udp.dc._msdcs.idm.example.com. SRV service location:

priority = 0

weight = 100

port = 88

svr hostname = server.idm.example.com

  1. > _ldap._tcp.dc._msdcs.idm.example.com.
  2. _tcp.dc._msdcs.idm.example.com. SRV service location:
  3. priority = 0
  4. weight = 100
  5. port = 389

svr hostname = server.idm.example.com

Active Directory only expects to discover domain controllers that can respond to AD-specific protocol requests, such as other AD domain controllers and IdM trust controllers. Use the?ipa-adtrust-install?tool to promote an IdM server to a trust controller, and you can verify which servers are trust controllers with the?ipa server-role-find –role ‘AD trust controller’?command.

  1. Verify that AD services are resolvable from the AD server.
  1. C:\>nslookup.exe

> set type=SRV

  1. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
  1. > _kerberos._udp.dc._msdcs.ad.example.com.

_udp.dc._msdcs.ad.example.com. SRV service location:

priority = 0

weight = 100

port = 88

  1. svr hostname = addc1.ad.example.com
  2. > _ldap._tcp.dc._msdcs.ad.example.com.
  3. _tcp.dc._msdcs.ad.example.com. SRV service location:
  4. priority = 0
  5. weight = 100
  6. port = 389

svr hostname = addc1.ad.example.com

 

Creating IPA Groups and adding AD users to it:

To map an AD user to local?IPA?posix group follow steps needs to be followed:

Login into IPA Server as?root?user.

Kinit on IPA Server as?admin?user.

kinit admin

  1. Create an external group in?IPA.

ipa group-add –desc=’IPA External Test Group’ tgroup_external –external

  1. Create posix group in?IPA.

ipa group-add –desc=’IPA Test Group’ tgroup

  1. Map?IPAexternal group to local group.

# ipa group-add-member tgroup –groups tgroup_external

  1. Map AD user to?IPAexternal group.

# ipa group-add-member tgroup_external –external ‘tuser@example.com’

  1. Check if?idcommand for user?tuser@example.comis showing group?tgroup.

# id tuser@example.com

 

uid=1102601115(tuser@example.com) gid=1102601115(tuser@example.com) groups=1102601115(tuser@example.com), 542400009(tgroup), 1102600513(domain users@example.com)

Below is to check the groups

# ipa group-show <adgroup_external>