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. Prerequisites 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, increasing RAM is more effective than increasing 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. In virtualized environments, memory ballooning must be disabled or the complete RAM must be reserved for the guest IdM servers. Note 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. Note 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 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. Single-DES (DES) and triple-DES (3DES) encryption types were removed from RHEL 8 and are not used in RHEL 9. 1.3.3. 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. Note 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 System-wide cryptographic policies 1.3.4. FIPS compliance You can install a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) mode enabled. The only exception is a system on which the FIPS:OSPP cryptographic subpolicy is 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-3: 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. 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: create a new IdM realm in FIPS mode 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 DNSSEC KSK and ZSK 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. 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. Important RADIUS authentication is not FIPS compliant. Do not install IdM on a server with FIPS mode enabled if you require RADIUS authentication. Additional Resources To enable FIPS mode in the RHEL operating system, see Switching the system to FIPS mode in the Security Hardening guide. For more details on FIPS 140-2, see the Security Requirements for Cryptographic Modules on the National Institute of Standards and Technology (NIST) web site. 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 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. Note 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. Additional resources Implementation of NTP Using the Chrony suite to configure NTP 1.4.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 1.1. List of NTP configuration options for IdM installation commands Option Behavior --ntp-server Use it to specify one NTP server. You can use it multiple times to specify multiple servers. --ntp-pool Use it to specify a pool of multiple NTP servers resolved as one hostname. -N , --no-ntp Do not configure, start, or enable chronyd . Additional resources Implementation of NTP Using the Chrony suite to configure NTP 1.4.3. Ensuring IdM can reference your NTP time server You can verify if you have the necessary configurations in place for IdM to be able to synchronize with your Network Time Protocol (NTP) time server. Prerequisites You have configured an NTP time server in your environment. In this example, the hostname of the previously configured time server is ntpserver.example.com . Procedure Perform a DNS service (SRV) record search for NTP servers in your environment. If the 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 Verify that DNS returns an entry for your time server on port 123 when you perform a search for _ntp._udp SRV records. Additional resources Implementation of NTP Using the Chrony suite to configure NTP 1.5. Meeting DNS 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. Warning DNS records are vital for nearly all Identity Management (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 all IdM servers, both with and without integrated DNS. Verify the server host name The host name must be a fully qualified domain name, such as server.idm.example.com . Important 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 example.com or company.example.com . 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 127.0.0.1 . To verify the host name, use the hostname utility on the system where you want to install: The output of hostname must not be localhost or localhost6 . Verify the forward and reverse DNS configuration Obtain the IP address of the server. 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: Verify the forward DNS configuration using the dig utility. Run the command dig +short server.idm.example.com A . The returned IPv4 address must match the IP address returned by ip addr show : Run the command dig +short server.idm.example.com AAAA . If it returns an address, it must match the IPv6 address returned by ip addr show : Note 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. 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. Run the command dig +short -x IPv4_address . The output must display the server host name. For example: If the command dig +short -x server.idm.example.com AAAA in the step returned an IPv6 address, use dig to query the IPv6 address too. The output must display the server host name. For example: Note If dig +short server.idm.example.com AAAA in the 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. Warning 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). To do this, inspect the output of the following command for each forwarder separately: The expected output displayed by the command contains the following information: Status: NOERROR Flags: ra If either of these items is missing from the output, inspect the documentation for your DNS forwarder and verify that EDNS0 is supported and enabled. Determine your DNS Security Extensions (DNSSEC) policy (required for integrated DNS only) Warning DNSSEC is only available as Technology Preview in IdM. DNSSEC validation is enabled in the IdM-integrated DNS server by default. If you do not require the DNSSEC feature in your IdM deployment, add the --no-dnssec-validation option to the ipa-server-install --setup-dns and ipa-replica-install --setup-dns commands when installing the primary IdM server and the IdM replicas. If you do want to use DNSSEC, ensure that all DNS forwarders you want to use with the IdM DNS server comply with the DNSSEC standard. To do this, inspect the output of the following command for each forwarder separately: 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 DNSSEC is 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 +dnssec : Note On already deployed IdM servers, you can check whether DNSSEC validation is enabled by searching for the dnssec-validation boolean option in the /etc/named/ipa-options-ext.conf file. 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 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: 1.6. 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 1.2. IdM ports Service Ports Protocol HTTP/HTTPS 80, 443 TCP LDAP/LDAPS 389, 636 TCP Kerberos 88, 464 TCP and UDP DNS 53 TCP and UDP (optional) Note 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 and 8443 are used internally by pki-tomcat and leave them blocked in the firewall to prevent their use by other services. Port 749 is used for remote management of the Kerberos server and only open it if you intend to use remote management. Table 1.3. firewalld services Service name For details, see: freeipa-4 /usr/lib/firewalld/services/freeipa-4.xml dns /usr/lib/firewalld/services/dns.xml 1.7. Opening the ports required by IdM You can open the required ports that IdM uses to communicate with its services. Procedure Verify that the firewalld service is running. To find out if firewalld is currently running: To start firewalld and configure it to start automatically when the system boots: Open the required ports using the firewall-cmd utility. Choose one of the following options: 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: 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: For details on using firewall-cmd to open ports on a system, see the firewall-cmd (1) man page. Reload the firewall-cmd configuration to ensure that the change takes place immediately: 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: Verification Log in to a host on the client subnet and use the nmap or nc utilities to connect to the opened ports or run a port scan. For example, to scan the ports that are required for TCP traffic: To scan the ports that are required for UDP traffic: Note 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. Prerequisites 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 Subscription Central . You have also enabled the BaseOS and AppStream repositories that IdM uses: For details on how to enable and disable specific repositories using RHSM, see Subscription Central . 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). Procedure 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: To download the packages necessary for installing an IdM server with an integrated DNS: To download the packages necessary for installing an IdM server that has a trust agreement with Active Directory: 1.9. 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. Prerequisites You have root privileges. Procedure Optional: Display the current umask : Set the umask to 0022 : Optional: After the IdM installation is complete, set the umask back to its original value: 1.10. Ensuring that fapolicyd rules do not block IdM installation 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 Red Hat Knowledgebase solution fapolicy restrictions causing IdM installation failures . 1.11. 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 1.4. General options: available for ipa-server-install and ipa-replica-install Argument Description -d , --debug Enables debug logging for more verbose output. -U , --unattended Enables an unattended installation session that does not prompt for user input. --hostname= server.idm.example.com The fully-qualified domain name of the IdM server machine. Only numbers, lowercase alphabetic characters, and hyphens (-) are allowed. --ip-address 127.0.0.1 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. -n example.com 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. -r <KERBEROS_REALM_NAME> 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. --setup-dns Tells the installation script to set up a DNS service within the IdM domain. --setup-ca 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 1.5. CA options: available for ipa-ca-install and ipa-server-install Argument Description --random-serial-numbers Enables Random Serial Numbers version 3 (RSNv3) for the IdM CA. When enabled, the CA generates fully random serial numbers for certificates and requests in PKI without range management. IMPORTANT: RSNv3 is supported only for new IdM CA installations. If enabled, it is required to use RSNv3 on all PKI services. --ca-subject= <SUBJECT> 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. --subject-base= <SUBJECT> 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. --external-ca Generates a certificate signing request to be signed by an external CA. --ca-signing-algorithm= <ALGORITHM> 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 1.6. DNS options: available for ipa-dns-install, or for ipa-server-install and ipa-replica-install when using --setup-dns Argument Description --forwarder= 192.0.2.1 Specifies a DNS forwarder to use with the DNS service. To specify more than one forwarder, use this option multiple times. --no-forwarders Uses root servers with the DNS service instead of forwarders. --no-reverse 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) and ipa-replica-install(1) man pages on your system ipa-dns-install(1) and ipa-ca-install(1) man pages on your system

Commands:
[user@server ~]USD dig +short -t SRV _ntp._udp.example.com 0 100 123 ntpserver .example.com.
[user@server ~]USD dig +short -t SRV _ntp._udp.example.com 0 100 123 ntpserver .example.com.
hostname server.idm.example.com
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 192.0.2.1 /24 brd 192.0.2.255 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
dig +short server.idm.example.com A 192.0.2.1
dig +short server.idm.example.com AAAA 2001:DB8::1111
dig +short -x 192.0.2.1 server.idm.example.com
dig +short -x 2001:DB8::1111 server.idm.example.com
dig @ IP_address_of_the_DNS_forwarder . SOA
dig +dnssec @ IP_address_of_the_DNS_forwarder . SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR , id: 48655 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; ANSWER SECTION: . 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400 . 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.0.2.1 server.idm.example.com server 2001:DB8::1111 server.idm.example.com server
systemctl status firewalld.service
systemctl start firewalld.service systemctl enable firewalld.service
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}
firewall-cmd --permanent --add-service={freeipa-4,dns}
firewall-cmd --reload
firewall-cmd --runtime-to-permanent
nmap -p 80,443,389,636,88,464,53 server.idm.example.com [...] PORT STATE SERVICE 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 389/tcp open ldap 443/tcp open https 464/tcp open kpasswd5 636/tcp open ldapssl
nmap -sU -p 88,464,53 server.idm.example.com [...] PORT STATE SERVICE 53/udp open domain 88/udp open|filtered kerberos-sec 464/udp open|filtered kpasswd5
subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpms
dnf install ipa-server
dnf install ipa-server ipa-server-dns
dnf install ipa-server ipa-server-trust-ad samba-client
umask 0027
umask 0022
umask 0027