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:

Install the necessary packages
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. 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 Optimizing System Performance in the Directory Server Performance Tuning Guide.

2.1.2. System Requirements

Identity Management 4.4 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.

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

Federal Information Processing Standard (FIPS) support

In environments set up using Red Hat Enterprise Linux 7.4 and later:

You can configure a new IdM server, replica, or client on a system with the 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, replica, or client, and do not enable it after the installation.

For further details about FIPS mode, see Federal Information Processing Standard (FIPS) in the Security Guide.

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: Installing and running an IdM server requires IPv6 to be enabled on the network. 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

You only need to have the IPv6 stack enabled. There is no need to assign an IPv6 address to any interface.

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

The server host must have DNS properly configured regardless of whether the DNS server is integrated within IdM or hosted externally.

Important

Identity Management requires one separate DNS domain to be used for service records. To avoid conflicts on the DNS level, the primary DNS domain used for IdM cannot be shared with any other system.

Note that host names of IdM clients are not required to be part of the primary DNS domain.

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

Important

The fully qualified domain name must be a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, like underscores, in the host name cause DNS failures. Additionally, the host name must be all lower-case; no capital letters are allowed.

For other recommended naming practices, see the Red Hat Enterprise Linux Security Guide.

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.

Verifying 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:

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

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

For a list of the required ports, see the section called “List of Required Ports”.
For a list of firewalld services that correspond to the required ports, see the section called “List of firewalld Services”.

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

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
```
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 Security Guide or the firewall-cmd(1) man page.
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 Reloading the Firewall Using the Command-Line Interface in the Security Guide. If required, to avoid the risk of time outs, repeat the commands without the --permanent option to apply the changes to the running system.
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.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.

Log in to Your Red Hat Account

Red Hat Account

Customer Portal

Select Your Language

Infrastructure and Management

Cloud Computing

Storage

JBoss Development and Management

JBoss Integration and Automation

Mobile

Services

Tools

Red Hat Product Security Center

Security Updates

Resources

Customer Portal Community

Customer Events

Stories

Red Hat Training

Chapter 2. Installing and Uninstalling an Identity Management Server

2.1. Prerequisites for Installing a Server

2.1.1. Hardware Recommendations

2.1.2. System Requirements

2.1.3. Host Name and DNS Configuration

Verifying the Server Host Name

Verifying the Forward and Reverse DNS Configuration

Verifying the Standards-compliance of DNS Forwarders

The `/etc/hosts` File

2.1.4. Port Requirements

List of Required Ports

List of firewalld Services

Opening the Required Ports

Where did the comment section go?

Red Hat Training

Chapter 2. Installing and Uninstalling an Identity Management Server

2.1. Prerequisites for Installing a Server

2.1.1. Hardware Recommendations

2.1.2. System Requirements

2.1.3. Host Name and DNS Configuration

Verifying the Server Host Name

Verifying the Forward and Reverse DNS Configuration

Verifying the Standards-compliance of DNS Forwarders

The /etc/hosts File

2.1.4. Port Requirements

List of Required Ports

List of firewalld Services

Opening the Required Ports

Where did the comment section go?

The `/etc/hosts` File