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 . Obtain the hostname. Get the IP address. In this example, the returned IP address is 196.2.3.4 . 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 . 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. 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 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. 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: 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: 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. 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 If NetworkManagerDispatcher is installed, ensure that it is stopped and disabled: [root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop Then, make sure that the network service is properly started. [root@server ~]# chkconfig network on; service network start Ensure that static networking is correctly configured. Restart the system.

Commands:
hostname server.example.com
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
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
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.
127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.168.1.1 ipaserver.example.com ipaserver
iptables -A INPUT -p tcp --dport 389 -j ACCEPT
positive-time-to-live group 3600 negative-time-to-live group 60 positive-time-to-live hosts 3600 negative-time-to-live hosts 20
chkconfig NetworkManager off; service NetworkManager stop
chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop
chkconfig network on; service network start