Este conteúdo não está disponível no idioma selecionado.

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.

8.1. Configuring an IdM client without Kerberos single sign-on

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.

8.2. Requesting SSL certificates without single sign-on

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

8.3. Configuring an IdM client with Kerberos single sign-on

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.

8.4. Requesting SSL certificates with single sign-on

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

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red Hat
Voltar ao topo