Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 8. Configuring IdM clients in an Active Directory DNS domain

While IdM clients should ideally reside in a separate DNS zone, you can join clients located in an Active Directory (AD) DNS domain to IdM. This enables RHEL-specific features for hosts within the AD namespace.

Important

This configuration is not recommended and has limitations. Always deploy IdM clients in a DNS zone separate from the ones owned by AD and access IdM clients using their IdM host names.

Your IdM client configuration depends on whether you require single sign-on with Kerberos.

When an IdM client resides in an Active Directory (AD) DNS domain, password-based authentication is the only supported authentication method. Join the client to the IdM realm manually without Kerberos single sign-on.

Procedure

  1. Install the IdM client with the --domain=IPA_DNS_Domain option to ensure the System Security Services Daemon (SSSD) can communicate with the IdM servers: 

    [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com

    This option disables the SRV record auto-detection for the Active Directory DNS domain.

  2. Open the /etc/krb5.conf configuration file and locate the existing mapping for the Active Directory domain in the [domain_realm] section. 

    .ad.example.com = IDM.EXAMPLE.COM
ad.example.com = IDM.EXAMPLE.COM

  3. Replace both lines with an entry mapping the fully qualified domain name (FQDN) of the Linux clients in the Active Directory DNS zone to the IdM realm: 

    idm-client.ad.example.com = IDM.EXAMPLE.COM

    By replacing the default mapping, you prevent Kerberos from sending its requests for the Active Directory domain to the IdM Kerberos Distribution Center (KDC). Instead Kerberos uses auto-discovery through SRV DNS records to locate the KDC.

Request SSL certificates using certmonger for Identity Management (IdM) clients without Kerberos SSO to enable secure SSL-based services.

After you configure an IdM client without Kerberos single sign-on, you can set up SSL-based services.

SSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database.

In this setup, where single sign-on is not enabled, IdM already contains a host object for the FQDN in its database. You can use certmonger to request a certificate using the FQDN.

Prerequisites

  • An IdM client configured without Kerberos single-sign on.

Procedure

  • Use certmonger to request a certificate using the FQDN: 

    [root@idm-client.ad.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=ipa-client.ad.example.com \
      -D ipa-client.ad.example.com \
      -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

    The certmonger service uses the default host key stored in the /etc/krb5.keytab file to authenticate to the IdM Certificate Authority (CA).

To enable Kerberos single sign-on (SSO) for IdM clients across DNS domains, you must map a CNAME record from the Active Directory (AD) domain to the IdM client’s A/AAAA record and configure the client to allow flexible principal acceptance.

For Kerberos-based application servers, MIT Kerberos supports a method to allow the acceptance of any host-based principal available in the application’s keytab.

Procedure

  1. Configure Kerberos by editing the /etc/krb5.conf file on the IdM client. In the [libdefaults] section, set ignore_acceptor_hostname to true. This allows the application to accept any host-based principal in its keytab: 

    ignore_acceptor_hostname = true
  2. Ensure a CNAME record exists in the Active Directory DNS, for example idm-client.ad.example.com, pointing to the IdM client’s A/AAAA record in the IdM DNS domain.

To secure services using Kerberos SSO, your SSL certificate must include both the host’s A/AAAA and CNAME records. Since IdM only issues certificates to database host objects, you must manually create and link a host entry for the CNAME alias.

Create a host object for ipa-client.example.com in IdM and make sure the real IdM machine’s host object is able to manage this host.

Prerequisites

  • You have disabled the strict checks on what Kerberos principal is used to target the Kerberos server.

Procedure

  1. On the IdM server, create a host entry for the AD-side alias. Use --force because the name resolves to a CNAME rather than an A/AAAA record. 

    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force

  2. To allow the physical IdM host to manage the new alias entry in the IdM database, grant management permissions to the host. 

    [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
      --hosts=idm-client.idm.example.com

  3. On the IdM client, use ipa-getcert to request the certificate. Ensure that you include both the FQDN and the CNAME using the -D flags. 

    [root@idm-client.idm.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=`hostname --fqdn` \
      -D `hostname --fqdn` \
      -D idm-client.ad.example.com \
      -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

    In SSL/TLS, the client checks the Subject Alternative Name (SAN) field. By using -D twice, you are populating that SAN field with both names so that no matter which URL the user hits, the certificate remains valid.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top