Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

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

If you have client systems in a DNS domain controlled by Active Directory (AD) and you require those clients to join the IdM Server to benefit from its RHEL features, you can configure users to access a client using a host name from the AD DNS domain.

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.

Password authentication is the only authentication method that is available for users to access resources on IdM clients if the IdM clients are in an Active Directory DNS domain. Follow this procedure to configure your client 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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.

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
    Copy to Clipboard Toggle word wrap

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

If you require Kerberos single sign-on to access resources on the IdM client, the client must be within the IdM DNS domain, for example idm-client.idm.example.com. You must create a CNAME record idm-client.ad.example.com in the Active Directory DNS domain pointing to the A/AAAA record of the IdM client.

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

  • On the IdM client, disable the strict checks on what Kerberos principal is used to target the Kerberos server by setting the following option in the [libdefaults] section of the /etc/krb5.conf configuration file: 

    ignore_acceptor_hostname = true
    Copy to Clipboard Toggle word wrap

After you disabled strict Kerberos principal checks on your IdM client, 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.

Follow this procedure to 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. Create a new host object on the IdM server: 

    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
    Copy to Clipboard Toggle word wrap

    Use the --force option, because the host name is a CNAME and not an A/AAAA record.

  2. On the IdM server, allow the IdM DNS host name to manage the Active Directory host entry in the IdM database: 

    [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
      --hosts=idm-client.idm.example.com
    Copy to Clipboard Toggle word wrap

  3. Your can now request an SSL certificate for your IdM client with the dNSName extension record for its host name within the Active Directory DNS domain: 

    [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
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

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.

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

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

Theme

© 2025 Red Hat