Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 2. Preparing the system for IdM server installation

The following sections list the requirements to install an Identity Management (IdM) server. Before the installation, verify your system meets these requirements.

2.1. Prerequisites

  • You need root privileges to install an Identity Management (IdM) server on your host.

2.2. Hardware recommendations

RAM is the most important hardware feature to size properly. Make sure your system has enough RAM available. Typical RAM requirements are:

  • For 10,000 users and 100 groups: at least 4 GB of RAM and 4 GB swap space
  • For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space

For larger deployments, it is more effective to increase the RAM than to increase disk space because much of the data is stored in cache. In general, adding more RAM leads to better performance for larger deployments due to caching.


A basic user entry or a simple host entry with a certificate is approximately 5—​10 kB in size.

2.3. Custom configuration requirements for IdM

Install an Identity Management (IdM) server on a clean system without any custom configuration for services such as DNS, Kerberos, Apache, or Directory Server.

The IdM server installation overwrites system files to set up the IdM domain. IdM backs up the original system files to /var/lib/ipa/sysrestore/. When an IdM server is uninstalled at the end of the lifecycle, these files are restored.

IPv6 requirements in IdM

The IdM system must have the IPv6 protocol enabled in the kernel and localhost (::1) is able to use it. If IPv6 is disabled, then the CLDAP plug-in used by the IdM services fails to initialize.


IPv6 does not have to be enabled on the network. It is possible to enable IPv6 stack without enabling IPv6 addresses if required.

Support for encryption types in IdM

Red Hat Enterprise Linux (RHEL) uses Version 5 of the Kerberos protocol, which supports encryption types such as Advanced Encryption Standard (AES), Camellia, and Data Encryption Standard (DES).

List of supported encryption types

While the Kerberos libraries on IdM servers and clients might support more encryption types, the IdM Kerberos Distribution Center (KDC) only supports the following encryption types:

  • aes256-cts:normal
  • aes256-cts:special (default)
  • aes128-cts:normal
  • aes128-cts:special (default)
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special
  • camellia128-cts-cmac:normal
  • camellia128-cts-cmac:special
  • camellia256-cts-cmac:normal
  • camellia256-cts-cmac:special

RC4 encryption types are disabled by default

The following RC4 encryption types have been deprecated and disabled by default in RHEL 8, as they are considered less secure than the newer AES-128 and AES-256 encryption types:

  • arcfour-hmac:normal
  • arcfour-hmac:special

For more information about manually enabling RC4 support for compatibility with legacy Active Directory environments, see Ensuring support for common encryption types in AD and RHEL.

Support for DES and 3DES encryption has been removed

Due to security reasons, support for the DES algorithm was deprecated in RHEL 7. The recent rebase of Kerberos packages in RHEL 8.3.0 removes support for single-DES (DES) and triple-DES (3DES) encryption types from RHEL 8.


Standard RHEL 8 IdM installations do not use DES or 3DES encryption types by default and are unaffected by the Kerberos upgrade.

If you manually configured any services or users to only use DES or 3DES encryption (for example, for legacy clients), you might experience service interruptions after updating to the latest Kerberos packages, such as:

  • Kerberos authentication errors
  • unknown enctype encryption errors
  • KDCs with DES-encrypted Database Master Keys (K/M) fail to start

Red Hat recommends you do not use DES or 3DES encryption in your environment.


You only need to disable DES and 3DES encryption types if you configured your environment to use them.

Support for system-wide cryptographic policies in IdM

IdM uses the DEFAULT system-wide cryptographic policy. This policy offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long. This policy does not allow DES, 3DES, RC4, DSA, TLS v1.0, and other weaker algorithms.


You cannot install an IdM server while using the FUTURE system-wide cryptographic policy. When installing an IdM server, ensure you are using the DEFAULT system-wide cryptographic policy.

Additional Resources

2.4. FIPS compliance

With RHEL 8.3.0 or later, you can install a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) 140 mode enabled.

To install IdM in FIPS mode, first enable FIPS mode on the host, then install IdM. The IdM installation script detects if FIPS is enabled and configures IdM to only use encryption types that are compliant with the FIPS 140 standard:

  • aes256-cts:normal
  • aes256-cts:special
  • aes128-cts:normal
  • aes128-cts:special
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special

For an IdM environment to be FIPS-compliant, all IdM replicas must have FIPS mode enabled.

Red Hat recommends that you enable FIPS mode in IdM clients as well, especially if you might promote those clients to IdM replicas. Ultimately, it is up to administrators to determine how they meet FIPS requirements; Red Hat does not enforce FIPS criteria.

Migration to FIPS-compliant IdM

You cannot migrate an existing IdM installation from a non-FIPS environment to a FIPS-compliant installation. This is not a technical problem but a legal and regulatory restriction.

To operate a FIPS-compliant system, all cryptographic key material must be created in FIPS mode. Furthermore, the cryptographic key material must never leave the FIPS environment unless it is securely wrapped and never unwrapped in non-FIPS environments.

If your scenario requires a migration of a non-FIPS IdM realm to a FIPS-compliant one, you must:

  1. create a new IdM realm in FIPS mode
  2. perform data migration from the non-FIPS realm to the new FIPS-mode realm with a filter that blocks all key material

The migration filter must block:

  • KDC master key, keytabs, and all related Kerberos key material
  • user passwords
  • all certificates including CA, service, and user certificates
  • OTP tokens
  • SSH keys and fingerprints
  • all vault entries
  • AD trust-related key material

Effectively, the new FIPS installation is a different installation. Even with rigorous filtering, such a migration may not pass a FIPS 140 certification. Your FIPS auditor may flag this migration.

Additional Resources

2.5. Support for cross-forest trust with FIPS mode enabled

To establish a cross-forest trust with an Active Directory (AD) domain while FIPS mode is enabled, you must meet the following requirements:

  • IdM servers are on RHEL 8.4.0 or later.
  • You must authenticate with an AD administrative account when setting up a trust. You cannot establish a trust using a shared secret while FIPS mode is enabled.

RADIUS authentication is not FIPS-compliant as the RADIUS protocol uses the MD5 hash function to encrypt passwords between client and server and, in FIPS mode, OpenSSL disables the use of the MD5 digest algorithm. However, if the RADIUS server is running on the same host as the IdM server, you can work around the problem and enable MD5 by performing the steps described in How to configure FreeRADIUS authentication in FIPS mode.

Additional Resources

2.6. Time service requirements for IdM

The following sections discuss using chronyd to keep your IdM hosts in sync with a central time source:

2.6.1. How IdM uses chronyd for synchronization

You can use chronyd to keep your IdM hosts in sync with a central time source as described here.

Kerberos, the underlying authentication mechanism in IdM, uses time stamps as part of its protocol. Kerberos authentication fails if the system time of an IdM client differs by more than five minutes from the system time of the Key Distribution Center (KDC).

To ensure that IdM servers and clients stay in sync with a central time source, IdM installation scripts automatically configure chronyd Network Time Protocol (NTP) client software.

If you do not pass any NTP options to the IdM installation command, the installer searches for _ntp._udp DNS service (SRV) records that point to the NTP server in your network and configures chrony with that IP address. If you do not have any _ntp._udp SRV records, chronyd uses the configuration shipped with the chrony package.


Because ntpd has been deprecated in favor of chronyd in RHEL 8, IdM servers are no longer configured as Network Time Protocol (NTP) servers and are only configured as NTP clients. The RHEL 7 NTP Server IdM server role has also been deprecated in RHEL 8.

2.6.2. List of NTP configuration options for IdM installation commands

You can use chronyd to keep your IdM hosts in sync with a central time source.

You can specify the following options with any of the IdM installation commands (ipa-server-install, ipa-replica-install, ipa-client-install) to configure chronyd client software during setup.

Table 2.1. List of NTP configuration options for IdM installation commands



Use it to specify one NTP server. You can use it multiple times to specify multiple servers.


Use it to specify a pool of multiple NTP servers resolved as one hostname.

-N, --no-ntp

Do not configure, start, or enable chronyd.

2.6.3. Ensuring IdM can reference your NTP time server

This procedure verifies you have the necessary configurations in place for IdM to be able to synchronize with your Network Time Protocol (NTP) time server.


  • You have configured an NTP time server in your environment. In this example, the hostname of the previously configured time server is


  1. Perform a DNS service (SRV) record search for NTP servers in your environment.

    [user@server ~]$ dig +short -t SRV
    0 100 123
  2. If the previous dig search does not return your time server, add a _ntp._udp SRV record that points to your time server on port 123. This process depends on your DNS solution.

Verification steps

  • Verify that DNS returns an entry for your time server on port 123 when you perform a search for _ntp._udp SRV records.

    [user@server ~]$ dig +short -t SRV
    0 100 123

2.6.4. Additional resources

2.7. Host name and DNS requirements for IdM

The host name and DNS requirements for server and replica systems are outlined below and also how to verify that the systems meet the requirements.

These requirements apply to all Identity Management (IdM) servers, those with integrated DNS and those without integrated DNS.


DNS records are vital for nearly all IdM domain functions, including running LDAP directory services, Kerberos, and Active Directory integration. Be extremely cautious and ensure that:

  • You have a tested and functional DNS service available
  • The service is properly configured

This requirement applies to IdM servers with and without integrated DNS.

Verify the server host name

The host name must be a fully qualified domain name, such as


Do not use single-label domain names, for example .company: the IdM domain must be composed of one or more subdomains and a top level domain, for example or

The fully qualified domain name must meet the following conditions:

  • It is a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, such as underscores (_), in the host name cause DNS failures.
  • It is all lower-case. No capital letters are allowed.
  • It does not resolve to the loopback address. It must resolve to the system’s public IP address, not to

To verify the host name, use the hostname utility on the system where you want to install:

# hostname

The output of hostname must not be localhost or localhost6.

Verify the forward and reverse DNS configuration
  1. Obtain the IP address of the server.

    1. The ip addr show command displays both the IPv4 and IPv6 addresses. In the following example, the relevant IPv6 address is 2001:DB8::1111 because its scope is global:

      [root@server ~]# ip addr show
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
      	inet brd scope global dynamic eth0
      		valid_lft 106694sec preferred_lft 106694sec
      	inet6 2001:DB8::1111/32 scope global dynamic
       		valid_lft 2591521sec preferred_lft 604321sec
      	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
      	       valid_lft forever preferred_lft forever
  2. Verify the forward DNS configuration using the dig utility.

    1. Run the command dig +short A. The returned IPv4 address must match the IP address returned by ip addr show:

      [root@server ~]# dig +short A
    2. Run the command dig +short AAAA. If it returns an address, it must match the IPv6 address returned by ip addr show:

      [root@server ~]# dig +short AAAA

      If dig does not return any output for the AAAA record, it does not indicate incorrect configuration. No output only means that no IPv6 address is configured in DNS for the system. If you do not intend to use the IPv6 protocol in your network, you can proceed with the installation in this situation.

  3. Verify the reverse DNS configuration (PTR records). Use the dig utility and add the IP address.

    If the commands below display a different host name or no host name, the reverse DNS configuration is incorrect.

    1. Run the command dig +short -x IPv4_address. The output must display the server host name. For example:

      [root@server ~]# dig +short -x
    2. If the command dig +short -x AAAA in the previous step returned an IPv6 address, use dig to query the IPv6 address too. The output must display the server host name. For example:

      [root@server ~]# dig +short -x 2001:DB8::1111

      If dig +short AAAA in the previous step did not display any IPv6 address, querying the AAAA record does not output anything. In this case, this is normal behavior and does not indicate incorrect configuration.


      If a reverse DNS (PTR record) search returns multiple host names, httpd and other software associated with IdM may show unpredictable behavior. Red Hat strongly recommends configuring only one PTR record per IP.

Verify the standards-compliance of DNS forwarders (required for integrated DNS only)

Ensure that all DNS forwarders you want to use with the IdM DNS server comply with the Extension Mechanisms for DNS (EDNS0) and DNS Security Extensions (DNSSEC) standards. To do this, inspect the output of the following command for each forwarder separately:

$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA

The expected output displayed by the command contains the following information:

  • status: NOERROR
  • flags: ra
  • EDNS flags: do
  • The RRSIG record must be present in the ANSWER section

If any of these items is missing from the output, inspect the documentation for your DNS forwarder and verify that EDNS0 and DNSSEC are supported and enabled. In the latest versions of the BIND server, the dnssec-enable yes; option must be set in the /etc/named.conf file.

Example of the expected output produced by dig:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096

. 31679 IN SOA 2015100701 1800 900 604800 86400
. 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
Verify the /etc/hosts file

Verify that the /etc/hosts file fulfills one of the following conditions:

  • The file does not contain an entry for the host. It only lists the IPv4 and IPv6 localhost entries for the host.
  • The file contains an entry for the host and the file fulfills all the following conditions:

    • The first two entries are the IPv4 and IPv6 localhost entries.
    • The next entry specifies the IdM server IPv4 address and host name.
    • The FQDN of the IdM server comes before the short name of the IdM server.
    • The IdM server host name is not part of the localhost entry.

    The following is an example of a correctly configured /etc/hosts file:   localhost localhost.localdomain \
localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain \
localhost6 localhost6.localdomain6	server
2001:DB8::1111	server

2.8. Port requirements for IdM

Identity Management (IdM) uses several ports to communicate with its services. These ports must be open and available for incoming connections to the IdM server for IdM to work. They must not be currently used by another service or blocked by a firewall.

Table 2.2. IdM ports



80, 443



389, 636



88, 464




TCP and UDP (optional)


IdM uses ports 80 and 389. This is a secure practice because of the following safeguards:

  • IdM normally redirects requests that arrive on port 80 to port 443. Port 80 (HTTP) is only used to provide Online Certificate Status Protocol (OCSP) responses and Certificate Revocation Lists (CRL). Both are digitally signed and therefore secured against man-in-the-middle attacks.
  • Port 389 (LDAP) uses STARTTLS and Generic Security Services API (GSSAPI) for encryption.

In addition, ports 8080, 8443, and 749 must be free as they are used internally. Do not open these ports and instead leave them blocked by a firewall.

Table 2.3. firewalld services

Service nameFor details, see:







2.9. Opening the ports required by IdM


  1. Verify that the firewalld service is running.

    • To find out if firewalld is currently running:

      # systemctl status firewalld.service
    • To start firewalld and configure it to start automatically when the system boots:

      # systemctl start firewalld.service
      # systemctl enable firewalld.service
  2. Open the required ports using the firewall-cmd utility. Choose one of the following options:

    1. Add the individual ports to the firewall by using the firewall-cmd --add-port command. For example, to open the ports in the default zone:

      # firewall-cmd --permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp}
    2. Add the firewalld services to the firewall by using the firewall-cmd --add-service command. For example, to open the ports in the default zone:

      # firewall-cmd --permanent --add-service={freeipa-4,dns}

      For details on using firewall-cmd to open ports on a system, see the firewall-cmd(1) man page.

  3. Reload the firewall-cmd configuration to ensure that the change takes place immediately:

    # firewall-cmd --reload

    Note that reloading firewalld on a system in production can cause DNS connection time outs. If required, to avoid the risk of time outs and to make the changes persistent on the running system, use the --runtime-to-permanent option of the firewall-cmd command, for example:

    # firewall-cmd --runtime-to-permanent
  4. Optional. To verify that the ports are available now, use the nc, telnet, or nmap utilities to connect to a port or run a port scan.

Note that you also have to open network-based firewalls for both incoming and outgoing traffic.

2.10. Installing packages required for an IdM server

In RHEL8, the packages necessary for installing an Identity Management (IdM) server are shipped as a module. The IdM server module stream is called the DL1 stream, and you need to enable this stream before downloading packages from this stream. The following procedure shows how to download the packages necessary for setting up the IdM environment of your choice.


  • You have a newly installed RHEL system.
  • You have made the required repositories available:

    For details on how to enable and disable specific repositories using RHSM, see Configuring options in Red Hat Subscription Manager.

    • If your RHEL system is running in the cloud, skip the registration. The required repositories are already available via the Red Hat Update Infrastructure (RHUI).
  • You have not previously enabled an IdM module stream.


  1. Enable the idm:DL1 stream:

    # yum module enable idm:DL1
  2. Switch to the RPMs delivered through the idm:DL1 stream:

    # yum distro-sync
  3. Choose one of the following options, depending on your IdM requirements:

    • To download the packages necessary for installing an IdM server without an integrated DNS:

      # yum module install idm:DL1/server
    • To download the packages necessary for installing an IdM server with an integrated DNS:

      # yum module install idm:DL1/dns
    • To download the packages necessary for installing an IdM server that has a trust agreement with Active Directory:

      # yum module install idm:DL1/adtrust
    • To download the packages from multiple profiles, for example the adtrust and dns profiles:

      # yum module install idm:DL1/{dns,adtrust}
    • To download the packages necessary for installing an IdM client:

      # yum module install idm:DL1/client

When switching to a new module stream once you have already enabled a different stream and downloaded packages from it, you need to first explicitly remove all the relevant installed content and disable the current module stream before enabling the new module stream. Trying to enable a new stream without disabling the current one results in an error. For details on how to proceed, see Switching to a later stream.


While it is possible to install packages from modules individually, be aware that if you install any package from a module that is not listed as "API" for that module, it is only going to be supported by Red Hat in the context of that module. For example, if you install bind-dyndb-ldap directly from the repository to use with your custom 389 Directory Server setup, any problems that you have will be ignored unless they occur for IdM, too.

2.11. Setting the correct file mode creation mask for IdM installation

The Identity Management (IdM) installation process requires that the file mode creation mask (umask) is set to 0022 for the root account. This allows users other than root to read files created during the installation. If a different umask is set, the installation of an IdM server will display a warning. If you continue with the installation, some functions of the server will not perform properly. For example, you will be unable to install an IdM replica from this server. After the installation, you can set the umask back to its original value.


  • You have root privileges.


  1. (Optional) Display the current umask:

    # umask
  2. Set the umask to 0022:

    # umask 0022
  3. (Optional) After the IdM installation is complete, set the umask back to its original value:

    # umask 0027

2.12. Ensuring that fapolicyd rules do not block IdM installation and operation

If you are using the fapolicyd software framework on your RHEL host to control the execution of applications based on a user-defined policy, the installation of the Identity Management (IdM) server can fail. As the installation and operation requires the Java program to complete successfully, ensure that Java and Java classes are not blocked by any fapolicyd rules.

For more information, see the fapolicy restrictions causing IdM installation failures KCS solution.

2.13. Options for the IdM installation commands

Commands such as ipa-server-install, ipa-replica-install, ipa-dns-install and ipa-ca-install have numerous options you can use to supply additional information for an interactive installation. You can also use these options to script an unattended installation.

The following tables display some of the most common options for different components. Options for a specific component are shared across multiple commands. For example, you can use the --ca-subject option with both the ipa-ca-install and ipa-server-install commands.

For an exhaustive list of options, see the ipa-server-install(1), ipa-replica-install(1), ipa-dns-install(1) and ipa-ca-install(1) man pages.

Table 2.4. General options: available for ipa-server-install and ipa-replica-install


-d, --debug

Enables debug logging for more verbose output.

-U, --unattended

Enables an unattended installation session that does not prompt for user input.

The fully-qualified domain name of the IdM server machine. Only numbers, lowercase alphabetic characters, and hyphens (-) are allowed.


Specifies the IP address of the server. This option only accepts IP addresses associated with the local interface.

--dirsrv-config-file <LDIF_file_name>

The path to an LDIF file used to modify the configuration of the directory server instance.


The name of the LDAP server domain to use for the IdM domain. This is usually based on the IdM server’s hostname.

-p <directory_manager_password>

The password of the superuser, cn=Directory Manager, for the LDAP service.

-a <ipa_admin_password>

The password for the admin IdM administrator account to authenticate to the Kerberos realm. For ipa-replica-install, use -w instead.


The name of the Kerberos realm to create for the IdM domain in uppercase, such as EXAMPLE.COM. For ipa-replica-install, this specifies the name of a Kerberos realm of an existing IdM deployment.


Tells the installation script to set up a DNS service within the IdM domain.


Install and configure a CA on this replica. If a CA is not configured, certificate operations are forwarded to another replica with a CA installed. For ipa-server-install, a CA is installed by default and you do not need to use this option.

Table 2.5. CA options: available for ipa-ca-install and ipa-server-install



Specifies the CA certificate subject Distinguished Name (default: CN=Certificate Authority,O=REALM.NAME). Relative Distinguished Names (RDN) are in LDAP order, with the most specific RDN first.


Specifies the subject base for certificates issued by IdM (default O=REALM.NAME). Relative Distinguished Names (RDN) are in LDAP order, with the most specific RDN first.


Generates a certificate signing request to be signed by an external CA.


Specifies the signing algorithm of the IdM CA certificate. Possible values are SHA1withRSA, SHA256withRSA, SHA512withRSA . The default is SHA256withRSA. Use this option with --external-ca if the external CA does not support the default signing algorithm.

Table 2.6. DNS options: available for ipa-dns-install, or for ipa-server-install and ipa-replica-install when using --setup-dns



Specifies a DNS forwarder to use with the DNS service. To specify more than one forwarder, use this option multiple times.


Uses root servers with the DNS service instead of forwarders.


Does not create a reverse DNS zone when the DNS domain is set up. If a reverse DNS zone is already configured, then that existing reverse DNS zone is used.

If this option is not used, then the default value is true. This instructs the installation script to configure reverse DNS.

Additional resources

  • ipa-server-install(1) man page
  • ipa-replica-install(1) man page
  • ipa-dns-install(1) man page
  • ipa-ca-install(1) man page