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
- Obtain the hostname.
[root@server ~]# hostname server.example.com
- Get the IP address. In this example, the returned IP address is
[root@server !]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:01:4C:E1:2C
inet addr:22.214.171.124Bcast:126.96.36.199 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 ...
- Verify that forward DNS is properly configured by using
digto query the hostname and check what IP address is returned. In this example, the expected IP address is
[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 188.8.131.52
- Verify the reverse DNS configuration using
-t ptrto 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 184.108.40.206.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:
;220.127.116.11.in-addr.arpa. IN PTR;; ANSWER SECTION:
18.104.22.168.in-addr.arpa. 21600 IN PTR server.example.com.
The DNS records should resolve to whatever hostname is used in the IdM certificates.
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,
ImportantThis 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
hostnamecommand cannot be
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/hostsfile. The fully-qualified domain name for the IdM server must be listed in the
hostsfile before any aliases.
NoteA 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
iptablesutility to list the available ports or the
nmaputilities 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
|Kerberos||88, 464||TCP and UDP|
|DNS||53||TCP and UDP|
|Dogtag Certificate System - LDAP||7389||TCP|
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-ntpoption when the IdM server is configured to prevent an NTP server from being installed.
It is strongly recommended that you avoid or restrict the use of
nscdin an IdM deployment. The
nscdservice 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.
nscdcaches authentication and identity information for all services that perform queries through nsswitch, including
nscdperforms 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
nscdaltogether. Alternatively, use a shorter cache time by resetting the time-to-live caching values in the
positive-time-to-live group 3600 negative-time-to-live group 60 positive-time-to-live hosts 3600 negative-time-to-live hosts 20
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
networkservice to manage the networking requirements in an IdM environment and disable the NetworkManager service.
- Boot the machine into single-user mode.
- Disable off the NetworkManager service in the start list and stop the NetworkManager service.
[root@server ~]# chkconfig NetworkManager off; service NetworkManager stop
NetworkManagerDispatcheris installed, ensure that it is stopped and disabled:
[root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop
- Then, make sure that the
networkservice is properly started.
[root@server ~]# chkconfig network on; service network start
- Ensure that static networking is correctly configured.
- Restart the system.