by Alexandre Borges
This article is Part 2 of a series that explains how to administer Oracle Linux 7.2. This article focuses on how to configure and integrate an identity management (IdM) client/server environment on Oracle Linux 7.2.
Table of Contents
Introduction
Installing an Identity Management Master Server
Installing the IPA Replica Server
Installing the IPA Client
Testing the IdM/IPA server
Testing the Kerberos SSO Aspect: the OpenSSH Application
Integrating Oracle Linux 7.2 with Microsoft Active Directory
Conclusion
See Also
About the Author
Introduction
Doubtless, there are some administration tasks that take us a considerable amount of time to accomplish, and one of them is configuring an identify management (IdM) server, which is composed of a Kerberos server and an LDAP Server, basically.
Fundamentally, a Kerberos server works as a central point of authentication for applications that are Kerberos-aware. The great advantage of installing and configuring a Kerberos server is that it increases the security of the authentication process, preventing passwords from being passed over the network and offering the possibility to implement single sign-on (SSO) capability. Furthermore, some potential insecure applications (for example, telnet) can have their security improved if they are integrated with Kerberos because, in the end, Kerberos offers a second level of authentication.
An LDAP server works with a distributed and hierarchical database, and it is object oriented, which means it can hold several kinds of information such as user and passwords, for example. Many operating systems and LDAP-enabled applications can use LDAP as a central repository for logging passwords and system configuration. Obviously, this arrangement mitigates the endless procedure of keeping updated password on different hosts.
During this article, we will be exploring how to configure an IdM server. Also, instead of configuring it and its associated services (DNS, NTP, and Kerberos) manually, we will be using an IPA (identity, policy, and auditing) client/server framework, which will help us to configure everything in a more automated way. At end, we will learn how to integrate the IdM framework with the Microsoft Active Directory (AD) service.
Installing an Identity Management Master Server
Fortunately, Oracle Linux 7.2 provides an excellent client/server solution for implementing an identity management (IdM) service—it is named IPA (Identity, Policy, and Auditing), and it integrates with Kerberos and LDAP.
The IPA service is a client/server framework, which creates a Linux-controlled domain that can synchronize data with a Microsoft Active Directory domain for centralizing identity management and making administration easier. The IdM server works as an identity and authentication server (a domain controller) by using a Kerberos server and, implicitly, a Kerberos Key Distribution Center (KDC) for authentication, which causes all data to be held (in a persistent way) on an LDAP server. Furthermore, a DNS server for name resolution and an NTP server (a reliable time provider that is necessary for the Kerberos service to work appropriately) are included to provide support functions for the IdM server.
On the client side, all credentials are cached by the System Security Services Daemon (SSSD), which it is responsible for managing authentication mechanisms, providing access to a remote directory, and making the integration with different account sources easier. The SSSD saves credentials either in an ldb database (https://ldb.samba.org/) or in a local file system as XML files. The only requirement is an appropriate system configuration to direct the SSSD to use the IdM services from the server. Other components, such as certmonger
, which is able to obtain different types of certificates (remember, that there is a public key inside each certificate) exist on the IdM client to monitor and renew certificates. More information about digital certificates can be found at https://en.wikipedia.org/wiki/Public_key_certificate.
To show the IdM service working, we will initially use two virtual machines (myoracle1
and myoracle2
) where the former (the server) has 4 GB of RAM and the latter (the client) has 2 GB of RAM. For real cases, it is recommended to use at least 2 GB on the server when the number of users is less than 10,000 users. When configuring the IdM replica server, we will use a third system (myoracle3
) that has 2 GB of RAM.
Before proceeding, it is strongly recommended that you update all systems (myoracle1
, myoracle2
, and myoracle3
) by executing the following commands on each:
[root@myoracle1 ~]# yum update
[root@myoracle1 ~]# reboot
Now, we can move forward.
Initially, we need to ensure that all system names can be resolved, so we should include the necessary information about our hosts (myoracle1
, myoracle2
, and myoracle3
) in the /etc/hosts
file, as shown below:
[root@myoracle2 ~]# more /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.195 myoracle1.example.com myoracle1
192.168.1.196 myoracle2.example.com myoracle2
192.168.1.197 myoracle3.example.com myoracle3
As another important task, we have to manage the firewall settings because the IdM server uses several ports to communicate with its services. These tasks prevent having any blocked ports. Thus, the following ports must be opened (see https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers):
- For NTP: port 123 (UDP)
- For DNS: port 53 (TCP and UDP)
- For HTTP: port 80 (TCP)
- For HTTPS: port 443 (TCP)
- For LDAP: port 389 (TCP)
- For LDAPS: port 636 (TCP)
- For Kerberos: port 88 and port 464 (TCP and UDP)
To open these ports, we must execute a few steps. (We could open all the ports using fewer steps, but I am performing the task in two stages here to make things easier to understand.)
First, enable the firewall service on the myoracle1
host by running the following command:
[root@myoracle1 ~]# systemctl enable firewalld.service
Include the LDAP port (389/TCP) into the firewall persistent configuration by creating a zone (a kind of container for rules) named public in a configuration file, as shown below:
[root@myoracle1 ~]# firewall-cmd --permanent --zone=public --add-port=389/tcp
If you make a mistake and include incorrect port numbers, you can remove them by executing the same command except replace the add-port
parameter with the remove-port
parameter. All remaining keywords and values are the same.
Execute the following command to reload the firewall rules from the configuration file and make them active in memory:
[root@myoracle1 ~]# firewall-cmd --reload
List the entire configuration of the public zone by running the following command:
[root@myoracle1 ~]# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: eno16777736
sources:
services: dhcpv6-client ssh
ports: 389/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
In the same way as done previously, we have to include the remaining ports into the firewall configuration file (permanent
option), as shown below:
[root@myoracle1 ~]# firewall-cmd --permanent --zone=public --add-port={123/udp,53/udp,53/tcp,80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,464/tcp,88/udp,464/udp}
Run the following command to load the new firewall changes from the configuration file and make them active:
[root@myoracle1 ~]# firewall-cmd --reload
List the configuration of the public zone by executing the following command:
[root@myoracle1 ~]# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: eno16777736
sources:
services: dhcpv6-client ssh
ports: 443/tcp 80/tcp 464/tcp 88/udp 464/udp 88/tcp 123/udp 389/tcp 53/tcp 53/udp 636/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
Now it's time to install on the myoracle1
system the ipa-server
package that recursively will install several dependencies, such as krb5-server
for the Kerberos service and 389-ds-base
for the LDAP service, and update other many packages, too. As mentioned above, this is one of the advantages of deploying an IdM server by using an IPA framework: all the necessary services may be installed and configured together, as we will see in the next steps.
Thus, execute the following command to install the necessary packages (during my installation there were 177 packages, so have a cup of coffee):
[root@myoracle1 ~]# yum install ipa-server bind bind-dyndb-ldap ipa-server-dns
The next step is to configure the IdM server by running the ipa-server-install
script, which configures all the required services for the IdM server—such as a 389 Directory Server instance (an LDAP server), an Apache server, an NTP server, a Kerberos KDC (for authentication), a Microsoft Active Directory Win-Sync plugin (if necessary, for integrating with Microsoft Active Directory), and a DNS server (optional, for resolving names)—and updates the SELinux target policy (https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-s1-syssec.html).
Important: Intentionally, we are not specifying a useful option named --mkhomedir
, which creates homes directories for users upon their first login. If you prefer not to enable the --mkhomedir
option later, replace the command shown below with ipa-server-install --mkhomedir
. Otherwise, follow the next steps as shown, and we will enable this option at the end of this section.
[root@myoracle1 ~]# ipa-server-install
The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.
This includes:
* Configure a stand-alone CA (dogtag) for certificate management
* Configure the Network Time Daemon (ntpd)
* Create and configure an instance of Directory Server
* Create and configure a Kerberos Key Distribution Center (KDC)
* Configure Apache (httpd)
To accept the default shown in brackets, press the Enter key.
Do you want to configure integrated DNS (BIND)? [no]: yes
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.
Server host name [myoracle1.example.com]: [ENTER]
Warning: skipping DNS resolution of host myoracle1.example.com
The domain name has been determined based on the host name.
Please confirm the domain name [example.com]: [ENTER]
The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.
Please provide a realm name [EXAMPLE.COM]: [ENTER]
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.
Directory Manager password: Hacker123@
Password (confirm): Hacker123@
The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.
IPA admin password: Otn2016!
Password (confirm): Otn2016!
Existing BIND configuration detected, overwrite? [no]: yes
Do you want to configure DNS forwarders? [yes]: yes
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.8.8
DNS forwarder 8.8.8.8 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.4.4
DNS forwarder 8.8.4.4 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip: [ENTER]
Checking DNS forwarders, please wait ...
Do you want to configure the reverse zone? [yes]: yes
Please specify the reverse zone name [1.168.192.in-addr.arpa.]: [ENTER]
Using reverse zone(s) 1.168.192.in-addr.arpa.
The IPA Master Server will be configured with:
Hostname: myoracle1.example.com
IP address(es): 192.168.1.195
Domain name: example.com
Realm name: EXAMPLE.COM
BIND DNS server will be configured to serve IPA domain with:
Forwarders: 8.8.8.8, 8.8.4.4
Reverse zone(s): 1.168.192.in-addr.arpa.
Continue to configure the system with these values? [no]: yes
The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
[1/42]: creating directory server user
[2/42]: creating directory server instance
[3/42]: adding default schema
[4/42]: enabling memberof plugin
...
[39/42]: activating sidgen plugin
[40/42]: activating extdom plugin
[41/42]: tuning directory server
[42/42]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds
[1/27]: creating certificate server user
[2/27]: configuring certificate server instance
[3/27]: stopping certificate server instance to update CS.cfg
...
[25/27]: migrating certificate profiles to LDAP
[26/27]: importing IPA certificate profiles
[27/27]: adding default CA ACL
Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv). Estimated time: 10 seconds
[1/3]: configuring ssl for ds instance
[2/3]: restarting directory server
[3/3]: adding CA certificate entry
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds
[1/10]: adding sasl mappings to the directory
[2/10]: adding kerberos container to the directory
[3/10]: configuring KDC
...
[9/10]: starting the KDC
[10/10]: configuring KDC to start on boot
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring ipa_memcached
[1/2]: starting ipa_memcached
[2/2]: configuring ipa_memcached to start on boot
Done configuring ipa_memcached.
Configuring ipa-otpd
[1/2]: starting ipa-otpd
[2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Configuring the web interface (httpd). Estimated time: 1 minute
[1/19]: setting mod_nss port to 443
[2/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2
[3/19]: setting mod_nss password file
...
[17/19]: enable KDC proxy
[18/19]: restarting httpd
[19/19]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Upgrading IPA:
[1/9]: stopping directory server
[2/9]: saving configuration
[3/9]: disabling listeners
...
[8/9]: restoring configuration
[9/9]: starting directory server
Done.
Restarting the directory server
Restarting the KDC
Configuring DNS (named)
[1/12]: generating rndc key file
[2/12]: adding DNS container
[3/12]: setting up our zone
...
[12/12]: changing resolv.conf to point to ourselves
Done configuring DNS (named).
Configuring DNS key synchronization service (ipa-dnskeysyncd)
[1/7]: checking status
[2/7]: setting up bind-dyndb-ldap working directory
[3/7]: setting up kerberos principal
[4/7]: setting up SoftHSM
[5/7]: adding DNSSEC containers
[6/7]: creating replica keys
[7/7]: configuring ipa-dnskeysyncd to start on boot
Done configuring DNS key synchronization service (ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
Restarting the web server
==============================================================================
Setup complete
Next steps:
1. You must make sure these network ports are open:
TCP Ports:
* 80, 443: HTTP/HTTPS
* 389, 636: LDAP/LDAPS
* 88, 464: kerberos
* 53: bind
UDP Ports:
* 88, 464: kerberos
* 53: bind
* 123: ntp
2. You can now obtain a kerberos ticket using the command: 'kinit admin'
This ticket will allow you to use the IPA tools (e.g., ipa user-add)
and the web user interface.
Be sure to back up the CA certificates stored in /root/cacert.p12
These files are required to create replicas. The password for these
files is the Directory Manager password
[root@myoracle1 ~]#
Next, restart the sshd
daemon and check its status by running the following commands:
[root@myoracle1 ~]# systemctl start sshd.service
[root@myoracle1 ~]# systemctl status sshd.service
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2016-02-10 19:23:35 BRST; 6min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 17606 (sshd)
CGroup: /system.slice/sshd.service
└─17606 /usr/sbin/sshd -D
Feb 10 19:23:35 myoracle1.example.com systemd[1]: Started OpenSSH server daemon.
Feb 10 19:23:35 myoracle1.example.com systemd[1]: Starting OpenSSH server daemon...
Feb 10 19:23:35 myoracle1.example.com sshd[17606]: Server listening on 0.0.0.0 port 22.
Feb 10 19:23:35 myoracle1.example.com sshd[17606]: Server listening on :: port 22.
Feb 10 19:30:20 myoracle1.example.com systemd[1]: Started OpenSSH server daemon.
Log in to the IPA server by using the password configured above (remember that the kinit
command obtains and caches an initial ticket-granting ticket [TGT] for the user) and list the Kerberos ticket by using the klist
command, as shown below:
[root@myoracle1 ~]# kinit admin
Password for admin@EXAMPLE.COM:Otn2016!
[root@myoracle1 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
02/11/2016 16:14:46 02/12/2016 16:14:41 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Confirm that the DNS configuration is OK by executing the following command:
[root@myoracle1 ~]# ipa dnszone-show
Zone name: example.com
Zone name: example.com.
Active zone: TRUE
Authoritative nameserver: myoracle1.example.com.
Administrator e-mail address: hostmaster.example.com.
SOA serial: 1455515204
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
Allow query: any;
Allow transfer: none;
Create a regular user named aborges
(by using the ipa user-add
command), which will be used for login later, as shown below:
[root@myoracle1 ~]# ipa user-add aborges --first=Alexandre --last=Borges --password
Password: Linux72@@
Enter Password again to verify: Linux72@@
--------------------
Added user "aborges"
--------------------
User login: aborges
First name: Alexandre
Last name: Borges
Full name: Alexandre Borges
Display name: Alexandre Borges
Initials: AB
Home directory: /home/aborges
GECOS: Alexandre Borges
Login shell: /bin/sh
Kerberos principal: aborges@EXAMPLE.COM
Email address: aborges@example.com
UID: 1695400001
GID: 1695400001
Password: True
Member of groups: ipausers
Kerberos keys available: True
The next step is to configure the Remote Name Daemon Control (RNDC) service (it helps us to control the DNS server operation) by creating an RNDC configuration file and its respective key (for preventing unauthorized access to the DNS daemon) by running the rdnc-congen
command. You should move the mouse to increase the entropy and generate a random key during the execution of the command shown below:
[root@myoracle1 ~]# /usr/sbin/rndc-confgen -a
wrote key file "/etc/rndc.key"
To implement the same security context from the /etc
directory, execute this command:
[root@myoracle1 ~]# /sbin/restorecon /etc/rndc.key
Alter the owner and permission of the RNDC key file, as shown below:
[root@myoracle1 ~]# chown root:named /etc/rndc.key
[root@myoracle1 ~]# chmod 0640 /etc/rndc.key
As I mentioned previously, we configured the IPA server by calling the ipa-server-install
command without specifying the --mkhomedir
option. The reason is that I have seen this command run without that option very often in real-world situations, and most administrators don't know how to proceed. Therefore, to enable the automatic home directory creation for users upon their first login, execute the following:
[root@myoracle1 ~]# authconfig --enablemkhomedir -update
It's perfect! We've done it!
Installing the IPA Replica Server
Before continuing, there is a small problem to solve. Deploying only an IdM server makes a single point of failure in the network system similar to having only one DNS server (we know that it is required to have at least two DNS servers in a company according RFC1035: http://www.ietf.org/rfc/rfc1035.txt). Therefore, it is recommended to have a replica IdM server (an IdM server holding the same IdM information as the first "primary" IdM server). If the primary IdM server fails (for example, because it has suffered an operating system crash), the second one (the replica) has the same IdM configuration.
To install a replica server, we are going to use a new system (myoracle3
) and perform the same preparation as for the primary IdM server (myoracle1
).
In this new system (myoracle3
), we have to open the required ports to avoid problems with IdM communications. Thus, the first step is to enable the firewall service by executing the following command as the root
user:
[root@myoracle3 ~]# systemctl enable firewalld.service
Include the LDAP port (389/TCP) into the firewall persistent configuration by creating a zone (a kind of container for rules) named public
in a configuration file, as shown below:
[root@myoracle3 ~]# firewall-cmd --permanent --zone=public --add-port=389/tcp
success
If you make a mistake and include incorrect port numbers, you can remove them by executing the same command except replace the add-port
parameter with the remove-port
parameter. All remaining keywords and values are the same.
Reload the firewall rules from the configuration file to make them active in memory by executing the next command:
[root@myoracle3 ~]# firewall-cmd --reload
success
Now we have to include the remaining ports into the firewall configuration file (permanent
option), as shown below:
[root@myoracle3 ~]# firewall-cmd --permanent --zone=public --add-port={123/udp,53/udp,53/tcp,80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,464/tcp,88/udp,464/udp}
success
Execute the following commands to reload the firewall rules from the configuration files and make them active in memory:
[root@myoracle3 ~]# firewall-cmd --reload
success
Additionally, we have to open the required ports for replication on both the master IdM server (myoracle1
) and the replica server (myoracle3
). In other words, there is a requirement to open a few ports that will be used to transfer (replicate) information from the primary IdM server to the secondary (replica) IdM server.
Therefore, these necessary ports are added into the firewall configuration file by running the following command:
[root@myoracle1 ~]# firewall-cmd --permanent --zone=public --add-port={9443/udp,9443/tcp,9444/tcp,9444/udp,9445/tcp,9445/udp,7389/tcp,7389/udp,22/tcp,22/udp}
Note: If you are configuring an exclusively Oracle Linux 7.2 configuration (as shown in this document), the 7389 port should be not required. Nonetheless, I kept it just in case someone is configuring a mixed environment that has both Oracle Linux 6 and 7.
In the same way, we have to reload the firewall service for making the firewall configuration active in memory, so execute the following command:
[root@myoracle1 ~]# firewall-cmd -reload
Remember that the replica server (myoracle3
) is an IdM sever, so the next step is to install the required packages (remember that there are 177 packages, so it takes few minutes), as shown below:
[root@myoracle3 ~]# yum install ipa-server bind bind-dyndb-ldap ipa-server-dns
On the master server (myoracle1
), we have to create the replica information file, which holds the configuration that will be used to configure the replica server.
Execute the following to create this replica information file. The parameter --ip-address
automatically creates A and PTR DNS records from the replica server (192.168.1.197) into the DNS server:
[root@myoracle1 ~]# ipa-replica-prepare myoracle3.example.com --ip-address 192.168.1.197
Directory Manager (existing master) password:
Preparing replica for myoracle3.example.com from myoracle1.example.com
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Saving dogtag Directory Server port
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/replica-info-myoracle3.example.com.gpg
Adding DNS records for myoracle3.example.com
Waiting for myoracle3.example.com. A or AAAA record to be resolvable
This can be safely interrupted (Ctrl+C)
The ipa-replica-prepare command was successful
In the next step, we have to create the replica information file and copy it to the replica server (myoracle3
). This step is necessary because we will use this replica information file to create a framework where the primary server (myoracle1
) can replicate all the IdM information to the replica server (myoracle3
). Therefore, execute the following command:
[root@myoracle1 ~]# scp /var/lib/ipa/replica-info-myoracle3.example.com.gpg root@myoracle3:/var/lib/ipa/
The authenticity of host 'myoracle3 (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is d1:9d:39:ac:43:f7:c4:4e:5a:b5:00:40:bf:a7:04:97.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myoracle3' (ECDSA) to the list of known hosts.
root@myoracle3's password: Aborges2016!
replica-info-myoracle3.example.com.gpg
100% 31KB 30.6KB/s 00:00
On the replica server (myoracle3
), execute the replication script by referencing the replica information file (copied by the last command), configuring the certificate authority (CA) (https://en.wikipedia.org/wiki/Certificate_authority) for the replica (--setup-ca
option), setting up the DNS server (--setup-ca
option), and including the DNS forwarder (https://en.wikipedia.org/wiki/Domain_Name_System) configuration (--forwarder
option), as shown below:
[root@myoracle3 ~]# ipa-replica-install --setup-ca --setup-dns --forwarder=8.8.8.8 --forwarder=8.8.4.4 /var/lib/ipa/replica-info-myoracle3.example.com.gpg
Directory Manager (existing master) password: Hacker123@
Existing BIND configuration detected, overwrite? [no]: yes
Checking DNS forwarders, please wait ...
Using reverse zone(s) 1.168.192.in-addr.arpa.
Run connection check to master
Check connection from replica to remote master 'myoracle1.example.com':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos Kpasswd: TCP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
The following list of ports use UDP protocol and would need to be
checked manually:
Kerberos KDC: UDP (88): SKIPPED
Kerberos Kpasswd: UDP (464): SKIPPED
Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@EXAMPLE.COM password: Otn2016!
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'myoracle3.example.com':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos KDC: UDP (88): OK
Kerberos Kpasswd: TCP (464): OK
Kerberos Kpasswd: UDP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
Connection from master to replica is OK.
Connection check OK
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
[1/38]: creating directory server user
[2/38]: creating directory server instance
[3/38]: adding default schema
[4/38]: enabling memberof plugin
[5/38]: enabling winsync plugin
...
[23/38]: restarting directory server
[24/38]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 4 seconds elapsed
Update succeeded
[25/38]: updating schema
[26/38]: setting Auto Member configuration
[27/38]: enabling S4U2Proxy delegation
[28/38]: importing CA certificates from LDAP
...
[37/38]: tuning directory server
[38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds
[1/23]: creating certificate server user
[2/23]: configuring certificate server instance
[3/23]: stopping certificate server instance to update CS.cfg
[4/23]: backing up CS.cfg
...
[21/23]: migrating certificate profiles to LDAP
[22/23]: importing IPA certificate profiles
[23/23]: adding default CA ACL
Done configuring certificate server (pki-tomcatd).
Restarting the directory and certificate servers
Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds
[1/8]: adding sasl mappings to the directory
[2/8]: configuring KDC
[3/8]: creating a keytab for the directory
[4/8]: creating a keytab for the machine
[5/8]: adding the password extension to the directory
[6/8]: enable GSSAPI for replication
[7/8]: starting the KDC
[8/8]: configuring KDC to start on boot
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring ipa_memcached
[1/2]: starting ipa_memcached
[2/2]: configuring ipa_memcached to start on boot
Done configuring ipa_memcached.
Configuring the web interface (httpd). Estimated time: 1 minute
[1/18]: setting mod_nss port to 443
[2/18]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2
[3/18]: setting mod_nss password file
[4/18]: enabling mod_nss renegotiate
...
[17/18]: restarting httpd
[18/18]: configuring httpd to start on boot
Done configuring the web interface (httpd).