Chapter 1. Preparing the system for IdM server installation

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

1.1. Authorization requirements when installing an IdM server

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

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

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

1.3.1. IPv6 requirements in IdM

The IdM system must have the IPv6 protocol enabled in the kernel. 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.

1.3.2. 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 disabled by default in RHEL 9, 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 on 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. Single-DES (DES) and triple-DES (3DES) encryption types were removed from RHEL 8 and are not used in RHEL 9.

1.3.3. FIPS compliance

You can install a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) mode enabled.

To install IdM with FIPS, 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 FIPS 140-2:

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

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 authenticate with an AD administrative account. You cannot establish a trust using a shared secret while FIPS mode is enabled.


RADIUS authentication is not FIPS compliant. Do not install IdM on a server with FIPS mode enabled if you require RADIUS authentication.

Additional Resources

1.4. Time service requirements for Idm

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

1.4.1. How IdM uses chronyd for synchronization

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.

1.4.2. List of NTP configuration options for IdM installation commands

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

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

1.4.4. Additional resources

1.5. Host name and DNS requirements for IdM

This section lists the host name and DNS requirements for server and replica systems. It also shows how to verify that the systems meet the requirements.

The requirements in this section 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

1.6. Port requirements for IdM

Identity Management (IdM) uses a number of 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 1.2. IdM ports



80, 443



389, 636



88, 464




TCP and UDP (optional)



UDP (optional)

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 1.3. firewalld services

Service nameFor details, see:







1.7. Opening the ports required by IdM


  1. Make sure 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,123/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-ldap,freeipa-ldaps,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.

1.8. Installing packages required for an IdM server

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:

    • If your RHEL system is not running in the cloud, you have registered your system with the Red Hat Subscription Manager (RHSM). For details, see Registration, attaching, and removing subscriptions in the Subscription Manager command line. You have also enabled the BaseOS and AppStream repositories that IdM uses:

      # subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
      # subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms

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


  • 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 install ipa-server
    • To download the packages necessary for installing an IdM server with an integrated DNS:

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

      # yum install ipa-server ipa-server-trust-ad samba-client

In RHEL 8, IdM packages were distributed as modules and required a different installation procedure. However, the RHEL 8 installation commands still work on RHEL 9.

If you prefer, you can still use the RHEL 8 installation commands, see Installing packages required for an IdM server.