SupportConsoleDevelopersStart a trialContact

2.4. System Prerequisites

The IdM server is set up using a configuration script, and this script makes certain assumption about the host system. If the system does not meet these prerequisites, then server configuration may fail.

2.4.1. DNS Records

Proper forward and reverse DNS settings are critical for both IdM servers and replicas (copies of servers) to be configured. DNS is used for replicating data between servers, for identifying servers in SSL certificates, and in Kerberos tickets, among other places. Therefore, servers must be resolvable in both forward and reverse DNS configuration.
The DNS settings for a host can be determined easily used ifconfig and dig.
  1. Obtain the hostname. 
    [root@server ~]# hostname
server.example.com
  2. Get the IP address. In this example, the returned IP address is 196.2.3.4. 
    [root@server !]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 52:54:01:4C:E1:2C
          inet addr:196.2.3.4  Bcast:196.9.8.7  Mask:255.255.255.255
          inet6 addr: 2620:52:0:102f:5054:1ff:fe4c:e12c/64 Scope:Global
	  inet6 addr: fe80::5054:1ff:fe4c:e12c/64 Scope:Link
...
  3. Verify that forward DNS is properly configured by using dig to query the hostname and check what IP address is returned. In this example, the expected IP address is 196.2.3.4. 
    [root@server ~]# dig server.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> server.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56680
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 12

;; QUESTION SECTION:
;server.example.com. IN A

;; ANSWER SECTION:
server.example.com. 2946 IN A 196.2.3.4
  4. Verify the reverse DNS configuration using dig with the -t ptr to query the PTR records (reverse records) for the address. This is the IP address in reverse order, with .in-addr.arpa. appended to the address. This should resolve to the hostname, server.example.com. in this example. 
    [root@server ~]# dig -t ptr 4.3.2.196.in-addr.arpa. 
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ptr 241.40.16.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57899
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10

;; QUESTION SECTION:
;4.3.2.196.in-addr.arpa. IN PTR

;; ANSWER SECTION:
4.3.2.196.in-addr.arpa. 21600 IN PTR server.example.com.
The DNS records should resolve to whatever hostname is used in the IdM certificates.

Note

If the IdM server is configured to host its own DNS server, the IdM DNS service processes all DNS queries. The IdM DNS records take precedence, and any previous existing DNS configuration is ignored.
All systems within the domain must be configured to use the IdM-managed DNS server.

2.4.2. Hostname and IP Address Requirements

Regardless of whether the DNS is within the IdM server or external, the server host must have DNS properly configured:
  • The hostname must be a fully-qualified domain name. For example, ipaserver.example.com.

    Important

    This must be a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, like underscores, in the hostname will cause DNS failures.
  • The hostname must be all lower-case.
  • The server's A record must be set and resolve to its public IP address.
    The fully-qualified domain name cannot resolve to the loopback address. It must resolve to the machine's public IP address, not to 127.0.0.1. The output of the hostname command cannot be localhost or localhost6.
    The A adn PTR records do not need to match for the server.
  • The server's hostname and IP address must be in its own /etc/hosts file. The fully-qualified domain name for the IdM server must be listed in the hosts file before any aliases.

    Note

    A misconfigured file can prevent the IdM command-line tools from functioning correctly and can prevent the IdM web interface from connecting to the IdM server.
    Additionally, the hostname cannot be part of the localhost entry.
    For example, this lists the IPv4 and IPv6 localhost entries for the host (properly), then the IdM server IP address and hostname as the first entry. 
    127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6
192.168.1.1	ipaserver.example.com	ipaserver
  • It is recommended that a separate DNS domain be allocated for the IdM server to manage. While not required (clients from other domains can still be enrolled in the IdM domain), this is a convenience for overall DNS management.

2.4.3. Directory Server

There must not be any instances of 389 Directory Server installed on the host machine.

2.4.4. System Files

The server script overwrites system files to set up the IdM domain. The system should be clean, without custom configuration for services like DNS and Kerberos, before configuring the IdM server.

2.4.5. System Ports

IdM uses a number of ports to communicate with its services. These ports, listed in Table 2.1, “IdM Ports”, must be open and available for IdM to work. They cannot be in use by another service or blocked by a firewall. To make sure that these ports are available, try the iptables utility to list the available ports or the nc, telnet, or nmap utilities to connect to a port or run a port scan.
To open a port: 
[root@server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPT
The iptables(8) man page has more information on opening and closing ports on a system.
Table 2.1. IdM Ports
Service Ports Type
HTTP/HTTPS 80, 443 TCP
LDAP/LDAPS 389, 636 TCP
Kerberos 88, 464 TCP and UDP
DNS 53 TCP and UDP
NTP 123 UDP
Dogtag Certificate System - LDAP 7389 TCP

2.4.6. NTP

Network time protocol (NTP) synchronizes time between systems on a network. An NTP server centralizes and manages that clock synchronization. By default, Identity Management installs and configures an NTP server which is used by the domain to synchronize clocks for other Identity Management servers, replicas, and systems and services within the IdM domain.
Some sort of NTP server must be running for some domain tasks — such as Kerberos ticket maintenance and data replication between servers and replicas in the topology — to function properly. It is not required that an IdM server host the NTP server, but it is strongly recommended. This is the default configuration.
If a server is being installed on a virtual machine, that server should not run an NTP server. To disable NTP for IdM, use the --no-ntp option when the IdM server is configured to prevent an NTP server from being installed.

2.4.7. NSCD

It is strongly recommended that you avoid or restrict the use of nscd in an IdM deployment. The nscd service is extremely useful for reducing the load on the server, and for making clients more responsive, but there can be problems when a system is also using SSSD, which performs its own caching.
nscd caches authentication and identity information for all services that perform queries through nsswitch, including getent. Because nscd performs both positive and negative caching, if a request determines that a specific IdM user does not exist, it caches this as a negative response. Values stored in the cache remain until the cache expires, regardless of any changes that may occur on the server. The results of such caching is that new users and memberships may not be visible, and users and memberships that have been removed may still be visible.
To avoid clashes with SSSD caches and to prevent locking out users, avoid using nscd altogether. Alternatively, use a shorter cache time by resetting the time-to-live caching values in the /etc/nscd.conf file: 
positive-time-to-live   group           3600
negative-time-to-live   group           60
positive-time-to-live   hosts           3600
negative-time-to-live   hosts           20

2.4.8. Networking

The default networking service used by Red Hat Enterprise Linux is NetworkManager. However, NetworkManager can cause problems with IdM and the KDC. It is highly recommended that you use the network service to manage the networking requirements in an IdM environment and disable the NetworkManager service.
  1. Boot the machine into single-user mode.
  2. Disable off the NetworkManager service in the start list and stop the NetworkManager service. 
    [root@server ~]# chkconfig NetworkManager off; service NetworkManager stop
  3. If NetworkManagerDispatcher is installed, ensure that it is stopped and disabled: 
    [root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop
  4. Then, make sure that the network service is properly started. 
    [root@server ~]# chkconfig network on; service network start
  5. Ensure that static networking is correctly configured.
  6. Restart the system.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.