Show Table of Contents
The
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 is192.0.2.1
. - The IPv6 address is displayed on the line starting with
inet6
. Only IPv6 addresses withscope global
are relevant for this procedure. In the following example, the returned IPv6 address is2001: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.- Run the
dig +short server.example.com A
command. The returned IPv4 address must match the IP address returned byip addr show
:[root@server ~]# dig +short server.example.com A 192.0.2.1
- Run the
dig +short server.example.com AAAA
command. If the command returns an address, it must match the IPv6 address returned byip 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.- 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
- Use
dig
to query the IPv6 address as well if thedig +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
Ifdig +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 thoughdig +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 theANSWER
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:- 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}
- Add the
firewalld
services to the firewall by using thefirewall-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 usingfirewall-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 reloadingfirewalld
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
, ornmap
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.