RedHat IDM (FreeIPA) Integration with Active Directory

Posted on by

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>