Menu Close
Settings Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 2. Installing and Uninstalling an Identity Management Server

An Identity Management (IdM) server is a domain controller: it defines and manages the IdM domain. To set set up an IdM server, you must:
  1. Install the necessary packages
  2. Configure the machine using setup scripts
Red Hat strongly recommends to set up multiple domain controllers within your domain for load balancing and redundancy. These additional servers are replicas of the initial master IdM server.
This chapter describes installing the first, initial IdM server. For information on installing a replica from the initial server, see Chapter 4, Installing and Uninstalling Identity Management Replicas.

2.1. Prerequisites for Installing a Server

2.1.1. Minimal Hardware Requirements

To run Identity Management (IdM), the server requires at a minimum the following hardware configuration:
  • 1 (virtual) CPU core
  • 2 GB RAM
    Even if you can install IdM with less RAM, certain operations, such as updating IdM, require at least 4 GB RAM.
  • 10 GB hard disk
Important
Depending on the amount of data stored in the database, IdM requires more resources, especially more RAM. For details, see Section 2.1.2, “Hardware Recommendations”. The required hardware resources also depend on other factors, such as the production workload of the server or if a trust with Active Directory is configured.

2.1.2. Hardware Recommendations

RAM is the most important hardware feature to size properly. To determine how much RAM you require, consider these recommendations:
  • For 10,000 users and 100 groups: at least 3 GB of RAM and 1 GB swap space
  • For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space
Note
A basic user entry or a simple host entry with a certificate is approximately 5 - 10 KiB in size.
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.
To increase performance, you can tune the underlying Directory Server to increase performance. For details, see the Red Hat Directory Server Performance Tuning Guide.

2.1.3. System Requirements

Identity Management is supported on Red Hat Enterprise Linux 7. Install an IdM server on a clean system without any custom configuration for services such as DNS, Kerberos, or Directory Server.
Important
For performance and stability reasons, Red Hat recommends that you do not install other applications or services on IdM servers. For example, IdM servers can be exhaustive to the system, especially if the number of LDAP objects is high. Also, IdM is integrated in the system and, if third party applications change configuration files IdM depends on, IdM can break.
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/.
Name Service Cache Daemon (NSCD) requirements
Red Hat recommends to disable NSCD on Identity Management machines. Alternatively, if disabling NSCD is not possible, only enable NSCD for maps that SSSD does not cache.
Both NSCD and the SSSD service perform caching, and problems can occur when systems use both services simultaneously. See the System-Level Authentication Guide for information on how to avoid conflicts between NSCD and SSSD.
IPv6 must be enabled on the system
The IdM server must have the IPv6 protocol enabled in the kernel. Note that IPv6 is enabled by default on Red Hat Enterprise Linux 7 systems.
If you disabled IPv6 before, re-enable it as described in How do I disable or enable the IPv6 protocol in Red Hat Enterprise Linux? in Red Hat Knowledgebase.
Note
IdM does not require the IPv6 protocol to be enabled in the kernel of the hosts you want to enroll as clients. For example, if your internal network only uses the IPv4 protocol, you can configure the System Security Services Daemon (SSSD) to only use IPv4 to communicate with the IdM server. You can do this by inserting the following line into the [domain/_NAME_] section of the /etc/sssd/sssd.conf file: 
lookup_family_order = ipv4_only
For more information on the lookup_family_order, see the sssd.conf(5) man page.

2.1.4. Prerequisites for Installing a Server in a FIPS Environment

In environments set up using Red Hat Enterprise Linux 7.4 and later:
  • You can configure a new IdM server or replica on a system with the Federal Information Processing Standard (FIPS) mode enabled. The installation script automatically detects a system with FIPS enabled and configures IdM without the administrator's intervention.
    To enable FIPS in the operating system, see Enabling FIPS Mode in the Security Guide.
    Important
    You cannot:
    • Enable FIPS mode on existing IdM servers previously installed with FIPS mode disabled.
    • Install a replica in FIPS mode when using an existing IdM server with FIPS mode disabled.
In environments set up using Red Hat Enterprise Linux 7.3 and earlier:
  • IdM does not support the FIPS mode. Disable FIPS on your system before installing an IdM server or replica, and do not enable it after the installation.
For further details about FIPS mode, see Federal Information Processing Standard (FIPS) in the Security Guide.

2.1.5. Host Name and DNS Configuration

Warning
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 integrated DNS services as well as to IdM servers installed without DNS. DNS records are vital for nearly all IdM domain functions, including running LDAP directory services, Kerberos, and Active Directory integration.
Note that the primary DNS domain and Kerberos realm cannot be changed after the installation.
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 server host must have DNS properly configured regardless of whether the DNS server is integrated within IdM or hosted externally.
Identity Management requires one separate DNS domain to be used for service records. To avoid conflicts on the DNS level, the primary IdM DNS domain, the DNS domain whose name is the lower-case version of the IdM Kerberos name, cannot be shared with any other system, such as other IdM or AD domains
The primary IdM DNS domain must contain its own SRV records for standard IdM services. The required records are:
  • the SRV record of both _kerberos._tcp.domain_name and _kerberos._udp.domain_name
  • the SRV record of _ldap._tcp.domain_name
  • the TXT record of _kerberos.domain_name
When an enrolled client, via the ipa command-line tool, is looking for a service provided or mediated by IdM, it looks up the server specified by the xmlrpc_uri parameter in the /etc/ipa/default.conf file. If need be, it also looks up the IdM DNS domain name given in the domain parameter in the same file, and consults the _ldap._tcp.domain_name SRV record for that domain to identify the server it is looking for. If there is no domain given in the /etc/ipa/default.conf file, the client only contacts the server that is set in the xmlrpc_uri parameter of the file.
Note that the host names of IdM clients and servers are not required to be part of the primary DNS domain. However, in trust environments with Active Directory (AD), the host names of IdM servers must be part of the IdM-owned domain, the domain associated with the IdM realm, and not part of the AD-owned domain, the domain associated with the trusted AD realm. From the perspective of the trust, this association is managed using Realm domains.
For information on configuring users to access an IdM client using a host name from the Active Directory DNS domain, while the client itself is joined to IdM, see IdM clients in an Active Directory DNS Domain in the Windows Integration Guide.

Verifying the Server Host Name

The host name must be a fully qualified domain name, such as server.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.
  • The fully qualified domain name must not resolve to the loopback address. It must resolve to the machine's public IP address, not to 127.0.0.1.
For other recommended naming practices, see the Recommended Naming Practices in the Red Hat Enterprise Linux Security Guide.
To verify your machine's host name, use the hostname utility: 
[root@server ~]# hostname
server.example.com
The output of hostname must not be localhost or localhost6.

Verifying the Forward and Reverse DNS Configuration

  1. Obtain the IP address of the server. The ip addr show command displays both the IPv4 and IPv6 addresses:
    • The IPv4 address is displayed on the line starting with inet. In the following example, the configured IPv4 address is 192.0.2.1.
    • The IPv6 address is displayed on the line starting with inet6. Only IPv6 addresses with scope global are relevant for this procedure. In the following example, the returned IPv6 address is 2001:DB8::1111. 
    [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 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
  2. Verify the forward DNS configuration by using the dig utility and adding the host name.
    1. Run the dig +short server.example.com A command. The returned IPv4 address must match the IP address returned by ip addr show: 
      [root@server ~]# dig +short server.example.com A
192.0.2.1
    2. Run the dig +short server.example.com AAAA command. If the command returns an address, it must match the IPv6 address returned by ip addr show: 
      [root@server ~]# dig +short server.example.com AAAA
2001:DB8::1111
      Note
      If no output is returned for the AAAA record, it does not indicate incorrect configuration; no output only means that no IPv6 address is configured in DNS for the server machine. 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) by using the dig utility and adding the IP address.
    1. Run the dig +short -x IPv4 address command. The server host name must be displayed in the command output. For example: 
      [root@server ~]# dig +short -x 192.0.2.1
server.example.com
    2. Use dig to query the IPv6 address as well if the dig +short -x server.example.com AAAA command in the previous step returned an IPv6 address. Again, the server host name must be displayed in the command output. For example: 
      [root@server ~]# dig +short -x 2001:DB8::1111
server.example.com
      Note
      If dig +short server.example.com 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 different host name or no host name is displayed, even though dig +short server.example.com in the previous step returned an IP address, it indicates that the reverse DNS configuration is incorrect.

Verifying the Standards-compliance of DNS Forwarders

When configuring IdM with integrated DNS, it is recommended to use DNS Security Extensions (DNSSEC) records validation. By validating signed DNS records from other servers, you protect your IdM installation against spoofed addresses. However, DNSSEC validation is not a hard requirement for a successful IdM installation.
IdM installer enables DNSSEC records validation by default. For successful DNSSEC validation, it is crucial to have forwarders on which DNSSEC has been properly configured. During installation, IdM checks global forwarders, and if a forwarder does not support DNSSEC, the DNSSEC validation will be disabled on the forwarder.
To verify that all DNS forwarders you want to use with the IdM DNS server comply with the Extension Mechanisms for DNS (EDNS0) and DNSSEC standards: 
$ 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 of your DNS forwarder and verify that EDNS0 and DNSSEC are supported and enabled. In latest versions of the BIND server, the dnssec-enable yes; option must be set in the /etc/named.conf file.
For example, the expected output can look like this: 
;; ->>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 [...]

The /etc/hosts File

Important
Do not modify the /etc/hosts file manually. If /etc/hosts has been modified, make sure its contents conform to the following rules.
The following is an example of a correctly configured /etc/hosts file. It properly lists the IPv4 and IPv6 localhost entries for the host, followed by the IdM server IP address and host name as the first entry. Note that the IdM server host name cannot be part of the localhost entry. 
127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6
192.0.2.1	server.example.com	server
2001:DB8::1111	server.example.com	server

2.1.6. Port Requirements

IdM uses a number of ports to communicate with its services. These ports must be open and available for IdM to work. They cannot be in use by another service or blocked by a firewall.

List of Required Ports

Table 2.1. Identity Management 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
NTP 123 UDP
Note
Do not be concerned that IdM uses ports 80 and 389.
  • Port 80 (HTTP) is 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 GSSAPI for encryption.
In addition, IdM can listen on port 8080 and in some installations also on ports 8443 and 749. However, these three ports are only used internally: even though IdM keeps them open, they are not required to be accessible from outside. It is recommended that you do not open ports 8080, 8443, and 749 and instead leave them blocked by a firewall.

List of firewalld Services

Table 2.2. firewalld Services

Service name For details, see:
freeipa-ldap /usr/lib/firewalld/services/freeipa-ldap.xml
freeipa-ldaps /usr/lib/firewalld/services/freeipa-ldaps.xml
dns /usr/lib/firewalld/services/dns.xml

Opening the Required Ports

  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,list_of_ports}
    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,list_of_services}
    For details on using firewall-cmd to open ports on a system, see the Modifying Settings in Runtime and Permanent Configuration using CLI in the Security Guide or 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. See also Modifying Settings in Runtime and Permanent Configuration using CLI in the Security Guide. 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 --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp,123/udp}
  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
Note that you also have to open network-based firewalls for both incoming and outgoing traffic.