Administering Oracle Linux 7.2--Part 2: Configuring and Integrating an Identity Management Server

Version 3

    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).

    Configuring ipa-otpd

      [1/2]: starting ipa-otpd

      [2/2]: configuring ipa-otpd to start on boot

    Done configuring ipa-otpd.

    Applying LDAP updates

    Upgrading IPA:

      [1/9]: stopping directory server

      [2/9]: saving configuration

      [3/9]: disabling listeners

      ...

      [9/9]: starting directory server

    Done.

    Restarting the directory server

    Restarting the KDC

    Configuring DNS (named)

      [1/9]: generating rndc key file

      [2/9]: setting up reverse zone

      ...

      [9/9]: 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

     

    Global DNS configuration in LDAP server is empty

    You can use 'dnsconfig-mod' command to set global DNS options that

    would override settings in local named.conf files

     

    Restarting the web server

     

    Now, we need to use a Kerberos ticket to test our configuration. So, the next command can be interpreted as a kind of an "administrative login":

     

    [root@myoracle3 ~]# kinit admin

    Password for admin@EXAMPLE.COM: Otn2016!

     

    Check the acquired ticked by running the following command:

     

    [root@myoracle3 ~]# klist

     

    Ticket cache: KEYRING:persistent:0:0

    Default principal: admin@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    02/11/2016 18:03:00  02/12/2016 18:02:53  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    To check whether the DNS entries were correctly created by the ipa-replica-prepare command, set the DOMAIN and NAMERVER environment variables, and execute the script, as shown below:

     

    [root@myoracle3 ~]# DOMAIN=example.com

    [root@myoracle3 ~]# NAMESERVER=myoracle3

    [root@myoracle3 ~]# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do echo ""; dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority; done | egrep -v "^;" | egrep _

     

    _ldap._tcp.example.com.     86400 IN  SRV  0 100 389 myoracle3.example.com.

    _ldap._tcp.example.com.     86400 IN  SRV  0 100 389 myoracle1.example.com.

    _kerberos._tcp.example.com. 86400 IN  SRV  0 100 88 myoracle1.example.com.

    _kerberos._tcp.example.com. 86400 IN  SRV  0 100 88 myoracle3.example.com.

    _kerberos._udp.example.com. 86400 IN  SRV  0 100 88 myoracle3.example.com.

    _kerberos._udp.example.com. 86400 IN  SRV  0 100 88 myoracle1.example.com.

    _kerberos-master._tcp.example.com. 86400 IN  SRV  0 100 88 myoracle3.example.com.

    _kerberos-master._tcp.example.com. 86400 IN  SRV  0 100 88 myoracle1.example.com.

    _kerberos-master._udp.example.com. 86400 IN  SRV  0 100 88 myoracle3.example.com.

    _kerberos-master._udp.example.com. 86400 IN  SRV  0 100 88 myoracle1.example.com.

    _ntp._udp.example.com.      86400  IN  SRV  0 100 123 myoracle3.example.com.

    _ntp._udp.example.com.      86400  IN  SRV  0 100 123 myoracle1.example.com.

     

    Additionally, to perform a complete test, let's create a new user on the replica server (myoracle3) and check whether the user is also created on the master server (myoracle1), as expected in our previous explanation.

     

    First, because the default shell configured in the IdM server for users is the Bourne shell, change it to bash:

     

    [root@myoracle3 ~]# ipa config-mod --defaultshell=/bin/bash

     

      Maximum username length: 32

      Home directory base: /home

      Default shell: /bin/bash

      Default users group: ipausers

      Default e-mail domain: example.com

      Search time limit: 2

      Search size limit: 100

      User search fields: uid,givenname,sn,telephonenumber,ou,title

      Group search fields: cn,description

      Enable migration mode: FALSE

      Certificate Subject base: O=EXAMPLE.COM

      Password Expiration Notification (days): 4

      Password plugin features: AllowNThash

      SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023

      Default SELinux user: unconfined_u:s0-s0:c0.c1023

      Default PAC types: nfs:NONE, MS-PAC

     

    Create a user named aborges2 in the replica server, as shown below:

     

    [root@myoracle3 ~]# ipa user-add aborges2

     

    First name: Alex

    Last name: Borges

    ---------------------

    Added user "aborges2"

    ---------------------

      User login: aborges2

      First name: Alex

      Last name: Borges

      Full name: Alex Borges

      ...

     

    Change the aborges2 user's password:

     

    [root@myoracle3 ~]# ipa passwd aborges2

     

    New Password: Test321&

    Enter New Password again to verify: Test321&

    -------------------------------------------

    Changed password for "aborges2@EXAMPLE.COM"

     

    To verify that the new user (aborges2) was correctly created in the LDAP database from the replica server (myoracle3), we need to use the ldapsearch command. Before proceeding, it is suitable to review the ldapsearch options shown below:

     

    • -x: specifies that simple authentication will be used instead of SASL (Simple Authentication and Security Layer)
    • -b: specifies the starting point for the search instead of using the default

     

    Now, perform the search by running the following command:

     

    [root@myoracle3 ~]# ldapsearch -x -b "dc=example, dc=com" uid=aborges2

     

    # extended LDIF

    #

    # LDAPv3

    # base <dc=example, dc=com> with scope subtree

    # filter: uid=aborges2

    # requesting: ALL

    #

     

    # aborges2, users, compat, example.com

    dn: uid=aborges2,cn=users,cn=compat,dc=example,dc=com

    cn: Alex Borges

    objectClass: posixAccount

    objectClass: ipaOverrideTarget

    objectClass: top

    gidNumber: 1695500500

    ipaAnchorUUID:: OklQQTpleGFtcGxlLmNvbTo3YjljNWIwMC1kMGZjLTExZTUtOWIwNy0wMDBjMj

    ljNzU2NmM=

    gecos: Alex Borges

    uidNumber: 1695500500

    loginShell: /bin/bash

    homeDirectory: /home/aborges2

    uid: aborges2

     

    # aborges2, users, accounts, example.com

    dn: uid=aborges2,cn=users,cn=accounts,dc=example,dc=com

    displayName: Alex Borges

    uid: aborges2

    objectClass: ipaobject

    objectClass: person

    objectClass: top

    objectClass: ipasshuser

    objectClass: inetorgperson

    objectClass: organizationalperson

    objectClass: krbticketpolicyaux

    objectClass: krbprincipalaux

    objectClass: inetuser

    objectClass: posixaccount

    objectClass: ipaSshGroupOfPubKeys

    objectClass: mepOriginEntry

    loginShell: /bin/bash

    initials: AB

    gecos: Alex Borges

    sn: Borges

    homeDirectory: /home/aborges2

    givenName: Alex

    cn: Alex Borges

    uidNumber: 1695500500

    gidNumber: 1695500500

     

    # search result

    search: 2

    result: 0 Success

     

    # numResponses: 3

    # numEntries: 2

     

    Now, to confirm that the new user (aborges2) was replicated to the master server (myoracle1), repeat the procedure on the IdM master server (myoracle1) and compare the results:

     

    [root@myoracle1 ~]# ldapsearch -x -b "dc=example, dc=com" uid=aborges2

     

    # extended LDIF

    #

    # LDAPv3

    # base <dc=example, dc=com> with scope subtree

    # filter: uid=aborges2

    # requesting: ALL

    #

     

    # aborges2, users, compat, example.com

    dn: uid=aborges2,cn=users,cn=compat,dc=example,dc=com

    cn: Alex Borges

    objectClass: posixAccount

    ...

     

    It is excellent. To make sure that replication is working in any situation, take down the network connection to the IdM master server (myoracle1). To accomplish this task, first list the existing connections by running the following command:

     

    [root@myoracle1 ~]# nmcli con show

     

    NAME  UUID                                  TYPE            DEVICE     

    eth0  9d294913-8cc7-491f-9779-cb90cc25200c  802-3-ethernet  eno16777736

     

    Take down the chosen connection and confirm that it is really down:

     

    [root@myoracle1 ~]# nmcli con down eth0

     

    [root@myoracle1 ~]# nmcli con show

    NAME  UUID                                  TYPE            DEVICE

    eth0  9d294913-8cc7-491f-9779-cb90cc25200c  802-3-ethernet  --    

     

    [root@myoracle1 ~]# ping www.oracle.com

    ping: unknown host www.oracle.com

     

    Now, create a new user (jdoe) on the IdM replica server (myoracle3) while the IdM master server (myoracle1) is down:

     

    [root@myoracle3 ~]# ipa user-add jdoe

     

    First name: John

    Last name: Doe

    -----------------

    Added user "jdoe"

    -----------------

      User login: jdoe

      First name: John

      Last name: Doe...

     

    Change the password for jdoe by executing the following command:

     

    [root@myoracle3 ~]# ipa passwd jdoe

     

    New Password: Oracle135!

    Enter New Password again to verify: Oracle135!

    ---------------------------------------

    Changed password for "jdoe@EXAMPLE.COM"

    ---------------------------------------

     

    Verify whether the new user (jdoe) is present in the LDAP database on the IdM replica server by running the following command:

     

    [root@myoracle3 ~]# ldapsearch -x -b "dc=example, dc=com" uid=jdoe

     

    # extended LDIF

    #

    # LDAPv3

    # base <dc=example, dc=com> with scope subtree

    # filter: uid=jdoe

    # requesting: ALL

    #

     

    # jdoe, users, compat, example.com

    dn: uid=jdoe,cn=users,cn=compat,dc=example,dc=com

    cn: John Doe

    ...

     

    Recover the network connection to the IdM master server (myoracle1), wait a few seconds, and then confirm that the jdoe user is also present there by using the ldapseach command, as shown below:

     

    [root@myoracle1 ~]# nmcli con up eth0

     

    [root@myoracle1 ~]# ldapsearch -x -b "dc=example, dc=com" uid=jdoe

     

    # extended LDIF

    #

    # LDAPv3

    # base <dc=example, dc=com> with scope subtree

    # filter: uid=jdoe

    # requesting: ALL

    #

     

    # jdoe, users, compat, example.com

    dn: uid=jdoe,cn=users,cn=compat,dc=example,dc=com

    cn: John Doe

    ...

     

    It's perfect! The IdM replication is working. It is also possible to check whether replicas are synchronized by executing the following command on myoracle1.example.com (the primary IPA server):

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM: Otn2016!

     

    [root@myoracle1 ~]# ipa-replica-manage list

    myoracle1.example.com: master

    myoracle3.example.com: master

     

    Lastly, enable the automatic home directory creation for users upon their first login (as we have done in the master IPA server) by executing the following command:

     

    [root@myoracle3 ~]# authconfig --enablemkhomedir --update

     

    We have finished the replica server configuration.

     

    Installing the IPA Client

     

    Finally, now it is time for the final milestone where we are going to configure the IdM client (myoracle2) to use our master and replica IdM servers.

     

    The first step is to open the required ports on the client (myoracle2), as shown below (these steps are similar to previous firewalls procedures):

     

    [root@myoracle2 ~]# systemctl enable firewalld.service

    [root@myoracle2 ~]# 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

     

    [root@myoracle2 ~]# firewall-cmd --reload

    success

     

    The next step is to install the required IdM client packages in the client (myoracle3) by running the following command:

     

    [root@myoracle2 ~]# yum install ipa-client ipa-admintools

     

    Before proceeding, we need to configure the DNS client settings on myoracle2 to point to myoracle1 (192.168.1.195) and myoracle3 (192.168.1.197). Thus, we list the existing connections by executing the next command:

     

    [root@myoracle2 ~]# nmcli con show

    NAME  UUID                                  TYPE            DEVICE     

    eth0  9d294913-8cc7-491f-9779-cb90cc25200c  802-3-ethernet  eno16777736

     

    Configure the DNS client setting to point to both DNS servers (myoracle1 and myoracle3) by executing the next commands:

     

    [root@myoracle2 ~]# nmcli con mod "eth0" ipv4.dns 192.168.1.195

    [root@myoracle2 ~]# nmcli con mod "eth0" +ipv4.dns 192.168.1.197

     

    Configure the domain search name by running the following command:

     

    [root@myoracle2 ~]# nmcli con mod "eth0" ipv4.dns-search example.com

     

    To force both configurations (DNS servers and domain search name) to take effect, bring down and bring up the network interface, as shown below:

     

    [root@myoracle2 ~]# nmcli con down "eth0"

    Connection 'eth0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/0)

     

    root@myoracle2 ~]# nmcli con up "eth0"

    Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)

     

    Check whether our changes were committed by running the next command:

     

    [root@myoracle2 ~]# nmcli con show "eth0" | grep ipv4.dns

    ipv4.dns:                               192.168.1.195,192.168.1.197

    ipv4.dns-search:                        example.com

     

    In the next step, we need to configure the NTP server on myoracle1 to accept requests from any host in the network. Therefore, we need to make changes in the /etc/ntpd.conf file so that instead of it reading like this:

     

     

    [root@myoracle1 ~]# grep restrict /etc/ntp.conf

     

    restrict default nomodify notrap nopeer noquery

    restrict 127.0.0.1

    restrict ::1

    # Hosts on local network are less restricted.

    #restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

     

     

    It reads like the following:

     

    [root@myoracle1 ~]# grep restrict /etc/ntp.conf

     

    restrict default nomodify notrap nopeer noquery

    #restrict 127.0.0.1

    #restrict ::1

    # Hosts on local network are less restricted.

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

     

    Restart the NTP server and check its status by executing the following commands:

     

    [root@myoracle1 ~]# systemctl restart ntpd

    [root@myoracle1 ~]# systemctl status ntpd

     

    ntpd.service - Network Time Service

       Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)

       Active: active (running) since Thu 2016-02-11 19:10:55 BRST; 10s ago

      Process: 40341 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)

    Main PID: 40342 (ntpd)

       CGroup: /system.slice/ntpd.service

               └─40342 /usr/sbin/ntpd -u ntp:ntp -g -x

     

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen and drop on 1

    v6wildcard :: UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen normally on 2 lo

    127.0.0.1 UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen normally on 3

    eno16777736 192.168.1.195 UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen normally on 4 virbr0

    192.168.122.1 UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen normally on 5 lo ::1

    UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listen normally on 6

    eno16777736 fe80::20c:29ff:fec9:d867 UDP 123

    Feb 11 19:10:55 myoracle1.example.com ntpd[40342]: Listening on routing socket on

    fd #23 for interface updates

    Feb 11 19:10:57 myoracle1.example.com ntpd[40342]: 0.0.0.0 c016 06 restart

    Feb 11 19:10:57 myoracle1.example.com ntpd[40342]: 0.0.0.0 c012 02 freq_set ntpd

    500.000 PPM

    Feb 11 19:10:57 myoracle1.example.com ntpd[40342]: 0.0.0.0 c615 05 clock_sync

     

    Finally, we can configure the IdM client by running the following command, which specifies the --enable-dns-update option to direct the SSSD (System Security Services Daemon) to update the DNS entries whenever the IP address changes because of the DHCP service (this is a very important step that allows a flexible and self-adaptable configuration). The --ntp-server option points to the NTP Server, the --mkhomedir option configures the PAM service to create the user's home directory if it doesn't exist, and the --ssh-trust-dns option configures the OpenSSH client to trust DNS SSHFP records. Therefore, execute the following:

     

    [root@myoracle2 ~]# ipa-client-install --enable-dns-update --ntp-server=myoracle1.example.com --mkhomedir --ssh-trust-dns

     

    Discovery was successful!

    Client hostname: myoracle2.example.com

    Realm: EXAMPLE.COM

    DNS Domain: example.com

    IPA Server: myoracle1.example.com

    BaseDN: dc=example,dc=com

     

    Continue to configure the system with these values? [no]: yes

    Synchronizing time with KDC...

    Attempting to sync time using ntpd.  Will timeout after 15 seconds

    User authorized to enroll computers: admin

    Password for admin@EXAMPLE.COM: Otn2016!

    Successfully retrieved CA cert

        Subject:     CN=Certificate Authority,O=EXAMPLE.COM

        Issuer:      CN=Certificate Authority,O=EXAMPLE.COM

        Valid From:  Wed Feb 10 21:17:57 2016 UTC

        Valid Until: Sun Feb 10 21:17:57 2036 UTC

     

    Enrolled in IPA realm EXAMPLE.COM

    Created /etc/ipa/default.conf

    New SSSD config will be created

    Configured sudoers in /etc/nsswitch.conf

    Configured /etc/sssd/sssd.conf

    Configured /etc/krb5.conf for IPA realm EXAMPLE.COM

    trying https://myoracle1.example.com/ipa/json

    Forwarding 'ping' to json server 'https://myoracle1.example.com/ipa/json'

    Forwarding 'ca_is_enabled' to json server 'https://myoracle1.example.com/ipa/json'

    Systemwide CA database updated.

    Added CA certificates to the default NSS database.

    Missing reverse record(s) for address(es): 192.168.1.196.

    Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub

    Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub

    Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub

    Forwarding 'host_mod' to json server 'https://myoracle1.example.com/ipa/json'

    SSSD enabled

    Configured /etc/openldap/ldap.conf

    NTP enabled

    Configured /etc/ssh/ssh_config

    Configured /etc/ssh/sshd_config

    Configuring example.com as NIS domain.

    Client configuration complete.

     

    We can confirm that our client host (myoracle2) was correctly added to the IPA server (myoracle1) database by performing a search, as shown below:

     

    [root@myoracle1 ~]# ipa host-find myoracle2.example.com

     

    --------------

    1 host matched

    --------------

      Host name: myoracle2.example.com

      Principal name: host/myoracle2.example.com@EXAMPLE.COM

      Password: False

      Keytab: True

      Managed by: myoracle2.example.com

      SSH public key fingerprint: 97:3A:3F:A3:FA:F7:F6:AE:6F:E9:75:D0:74:DA:40:44 (ssh-ed25519), D1:9D:39:AC:43:F7:C4:4E:5A:B5:00:40:BF:A7:04:97

                                  (ecdsa-sha2-nistp256), F1:5B:AE:D7:07:14:23:C8:88:E9:A8:24:FE:3F:01:97 (ssh-rsa)

    ----------------------------

    Number of entries returned 1

    ----------------------------

     

    Testing the IdM/IPA server

     

    To confirm that our configuration works well, let's search on the IdM server from the client (myoracle2) for few users and prove that they exist. Thus, execute the following sequence of commands:

     

    [root@myoracle2 ~]# kinit admin

    Password for admin@EXAMPLE.COM: Otn2016!

     

    [root@myoracle2 ~]# klist

    Ticket cache: KEYRING:persistent:0:0

    Default principal: admin@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    02/12/2016 18:41:19  02/13/2016 18:41:11  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    [root@myoracle2 ~]# ipa user-find admin

    --------------

    1 user matched

    --------------

      User login: admin

      Last name: Administrator

      Home directory: /home/admin

      Login shell: /bin/bash

      UID: 1695400000

      GID: 1695400000

      Account disabled: False

      Password: True

      Kerberos keys available: True

    ----------------------------

    Number of entries returned 1

    ----------------------------

     

    [root@myoracle2 ~]# ipa user-find aborges

    ---------------

    2 users matched

    ---------------

      User login: aborges

      First name: Alexandre

      Last name: Borges

      Home directory: /home/aborges

      ...

     

    We can search for the same users in the /etc/passwd database by using the getent command, as shown below:

     

    [root@myoracle2 ~]# getent passwd admin

    admin:*:1695400000:1695400000:Administrator:/home/admin:/bin/bash

     

    [root@myoracle2 ~]# getent passwd aborges

    aborges:x:1002:1002:Alexandre Borges:/home/aborges:/bin/bash

     

    It has worked and we proved that our client automatically goes to the IdM servers! Nevertheless, we can make a more-impressive test.

     

    Remember that we also created a user named aborges2 after configuring the replica server. Therefore, on myoracle2, we can use the GUI log out and log in again, but this time using the aborges2 user. Because it will be the first login of the aborges2 user, the system will request that we change the password. An interesting detail is that the aborges2 user doesn't exist locally on myoracle2, as shown below:

     

    [root@myoracle2 ~]# grep aborges2 /etc/passwd

    [root@myoracle2 ~]#

     

    After having executed a GUI login, open a terminal and execute the following commands to prove our previous explanation:

     

    [aborges2@myoracle2 ~]$ whoami

    aborges2

     

    [aborges2@myoracle2 ~]$ id

    uid=1695500500(aborges2) gid=1695500500(aborges2) groups=1695500500(aborges2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [aborges2@myoracle2 ~]$ klist

    Ticket cache: KEYRING:persistent:1695500500:krb_ccache_hRpb0h2

    Default principal: aborges2@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    02/12/2016 21:36:48  02/13/2016 21:36:48  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    It is amazing! The myoracle2 host doesn't have the aborges2 user, but it fetches the user and its credentials to authenticate aborges2 from the myoracle1 host (the IdM/IPA master server where Kerberos is configured). Of course, we could also have logged in to myoracle1 by using the su command, as shown below:

     

    [root@myoracle2 ~]# id

    uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [root@myoracle2 ~]# su - aborges2

    Last login: Fri Feb 12 21:36:48 BRST 2016 on :0

     

    [aborges2@myoracle2 ~]$ klist

    Ticket cache: KEYRING:persistent:1695500500:krb_ccache_hRpb0h2

    Default principal: aborges2@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    02/12/2016 21:38:55  02/13/2016 21:36:48  host/myoracle1.example.com@EXAMPLE.COM

    02/12/2016 21:36:48  02/13/2016 21:36:48  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    Once more, it is amazing!

     

    Testing the Kerberos SSO Aspect: the OpenSSH Application

     

    To execute a more real test, we can prove the SSO capabilities of the Kerberos (and, implicitly, of the IPA server) by performing a simple test. On the myoracle2 client system, use the GUI to  log on as aborges2, and then open a terminal and execute the following commands:

     

    [aborges2@myoracle2 ~]$ id

     

    uid=1695500500(aborges2) gid=1695500500(aborges2) groups=1695500500(aborges2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [aborges2@myoracle2 ~]$ whoami

    aborges2

     

    Before proceeding, check if the SSH server configuration file (/etc/ssh/sshd_config) has the following configuration (the options were explained in the first part of this series) for the myoracle1 and myoracle3 systems:

     

    [root@myoracle1 ~]# more /etc/ssh/sshd_config

    [root@myoracle3 ~]# more /etc/ssh/sshd_config

     

    # Kerberos options

    #KerberosAuthentication yes

    #KerberosOrLocalPasswd yes

    #KerberosTicketCleanup yes

    #KerberosGetAFSToken no

    #KerberosUseKuserok no

     

    # GSSAPI options

    GSSAPIAuthentication yes

    GSSAPICleanupCredentials yes

    #GSSAPIStrictAcceptorCheck yes

    GSSAPIKeyExchange yes

    #GSSAPIEnablek5users no

     

    Now, open an SSH connection to myoracle1 (the IPA master server) and prove our identity by executing the following commands:

     

    [aborges2@myoracle2 ~]$ ssh myoracle1.example.com

    Last login: Mon Feb 15 05:43:50 2016 from myoracle2.example.com

     

    [aborges2@myoracle1 ~]$ uname -a

    Linux myoracle1.example.com 3.8.13-118.3.1.el7uek.x86_64 #2 SMP Fri Jan 29 16:58:37 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

     

    [aborges2@myoracle1 ~]$ id

    uid=1695500500(aborges2) gid=1695500500(aborges2) groups=1695500500(aborges2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [aborges2@myoracle1 ~]$ klist

    Ticket cache: KEYRING:persistent:1695500500:krb_ccache_lrXVKNp

    Default principal: aborges2@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    02/15/2016 05:43:49  02/16/2016 05:43:49  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    Repeat the test by connecting using SSH to myoracle3 (the IPA replica server), as shown below:

     

    [aborges2@myoracle2 ~]$ ssh myoracle3.example.com

    Last login: Mon Feb 15 06:33:03 2016 from myoracle2.example.com

     

    [aborges2@myoracle3 ~]$ id

    uid=1695500500(aborges2) gid=1695500500(aborges2) groups=1695500500(aborges2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [aborges2@myoracle3 ~]$ uname -a

    Linux myoracle3.example.com 3.8.13-118.3.1.el7uek.x86_64 #2 SMP Fri Jan 29 16:58:37 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

     

    It is simply great! We have connected through SSH to myoracle1 and myoracle3 from myoracle2 without entering the password again, because we already logged in as aborges2 (we entered the password during the GUI login) and, thanks to Kerberos, we haven't needed to do it again! This doubtlessly proves the SSO feature from Kerberos!

     

    Integrating Oracle Linux 7.2 with Microsoft Active Directory

     

    This section presents theories and procedures explaining how to integrate Oracle Linux 7.2 with Microsoft Active Directory.

     

    Prerequisites

     

    Talking about the integration of Linux systems with Microsoft Active Directory has various meanings, because we could want either to enroll Oracle Linux 7.2 into Active Directory or configure Oracle Linux 7.2 as a peer to the Windows domain. In addition, these other planning issues need to be answered:

     

    • Where company users will be located?
    • How will these users authenticate on the Oracle Linux 7.2 server (our IPA server)? Are we going to use Active Directory as a user repository?
    • How are we going to plan and configure the existing groups?
    • What DNS server will be used?

     

    In this section, we are using a Windows 2012 Server with 2 GB of RAM, and it is configured as a domain controller. The domain is winexample.com and Active Directory will serve as our main database for users. Furthermore, a trust-based solution will be used, in which the IdM server (the IPA server) is used as a central server to control our Oracle Linux systems and, additionally, we establish a cross-realm Kerberos trust with Active Directory. Therefore, we are using the Kerberos server (on the IPA server) to establish trust, where the IPA server will be presented to Active Directory as a separate forest (an object type inside the Active Directory tree).

     

    The Windows 2012 Server system has 192.168.1.229 as its IP address, and it is recommended to check, by using the ping command, whether it can reach the other systems (myoracle1, myoracle2, and myoracle3).

     

    It is also necessary to configure the Windows 2012 DNS service to include a DNS reverse zone to make it possible to resolve from an IP address to a name (and vice versa). Although the purpose is not show how to perform all the details about basic Windows configuration, the next two commands show how to add an Active Directory integrated reverse lookup zone and a type PTR record inside the reverse zone by using the PowerShell:

     

    PS C:\> Add-DnsServerPrimaryZone -NetworkID "192.168.1.0/24" -ReplicationScope "Forest"

     

    PS C:\> Add-DnsServerResourceRecordPtr -Name "229" -ZoneName "1.168.192.in-addr.arpa" -AllowUpdateAny -PtrDomainName "win2012.winexample.com"

     

    If the GUI tool is the preferred option, so go to Server Manager -> DNS, right-click Win2012 Server, and select DNS Manager and, once there, create a reverse zone.

     

    To confirm that the reverse zone was created, execute the command shown in Figure 1 on Windows by using the PowerShell:

     

    f1.png

    Figure 1

     

    Open a command prompt on the Windows 2012 system and execute the following commands to check whether the DNS service is resolving IP addresses and the name of our Windows 2012 system:

     

    C:\> hostname

    Win2012

     

    C:\> nslookup win2012.winexample.local

    Server:  localhost

    Address:  ::1

     

    Name:    win2012.winexample.local

    Address:  192.168.1.229

     

     

    C:\> nslookup 192.168.1.229

    Server:  localhost

    Address:  ::1

     

    Name:    win2012.winexample.local

    Address:  192.168.1.229

     

    > exit

     

    It's interesting to notice that Windows 2012 cares about its DNS domain (example.local), so we should configure as a DNS forwarder server the IPA master server (myoracle1), as shown below:

     

    C:\> dnscmd 127.0.0.1 /ZoneAdd example.com /Forwarder 192.168.1.195

    DNS Server 127.0.0.1 created zone example.com:

     

    Command completed successfully.

     

    Connecting to Active Directory

     

    There is an important daemon named System Security Services Daemon (SSSD) that runs in Oracle Linux and provides access to several types of external authentication services such as Active Directory. The /etc/sssd/sssd.conf file is used to configure the SSSD and the default example is shown below:

     

    [root@myoracle1 ~]# more /etc/sssd/sssd.conf

     

    [domain/example.com]

     

    cache_credentials = True

    krb5_store_password_if_offline = True

    ipa_domain = example.com

    id_provider = ipa

    auth_provider = ipa

    access_provider = ipa

    ipa_hostname = myoracle1.example.com

    chpass_provider = ipa

    ipa_server = myoracle1.example.com

    ipa_server_mode = True

    ldap_tls_cacert = /etc/ipa/ca.crt

     

    [sssd]

     

    services = nss, sudo, pam, ssh

    config_file_version = 2

    domains = example.com

    [

    nss]

    memcache_timeout = 600

    homedir_substring = /home

     

    [pam]

     

    [sudo]

     

    [autofs]

     

    [ssh]

     

    [pac]

     

    [ifp]

     

    To start the integration of Oracle Linux with Active Directory, the /etc/sssd/sssd.conf file would be one of first files that we should edit and adapt for our environment. Nonetheless, because we would like to integrate the Active Directory (AD) with Kerberos (running as a service in our IPA master server) and with the Samba server, we have to run several different commands and manually configure several files, which take so much time. Thus, we will use the realm command to perform many tasks automatically and make our lives easier.

     

    Thus, our first task is to install the realmd package (in case it is not installed) on each Oracle Linux system by running the following commands:

     

    [root@myoracle1 ~]# yum install realmd

    [root@myoracle2 ~]# yum install realmd

    [root@myoracle3 ~]# yum install realmd

     

    To avoid facing problems with access to the Windows 2012 server, open the common Windows ports (138, 139, and 445) for each Linux system, as shown below:

     

    [root@myoracle1 ~]# firewall-cmd --permanent --zone=public --add-port={138/tcp,138/udp,139/tcp,139/udp,445/tcp,445/udp}

     

    [root@myoracle1 ~]# firewall-cmd --reload

     

    [root@myoracle2 ~]# firewall-cmd --permanent --zone=public --add-port={138/tcp,138/udp,139/tcp,139/udp,445/tcp,445/udp}

     

    [root@myoracle2 ~]# firewall-cmd --reload

     

    [root@myoracle3 ~]# firewall-cmd --permanent --zone=public --add-port={138/tcp,138/udp,139/tcp,139/udp,445/tcp,445/udp}

     

    [root@myoracle3 ~]# firewall-cmd --reload

     

    Remember that we have configured a DNS forwarder entry on Windows 2012, so it should be able to resolve its own domain (winexample.com) and forward requests that it is not able to resolve, such as example.com. In the same way, we have to configure a forwarder on the IPA server to forward any request for the winexample.com domain to the winexample.com DNS server (win2012.winexample.com).

     

    The first step is to disable the dnssec-validation setting (dnssec-validation=no) in all DNS servers from the example.com domain by editing the /etc/named.conf file. The reason for this procedure is to prevent problems while configuring the forwarder server for the winexample.com domain. After changing the setting in the IPA master server (myoracle1.example.com), we should see the following output:

     

    [root@myoracle1 ~]# more /etc/named.conf

    options {

       // turns on IPv6 for port 53; IPv4 is on by default for all ifaces

       listen-on-v6 {any;};

     

       // Put files that named is allowed to write in the data/ directory:

       directory "/var/named"; // the default

       dump-file            "data/cache_dump.db";

       statistics-file      "data/named_stats.txt";

       memstatistics-file   "data/named_mem_stats.txt";

     

       forward first;

       forwarders {

          8.8.8.8;

          8.8.4.4;

       };

     

       // Any host is permitted to issue recursive queries

       allow-recursion { any; };

     

       tkey-gssapi-keytab "/etc/named.keytab";

       pid-file "/run/named/named.pid";

     

       dnssec-enable yes;

       dnssec-validation no;

     

       /* Path to ISC DLV key */

       bindkeys-file "/etc/named.iscdlv.key";

    ...

     

    In the same way, make the same change on the IPA replica server (myoracle3), and you should see the following output:

     

    [root@myoracle3 ~]# grep -5 dnssec-validation /etc/named.conf

     

       tkey-gssapi-keytab "/etc/named.keytab";

       pid-file "/run/named/named.pid";

     

       dnssec-enable yes;

       dnssec-validation no;

     

       /* Path to ISC DLV key */

       bindkeys-file "/etc/named.iscdlv.key";

     

       managed-keys-directory "/var/named/dynamic";

     

    For our changes take effect, restart the IPA service on both IPA servers by executing the following command:

     

    [root@myoracle1 ~]# ipactl restart

     

    Restarting Directory Service

    Restarting krb5kdc Service

    Restarting kadmin Service

    Restarting named Service

    Restarting ipa_memcached Service

    Restarting httpd Service

    Restarting ipa-otpd Service

    Restarting ipa-dnskeysyncd Service

    Starting pki-tomcatd Service

    ipa: INFO: The ipactl command was successful

     

    [root@myoracle3 ~]# ipactl restart

     

    Stopping pki-tomcatd Service

    Restarting Directory Service

    Restarting krb5kdc Service

    Restarting kadmin Service

    Restarting named Service

    Restarting ipa_memcached Service

    Restarting httpd Service

    Restarting pki-tomcatd Service

    Restarting ipa-otpd Service

    Restarting ipa-dnskeysyncd Service

    ipa: INFO: The ipactl command was successful

     

    In rare situations, if the dnssec-validation didn't take effect, reboot the system.

     

    In the IPA master server, configure the forwarder for the winexample.com domain by running the following commands:

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM:

     

    [root@myoracle1 ~]# ipa dnsforwardzone-add winexample.com --forwarder=192.168.1.229 --forward-policy=only

     

    Server will check DNS forwarder(s).

    This may take some time, please wait ...

      Zone name: winexample.com.

      Active zone: TRUE

      Zone forwarders: 192.168.1.229

      Forward policy: only

     

    Where:

    • winexample.com specifies the desired forward domain
    • --forwarder specifies the authoritative DNS server of the winexample.com domain
    • --forward-policy=only forwards queries to the forwarder

     

    Check if all the DNS configuration is OK by executing the following commands:

     

    [root@myoracle1 ~]# ipa dnszone-find

     

    Zone name: 1.168.192.in-addr.arpa.

      Active zone: TRUE

      Authoritative nameserver: myoracle1.example.com.

      Administrator e-mail address: hostmaster.example.com.

      SOA serial: 1456351076

      SOA refresh: 3600

      SOA retry: 900

      SOA expire: 1209600

      SOA minimum: 3600

      Allow query: any;

      Allow transfer: none;

     

      Zone name: example.com.

      Active zone: TRUE

      Authoritative nameserver: myoracle1.example.com.

      Administrator e-mail address: hostmaster.example.com.

      SOA serial: 1456351076

      SOA refresh: 3600

      SOA retry: 900

      SOA expire: 1209600

      SOA minimum: 3600

      Allow query: any;

      Allow transfer: none;

      Allow in-line DNSSEC signing: FALSE

    ----------------------------

    Number of entries returned 2

    ----------------------------

     

    [root@myoracle1 ~]# ipa dnsconfig-show

      Global forwarders: 8.8.8.8, 8.8.4.4

     

    [root@myoracle1 ~]# ipa dnsforwardzone-find

      Zone name: winexample.com.

      Active zone: TRUE

      Zone forwarders: 192.168.1.229

      Forward policy: only

    ----------------------------

    Number of entries returned 1

    ----------------------------

     

    Make sure the following commands succeed:

     

    [root@myoracle1 ~]# dig SRV _ldap._tcp.winexample.com

    [root@myoracle1 ~]# dig SRV _ldap._tcp.example.com

     

    Finally, try to ping win2012.winexample.com from the IPA server:

     

    [root@myoracle1 ~]# ping win2012.winexample.com

     

    PING win2012.winexample.com (192.168.1.229) 56(84) bytes of data.

    64 bytes from 192.168.1.229: icmp_seq=1 ttl=128 time=1.29 ms

    64 bytes from 192.168.1.229: icmp_seq=2 ttl=128 time=0.298 ms

    ^C

     

    It's perfect!

     

    For the next step, add two users to win2012.winexample.com,  as shown below:

     

    C:\> net user alexandreb * /ADD /DOMAIN

     

    Type a password for the user:

    Retype the password to confirm:

    The command completed successfully.

     

    C:\> net user mark * /ADD /DOMAIN

     

    Type a password for the user:

    Retype the password to confirm:

    The command completed successfully.

     

    Proceeding with the Active Directory integration, execute (on each Oracle Linux system) the realm discover command to get the Active Directory domain configuration and a list of the packages that must be installed for the system to be enrolled into the domain, as shown in Listing 1:

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM:

     

    [root@myoracle1 ~]# realm discover winexample.com

     

    winexample.com

      type: kerberos

      realm-name: WINEXAMPLE.COM

      domain-name: winexample.com

      configured: no

      server-software: active-directory

      client-software: sssd

      required-package: oddjob

      required-package: oddjob-mkhomedir

      required-package: sssd

      required-package: adcli

      required-package: samba-common

    Listing 1

     

    According to the output in Listing 1, we have to install a few packages before proceeding. Therefore, execute the following command:

     

    [root@myoracle1 ~]# yum -y install oddjob oddjob-mkhomedir sssd adcli samba-common

     

    We have to repeat the last two commands on myoracle2 and myoracle3, as shown below (the output was omitted):

     

    [root@myoracle2 ~]# realm discover winexample.com

    [root@myoracle2 ~]# yum -y install oddjob oddjob-mkhomedir sssd adcli samba-common

    [root@myoracle3 ~]# realm discover winexample.com

    [root@myoracle3 ~]# yum -y install oddjob oddjob-mkhomedir sssd adcli samba-common

     

    Now we can join into the Active Directory domain (example.local) by running the following command on each Linux server:

     

    [root@myoracle1 ~]# realm join winexample.com

    Password for Administrator: [ENTER THE WINDOWS ADMINISTRATOR PASSWORD]

     

    [root@myoracle2 ~]# realm join winexample.com

    Password for Administrator: [ENTER THE WINDOWS ADMINISTRATOR PASSWORD]

     

    [root@myoracle3 ~]# realm join winexample.com

    Password for Administrator: [ENTER THE WINDOWS ADMINISTRATOR PASSWORD]

     

    Testing the Connectivity with Active Directory

     

    Run the following commands to test the system configuration after joining the domain by collecting information about the user that we created in Windows 2012:

     

    [root@myoracle1 ~]# id alexandreb@winexample.com

    uid=1902201105(alexandreb@winexample.com) gid=1902200513(domain users@winexample.com) groups=1902200513(domain users@winexample.com)

     

    This Windows user (alexandreb) wasn't created in the any Oracle Linux system, but he was created in windows2012.example.com. Nevertheless, we are able to connect by SSH to any Oracle Linux system using this Windows user by executing the following commands:

     

    [root@myoracle1 ~]# su - alexandreb@WINEXAMPLE.COM

    Creating home directory for alexandreb@winexample.com.

    Last login: Fri Mar 25 01:24:38 BRT 2016 from 192.168.1.229 on pts/3

     

    -sh-4.2$ bash

     

    [alexandreb@winexample.com@myoracle1 ~]$ id

    uid=1902201105(alexandreb@winexample.com) gid=1902201105(alexandreb@winexample.com) groups=1902201105(alexandreb@winexample.com),1902200513(domain users@winexample.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [alexandreb@winexample.com@myoracle1 ~]$ kinit alexandreb@WINEXAMPLE.COM

    Password for alexandreb@WINEXAMPLE.COM:

     

    [alexandreb@winexample.com@myoracle1 ~]$ ssh myoracle2.example.com

    The authenticity of host 'myoracle2.example.com (<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 'myoracle2.example.com' (ECDSA) to the list of known hosts.

    Creating home directory for alexandreb@winexample.com.

    Last login: Fri Mar 25 04:24:26 2016

     

    [alexandreb@winexample.com@myoracle2 ~]$ uname -a

    Linux myoracle2.example.com 3.8.13-118.4.2.el7uek.x86_64 #2 SMP Tue Mar 22 20:46:48 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

     

    The results are interesting because we were able to connect from myoracle1 to myoracle2 through SSH without typing any password.

     

    We are able to get a similar result by connecting through SSH from the myoracle2 system to the myoracle3 system, as shown below:

     

    [root@myoracle2 ~]# su - mark@WINEXAMPLE.COM

    Last login: Sat Mar 26 02:35:37 BRT 2016 on pts/1

     

    -sh-4.2$ bash

     

    [mark@winexample.com@myoracle2 ~]$ id

    uid=1902201108(mark@winexample.com) gid=1902201108(mark@winexample.com) groups=1902201108(mark@winexample.com),1902200513(domain users@winexample.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    [mark@winexample.com@myoracle2 ~]$ kinit mark@WINEXAMPLE.COM

    Password for mark@WINEXAMPLE.COM:

     

    [mark@winexample.com@myoracle2 ~]$ ssh myoracle3.example.com

    Last login: Sat Mar 26 02:38:15 2016

     

    -sh-4.2$ bash

     

    [mark@winexample.com@myoracle3 ~]$ uname -a

    Linux myoracle3.example.com 3.8.13-118.4.2.el7uek.x86_64 #2 SMP Tue Mar 22 20:46:48 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

     

    [mark@winexample.com@myoracle3 ~]$

     

    We have repeated the result. Thus, Windows 2012 has identified and authenticated the SSH login to an Oracle Linux system. It's fine.

     

    Nevertheless, we can do a much better and more meaningful test. Log out from your GUI session and try to log in again by using any of our Windows users (mark@WINEXAMPLE.COM or alexandreb@WINEXAMPLE.COM) and their respective passwords.

     

    After the GUI login, open a terminal and execute the following commands:

     

    [mark@winexample.com@myoracle2 ~]$ id

    uid=1902201108(mark@winexample.com) gid=1902201108(mark@winexample.com) groups=1902201108(mark@winexample.com),1902200513(domain users@winexample.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    mark@winexample.com@myoracle2 ~]$ whoami

    mark@winexample.com

     

    mark@winexample.com@myoracle2 ~]$ ssh myoracle3.example.com

    Last login: Sat Mar 26 04:19:39 2016 from myoracle2.example.com

     

    -sh-4.2$ bash

     

    [mark@winexample.com@myoracle3 ~]$ uname -a

    Linux myoracle3.example.com 3.8.13-118.4.2.el7uek.x86_64 #2 SMP Tue Mar 22 20:46:48 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux

    [mark@winexample.com@myoracle3 ~]$

     

    It is fantastic! We could log in to the myoracle2 system from the GUI by using a Windows user (mark@WINEXAMPLE.COM), open a terminal, and make an SSH connection to myoracle3 without typing any password. Finally, it's a true and full SSO login!

     

    Establishing Cross-Realm Trust Between Active Directory and the IdM Server

     

    Background

     

    As you might already know, Kerberos allows the configuration of trusted domains. In this scenario, where each realm has users and resources, a principal from a realm can request a ticket and, by using this acquired ticket, connect to a service in another realm. However, it is possible to go beyond this simple configuration. We could configure two separate Kerberos domains (one from the IdM Linux environment and the other from the Windows AD environment) to be integrated transparently (a cross-realm trust) to allow users from one realm to access resources in the other realm.

     

    The cross-realm trust configuration demands that Kerberos, LDAP, DNS, and certificate services from both sides (IdM and AD) interact cleanly with one another. Therefore, in this case, it is necessary to establish a trust relationship between two separates domains to allow users and services from different sides to communicate with each other (a two-way relationship, as shown in Figure 2).

     

    f2.png

    Figure 2

     

    The trust configuration could also be one-way. For example, the AD domain could access resources from the IdM domain, but the opposite would not be true. In that case, the identification and authorization would be centered in the AD domain.

     

    In operational terms, the cross-realm trust configuration shown above is composed of AD, the IPA server (to associate the AD user with the IdM group), Samba (it performs the user and group lookups on AD), and the System Security Services Daemon (SSSD; to cache user, group and ticket information, and to map Kerberos and DNS domains). From an IdM point of view, the AD users are external to the IdM domain. Therefore, these AD users are configured as external groups inside the IdM users.

     

    A very important point during the configuration of a cross-realm trust is that the DNS services from both sides (AD and IdM) must be working perfectly, so it is possible to resolve any host name from any domain. Thus, they have to be configured as shown in Figure 3:

     

    f3.png

    Figure 3

     

    Thus, before proceeding, check if both DNS servers (AD and IdM) can see each other.

     

    First, run the follow two commands on the IPA master server (myoracle1.example.com), as shown below:

     

    [root@myoracle1 ~]# dig SRV _ldap._tcp.example.com

     

    ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> SRV _ldap._tcp.example.com

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37037

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

     

    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 4096

    ;; QUESTION SECTION:

    ;_ldap._tcp.example.com.      IN   SRV

     

    ;; ANSWER SECTION:

    _ldap._tcp.example.com.   86400   IN   SRV   0 100 389 myoracle3.example.com.

    _ldap._tcp.example.com.   86400   IN   SRV   0 100 389 myoracle1.example.com.

     

    ;; AUTHORITY SECTION:

    example.com.      86400   IN   NS   myoracle3.example.com.

    example.com.      86400   IN   NS   myoracle1.example.com.

     

    ;; ADDITIONAL SECTION:

    myoracle1.example.com.   1200   IN   A   192.168.1.195

    myoracle3.example.com.   1200   IN   A   192.168.1.197

     

    ;; Query time: 2 msec

    ;; SERVER: 192.168.1.195#53(192.168.1.195)

    ;; WHEN: Wed Mar 23 03:00:14 BRT 2016

    ;; MSG SIZE  rcvd: 193

     

    [root@myoracle1 ~]# dig SRV _ldap._tcp.winexample.com

     

    ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> SRV _ldap._tcp.winexample.com

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26262

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 2

     

    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 4096

    ;; QUESTION SECTION:

    ;_ldap._tcp.winexample.com.   IN   SRV

     

    ;; ANSWER SECTION:

    _ldap._tcp.winexample.com. 600   IN   SRV   0 100 389 win2012.winexample.com.

     

    ;; AUTHORITY SECTION:

    ..........8319   IN   NS   h.root-servers.net.

    ..........8319   IN   NS   k.root-servers.net.

    ..........8319   IN   NS   e.root-servers.net.

    .........8319   IN   NS   f.root-servers.net.

    ..........8319   IN   NS   i.root-servers.net.

    ..........8319   IN   NS   b.root-servers.net.

    ..........8319   IN   NS   g.root-servers.net.

    ..........8319   IN   NS   m.root-servers.net.

    ..........8319   IN   NS   a.root-servers.net.

    ..........8319   IN   NS   l.root-servers.net.

    ..........8319   IN   NS   j.root-servers.net.

    ..........8319   IN   NS   d.root-servers.net.

    ..........8319   IN   NS   c.root-servers.net.

     

    ;; ADDITIONAL SECTION:

    win2012.winexample.com.   3347   IN   A   192.168.1.229

     

    ;; Query time: 3 msec

    ;; SERVER: 192.168.1.195#53(192.168.1.195)

    ;; WHEN: Wed Mar 23 03:00:36 BRT 2016

    ;; MSG SIZE  rcvd: 323

     

    Now, check the AD domain server (win2012.winexample.com), as shown below:

     

    C:\> nslookup

     

    Default Server:  win2012.winexample.com

    Address:  192.168.1.229

     

    > set type=srv

    > _ldap._tcp.winexample.com

     

    Default Server:  win2012.winexample.com

    Address:  192.168.1.229

     

    _ldap._tcp.winexample.com       SRV service location:

              priority       = 0

              weight         = 100

              port           = 389

              svr hostname   = win2012.winexample.com

    win2012.winexample.com  internet address = 192.168.1.229

     

    > _ldap._tcp.example.com

    Default Server:  win2012.winexample.com

    Address:  192.168.1.229

     

    Non-authoritative answer:

    _ldap._tcp.example.com  SRV service location:

              priority       = 0

              weight         = 100

              port           = 389

              svr hostname   = myoracle1.example.com

    _ldap._tcp.example.com  SRV service location:

              priority       = 0

              weight         = 100

              port           = 389

              svr hostname   = myoracle3.example.com

     

    myoracle1.example.com   internet address = 192.168.1.195

    myoracle3.example.com   internet address = 192.168.1.197

     

    > exit

     

    C:\>

     

    Both DNS server configurations are working well. It's time to configure the cross-realm trust relationship.

     

    Practical Implementation

     

    To configure a cross-realm trust agreement, we are using an Oracle Linux 7.2 and Windows 2012 Server. Alternatively, we could use a previous version of the Windows, such as Windows 2008 R2.

     

    It's interesting to note that Kerberos realm names use uppercase, so domains names such as example.com (for IdM) and winexample.com (for AD) are required to be EXAMPLE.COM and WINEXAMPLE.COM, respectively.

     

    Another relevant action is to check whether ports such as 138 (TCP/UDP), 139 (TCP/UDP), 389 (UDP), and 445 (TCP and UDP) are open in the firewall. If they are not, execute the following steps on the myoracle1, myoracle2, and myoracle3 systems:

     

    [root@myoracle1 ~]# firewall-cmd --permanent --zone=public --add-port={138/tcp,138/udp,139/tcp,139/udp,389/udp,445/tcp,445/udp}

    success

     

    [root@myoracle1 ~]# firewall-cmd --reload

    success

     

    [root@myoracle1 ~]# firewall-cmd --zone=public --list-all

    public (default, active)

      interfaces: eno16777736

      sources:

      services: dhcpv6-client ssh

      ports: 80/tcp 464/tcp 9443/tcp 88/udp 9444/udp 7389/udp 139/tcp 389/tcp 53/tcp 9443/udp 138/tcp 7389/tcp 9445/tcp 22/tcp 139/udp 123/udp 9444/tcp 138/udp 445/udp 636/tcp 443/tcp 464/udp 88/tcp 22/udp 445/tcp 389/udp 53/udp 9445/udp

      masquerade: no

      forward-ports:

      icmp-blocks:

      rich rules:

     

    We are ready to start. First, install the IdM trust package by running the following command:

     

    [root@myoracle1 ~]# yum install "*ipa-server-trust-ad"

     

    Before proceeding, save your Samba configuration file by running the next couple of commands:

     

    [root@myoracle1 ~]# mkdir /backup

    [root@myoracle1 ~]# cp /etc/samba/smb.conf /backup

     

    Enable the trust services by running the command shown in Listing 2:

     

    [root@myoracle1 ~]# ipa-adtrust-install

     

    The log file for this installation can be found in /var/log/ipaserver-install.log

    ==============================================================================

    This program will setup components needed to establish trust to AD domains for

    the IPA Server.

     

    This includes:

      * Configure Samba

      * Add trust related objects to IPA LDAP server

     

    To accept the default shown in brackets, press the Enter key.

     

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration.

     

     

    Do you wish to continue? [no]: yes

    Do you want to enable support for trusted domains in Schema Compatibility plugin?

    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.

     

    Enable trusted domains support in slapi-nis? [no]: yes

     

    Configuring cross-realm trusts for IPA server requires password for user 'admin'.

    This user is a regular system account used for IPA server administration.

     

    admin password: Otn2016!

     

    Enter the NetBIOS name for the IPA domain.

    Only up to 15 uppercase ASCII letters and digits are allowed.

    Example: EXAMPLE.

     

     

    NetBIOS domain name [EXAMPLE]: [ENTER]

     

     

    WARNING: 7 existing users or groups do not have a SID identifier assigned.

    Installer can run a task to have ipa-sidgen Directory Server plugin generate

    the SID identifier for all these users. Please note, the in case of a high

    number of users and groups, the operation might lead to high replication

    traffic and performance degradation. Refer to ipa-adtrust-install(1) man page

    for details.

     

    Do you want to run the ipa-sidgen task? [no]: yes

     

    The following operations may take some minutes to complete.

    Please wait until the prompt is returned.

     

    Configuring CIFS

      [1/23]: stopping smbd

      [2/23]: creating samba domain object

      [3/23]: creating samba config registry

      [4/23]: writing samba config file

      [5/23]: adding cifs Kerberos principal

      [6/23]: adding cifs and host Kerberos principals to the adtrust agents group

      [7/23]: check for cifs services defined on other replicas

      [8/23]: adding cifs principal to S4U2Proxy targets

      [9/23]: adding admin(group) SIDs

      [10/23]: adding RID bases

      [11/23]: updating Kerberos config

    'dns_lookup_kdc' already set to 'true', nothing to do.

      [12/23]: activating CLDAP plugin

      [13/23]: activating sidgen task

      [14/23]: configuring smbd to start on boot

      [15/23]: adding special DNS service records

      [16/23]: enabling trusted domains support for older clients via Schema Compatibility plugin

      [17/23]: restarting Directory Server to take MS PAC and LDAP plugins changes into account

      [18/23]: adding fallback group

      [19/23]: adding Default Trust View

      [20/23]: setting SELinux booleans

      [21/23]: enabling oddjobd

      [22/23]: starting CIFS services

      [23/23]: adding SIDs to existing users and groups

    Done configuring CIFS.

     

    =============================================================================

    Setup complete

     

    You must make sure these network ports are open:

       TCP Ports:

         * 138: netbios-dgm

         * 139: netbios-ssn

         * 445: microsoft-ds

       UDP Ports:

         * 138: netbios-dgm

         * 139: netbios-ssn

         * 389: (C)LDAP

         * 445: microsoft-ds

     

    =============================================================================

    Listing 2

     

    Here are a few comments about the choices made in Listing 2:

     

    • We answered "yes" to the question about enabling support in slapd-nis because the slapi-nis plugin is a compatibility plugin that allows older Linux clients to work with trusted users.
    • Remember that the NETBIOS name is usually the far-left component of the domain name. Therefore, because our domain name is example.com (and the Kerberos realm requires uppercase), we have kept "EXAMPLE."
    • Because we had seven users/groups that do not have an SID identifier assigned, the installer automatically generated them.
    • At end of the output, there is a note about what ports must be open (we have already opened them!).

     

    Test whether Samba responds to Kerberos authentication from the IdM system (myoracle1), as shown below:

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM: Otn2016!

     

    [root@myoracle1 ~]# smbclient -L myoracle1.example.com -k

     

    lp_load_ex: changing to config backend registry

    Domain=[EXAMPLE] OS=[Windows 6.1] Server=[Samba 4.2.3]

     

       Sharename       Type      Comment

       ---------       ----      -------

       IPC$            IPC       IPC Service (Samba 4.2.3)

    Domain=[EXAMPLE] OS=[Windows 6.1] Server=[Samba 4.2.3]

     

       Server               Comment

       ---------            -------

     

       Workgroup            Master

       ---------            -------

     

    Run the following command to create a two-way trust agreement (that enables IdM users/groups to access resources in AD and vice-versa) between the AD domain (winexample.com) and the IdM (IPA) domain:

     

    [root@myoracle1 ~]# ipa trust-add --type=ad winexample.com --admin Administrator --password --two-way=true

     

    Active Directory domain administrator's password: [ENTER THE ADMINISTRATOR PASSWORD]

    -------------------------------------------------------

    Added Active Directory trust for realm "winexample.com"

    -------------------------------------------------------

      Realm name: winexample.com

      Domain NetBIOS name: WINEXAMPLE

      Domain Security Identifier: S-1-5-21-4199127807-1472518960-3673672087

      SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,

                              S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18

      SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,

                              S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18

      Trust direction: Two-way trust

      Trust type: Active Directory domain

      Trust status: Established and verified

     

    The options above are self-explanatory, but there is a point that it is suitable to explain. If we hadn't forced the "two-way=true" option, the trust agreement would have been configured as one-way and then AD users/groups could access the IdM (IPA) resources, but the inverse wouldn't be allowed.

     

    We can test the Kerberos configuration in several ways. For example, from a client system (myoracle2), request a ticket for an IdM user by running the following command:

     

    [root@myoracle2 ~]# su - aborges2

    Last login: Mon Mar 21 20:19:43 BRT 2016 on :0

     

    [aborges2@myoracle2 ~]$ kinit aborges2

    Password for aborges2@EXAMPLE.COM:

     

    Now, run the following command from the same client system to request service tickets for services running inside of the IdM domain:

     

    [aborges2@myoracle2 ~]$ kvno -S host myoracle1.example.com

    host/myoracle1.example.com@EXAMPLE.COM: kvno = 2

     

    Finally, run the following command to request service tickets for services running inside the AD domain:

     

    [aborges2@myoracle2 ~]$ kvno -S cifs win2012.winexample.com

    cifs/win2012.winexample.com@: kvno = 4

     

    List all tickets (-A option) by running the following command:

     

    [aborges2@myoracle2 ~]$ klist -A

    Ticket cache: KEYRING:persistent:1695500500:1695500500

    Default principal: aborges2@EXAMPLE.COM

     

    Valid starting       Expires              Service principal

    03/24/2016 03:30:21  03/24/2016 13:30:21  cifs/win2012.winexample.com@WINEXAMPLE.COM

    03/24/2016 03:30:21  03/24/2016 13:30:21  cifs/win2012.winexample.com@

    03/24/2016 03:30:26  03/25/2016 03:28:21  krbtgt/WINEXAMPLE.COM@EXAMPLE.COM

    03/24/2016 03:29:01  03/25/2016 03:28:21  host/myoracle1.example.com@EXAMPLE.COM

    03/24/2016 03:28:26  03/25/2016 03:28:21  krbtgt/EXAMPLE.COM@EXAMPLE.COM

     

    It looks like everything is OK so far.

     

    To allow us to set access permissions, manage the host-based access control, and manage other controls, we have to create an external group (--external option) in the IdM domain (example.com) for AD users. Thus, execute the following command to create the external group:

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM:

     

    [root@myoracle1 ~]# ipa group-add --desc='AD user in the external group' external_ad_group --external

    -------------------------------

    Added group "external_ad_group"

    -------------------------------

      Group name: external_ad_group

      Description: AD user in the external group

     

    Because IdM policies must be administered, create an IdM POSIX group, as shown below:

     

    [root@myoracle1 ~]# ipa group-add --desc='Users from AD domain' ad_users_group

    ----------------------------

    Added group "ad_users_group"

    ----------------------------

      Group name: ad_users_group

      Description: Users from AD domain

      GID: 1695400006

     

    A simple trick follows. Add the existing and default WINEXAMPLE\Domain Admins group into the external_ad_group IdM external group (yes, we are adding one group inside another group), as shown below:

     

    [root@myoracle1 samba]# ipa group-add-member external_ad_group --external "WINEXAMPLE\Domain Admins"

    [member user]:

    [member group]:

      Group name: external_ad_group

      Description: AD user in the external group

      External member: S-1-5-21-4199127807-1472518960-3673672087-513, S-1-5-21-4199127807-1472518960-3673672087-512

    -------------------------

    Number of members added 1

    -------------------------

     

    Now, run the following command to add the external IdM group (external_ad_group) into the POSIX IdM group (ad_users_group) as a member:

     

    [root@myoracle1 ~]# ipa group-add-member ad_users_group --groups

    external_ad_group

     

    Group name: ad_users_group

      Description: Users from AD domain

      GID: 1695400006

      Member groups: external_ad_group

    -------------------------

    Number of members added 1

     

    In the nutshell, we have inserted all AD users into an IdM POSIX group. Therefore, these AD users can access protected resources in the IPA (IdM) domain because they were mapped.

     

    Finally, insert the bold lines shown in the output below into the /etc/krb5.conf file from myoracle1 to normalize and map problems with AD accounts and realms with POSIX IPA accounts and realms:

     

    [root@myoracle1 ~]# more /etc/krb5.conf

    ...

    [realms]

    EXAMPLE.COM = {

      kdc = myoracle1.example.com:88

      master_kdc = myoracle1.example.com:88

      admin_server = myoracle1.example.com:749

      default_domain = example.com

      pkinit_anchors = FILE:/etc/ipa/ca.crt

      auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@WINEXAMPLE.COM/@winexample.com/

      auth_to_local = DEFAULT

    }

     

    Test 1: SSH from Windows

     

    Finally, it's time to perform few tests. Because we have already mapped the domain users groups from AD to the IdM domain, we should be able to connect to any host from the example.com IdM domain.

     

    First, download the Putty tool to your Windows 2012 controller (AD server).

     

    On the win2012.winexample.com system, we are already logged on as Administrator. Thus, open the Putty tool and connect to the myoracle2.example.com host as Administrator@winexample.com (an AD user), as shown in Figure 4:

     

    f4.png

    Figure 4

     

    The Putty tool will open a terminal in which you can type in the username, so we can use the Administrator@winexample.com username (we should not forget to specify the AD domain, because it is an AD user), as shown below:

     

    login as: Administrator@winexample.com

    Last login: Fri Mar 25 01:39:37 2016 from 192.168.1.229

     

    [administrator@winexample.com@myoracle2 ~]$ uname -a

    Linux myoracle2.example.com 3.8.13-118.3.1.el7uek.x86_64 #2 SMP Fri Jan 29

    16:58:37 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

     

    [administrator@winexample.com@myoracle2 ~]$ id

     

    uid=1902200500(administrator@winexample.com) gid=1902200513(domain

    users@winexample.com) groups=1902200513(domain

    users@winexample.com),1902200512(domain admins@winexample.com),1902200518(schema

    admins@winexample.com),1902200519(enterprise

    admins@winexample.com),1902200520(group policy creator

    owners@winexample.com),1902200572(denied rodc password replication

    group@winexample.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

     

    It is outstanding: we used a typical Windows username, and we logged in to the Oracle Linux system without entering any password! We can use any Windows username to log in to any host from the IdM (IPA) domain.

     

    Test 2: Integrating the Samba, Kerberos, and Active Directory Services (ADS)

     

    Samba is a suite that is usually deployed in a Linux environment to allow interoperability with Windows systems (file systems and printers) by making the Linux clients appear to be a Windows client. Furthermore, it allows the Linux system to join an AD Kerberos realm during the use of Samba. As result, it is possible to use AD for identifying and authenticating access to Windows shared folders and printers using the SSO (single sign-on) feature.

     

    To implement the Samba framework, which is integrated with AD, it is necessary to enable and configure the following services:

     

    • The Samba framework, which has a main configuration file called /etc/samba/smb.conf.
    • The DNS service, for which the local DNS client must be configured to use the AD as its domain controller.
    • The Kerberos framework, which we must configure to use AD as its KDC
    • PAM (Pluggable Authentication Module) and NSS (Name Service Switch), which allow applications to use the Kerberos authentication feature that is provided by AD. The main configuration files are /etc/pam.d/system-auth, /etc/security/pam_winbind.conf (PAM service), and /etc/nssswitch.conf (NSS).

     

    It would be better to take a new machine (for example, a possible myoracle4.example.com system) to perform these tests, but because we don't have infinite memory and disk space, let's choose myoracle2.example.com as the Samba server. So, to configure the scenario above, execute the following steps:

     

    1. As shown below, in the myoracle2 host, install the samba-windbind, sssd-libwbclient, samba, and samba-client packages, which are required for Windows integration and Samba services as shown below:

     

    [root@myoracle2 ~]# yum -y install sssd-libwbclient samba samba-client samba-winbind

     

    2. Install the kbr5-workstation package (it was already was installed by the IPA service):

     

    [root@myoracle2 ~]# yum install krb5-workstation

     

    3. On the IPA server, create the Common Internet File System (CIFS) principal for the Samba server by executing the following command:

     

    [root@myoracle1 ~]# kinit admin

    Password for admin@EXAMPLE.COM:

     

    [root@myoracle1 ~]# ipa service-add cifs/myoracle2.example.com

    ------------------------------------------------------

    Added service "cifs/myoracle2.example.com@EXAMPLE.COM"

    ------------------------------------------------------

      Principal: cifs/myoracle2.example.com@EXAMPLE.COM

      Managed by: myoracle2.example.com

     

    4. Install the keytab file on the Samba server (myoracle2) by executing the following command, where -s means the IPA server, -p means principal, and -k indicates the keytab:

     

    [root@myoracle2 ~]# ipa-getkeytab -s myoracle1.example.com -p cifs/myoracle2.example.com -k /etc/samba/samba.keytab

     

    5. For the Windows system to be able to access the Samba shares, we must put the Samba server in the same realm as the Windows AD server (winexample.com). Thus, execute the commands shown in Listing 3 to save the existing configuration files and to alter a few parameters in several files:

     

    [root@myoracle2 ~]# mkdir /backup

    [root@myoracle2 ~]# cp /etc/krb5.conf  /backup/

    [root@myoracle2 ~]# cp /etc/samba/smb.conf  /backup

    [root@myoracle2 ~]# rm /etc/samba/smb.conf 

    [root@myoracle2 ~]# touch /etc/samba/smb.conf

     

    [root@myoracle2 ~]# authconfig --smbsecurity=ads --update 

    [root@myoracle2 ~]# authconfig --smbworkgroup=WINEXAMPLE --update 

    [root@myoracle2 ~]# authconfig --update --smbrealm=WINEXAMPLE.COM

    [root@myoracle2 ~]# authconfig --update --smbservers=win2012.winexample.com

    [root@myoracle2 ~]# authconfig --update --krb5realm=WINEXAMPLE.COM

    [root@myoracle2 ~]# authconfig --enablesssdauth --update

    [root@myoracle2 ~]# authconfig --enablemkhomedir --update

    [root@myoracle2 ~]# authconfig --enablewinbindkrb5 --update

    Listing 3

     

       These few options in Listing 3 seem obvious, but they and other possible options that are not shown, deserve a quick explanation:

     

    • --smbsecurity=ads is one of security modes that configure the Samba server as a domain member server within an AD domain.
    • --smbworkgroup configures the Winbind domain in the /etc/samba/smb.conf file (workgroup parameter).
    • --smbrealm configures the Winbind ADS (Active Directory Service) domain in the /etc/samba/smb.conf (realm parameter) and /etc/krb5.conf (default_realm and REALMNAME parameters) files. These files are related to Samba and Kerberos services.
    • --smbservers configures the Winbind Domain Controllers (Kerberos service) in the /etc/krb5.conf file (the KDC in the realm entry, which is represented by the REALMNAME parameter).
    • --krb5realm configures the Kerberos realm in the /etc/krb5.conf file (the domain parameter).
    • --enablewinbindoffline configures Winbind to allow offline login.
    • --enablewinbindkrb5 configures authentication functions through the /etc/pam.d/system-auth file.
    • --winbindtemplateshell sets which login shell to use for Windows user account settings.
    • --winbindjoin automatically runs the net join command to add the system to the AD domain.
    • --enablelocauthorize configures the local authorization mechanism to first check the /etc/passwd file.
    • --savebackup backs up the configuration files to the specified directory before making the changes.
    • --enablewinbind configures user information services in the /etc/nsswitch.conf file (shadows, group, and passwd parameters).
    • --enablewins configures user information services in the /etc/nsswitch.conf file (hosts parameter).
    • --enablewinbindauth configures authentication functions via the /etc/pam.d/system-auth file (sessions, password, account, and auth parameters).
    • --enablesssdauth enables the integration of Windows AD with Samba, providing AD identification and authentication to the Samba service through a map between AD SIDs (security IDs) and Linux UIDs.
    • --enablemkhomedir creates the user's home directory if it doesn't exist.

     

    The final /etc/krb5.conf file should be like what's shown below. If it is not, you can manually edit the file and make the appropriate changes:

     

    [root@myoracle2 ~]# more /etc/krb5.conf

     

    #File modified by ipa-client-install

     

    includedir /var/lib/sss/pubconf/krb5.include.d/

     

    [libdefaults]

    default_realm = WINEXAMPLE.COM

    dns_lookup_realm = true

    dns_lookup_kdc = true

      rdns = false

      ticket_lifetime = 24h

      forwardable = yes

      udp_preference_limit = 0

      default_ccache_name = KEYRING:persistent:%{uid}

     

     

    [realms]

      EXAMPLE.COM = {

        pkinit_anchors = FILE:/etc/ipa/ca.crt

     

      }

     

     

    WINEXAMPLE.COM = {

      kdc = win2012.winexample.com

    }

     

    [domain_realm]

      .example.com = EXAMPLE.COM

      example.com = EXAMPLE.COM

     

     

    winexample.com = WINEXAMPLE.COM

    .winexample.com = WINEXAMPLE.COM

     

    6. Complete the Samba configuration file (/etc/samba/smb.conf), as shown in Listing 4:

     

    [root@myoracle2 ~]# more /etc/samba/smb.conf

     

    [global]

    #--authconfig--start-line--

     

    # Generated by authconfig on 2016/03/26 22:17:32

    # DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--)

    # Any modification may be deleted or altered by authconfig in future

     

       workgroup = WINEXAMPLE

       realm = WINEXAMPLE.COM

       security = ads

       idmap config * : range = 16777216-33554431

       template shell = /bin/false

       kerberos method = secrets and keytab

       winbind use default domain = false

       winbind offline logon = false

     

    #--authconfig--end-line--

            dedicated keytab file = FILE:/etc/samba/samba.keytab

            log file = /var/log/samba/log.%m

     

    [backup]

            path = /backup

            writable = yes

            browsable=yes

            write list = @ad_users_group

    Listing 4

     

    In the configuration file in Listing 4, we are using a dedicated keytab file to store principals and encrypted keys to allow the Samba service authentication. Furthermore, we are choosing a log file location and format, creating two shares (home directories and backup), where the latter will be accessible only by users from the ad_users_group group.

     

    The Samba parameter verification can be done by executing the following command:

     

    [root@myoracle2 ~]# testparm -s

     

    Load smb config files from /etc/samba/smb.conf

    rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)

    Processing section "[backup]"

    Loaded services file OK.

    Server role: ROLE_DOMAIN_MEMBER

     

    # Global parameters

    [global]

       workgroup = WINEXAMPLE

       realm = WINEXAMPLE.COM

       security = ADS

       dedicated keytab file = FILE:/etc/samba/samba.keytab

       kerberos method = secrets and keytab

       log file = /var/log/samba/log.%m

       idmap config * : range = 16777216-33554431

       idmap config * : backend = tdb

     

     

    [backup]

       path = /backup

       write list = @ad_users_group

       read only = No

     

    ...

     

    7. Open the firewall to the Samba service by executing the following commands:

     

    [root@myoracle2 ~]# firewall-cmd --permanent --zone=public --add-service=samba

    [root@myoracle2 ~]# firewall-cmd --reload

     

    8. Enable and start both the smb and nmb services, as shown below:

     

    [root@myoracle2 ~]# systemctl start smb.service

    [root@myoracle2 ~]# systemctl start nmb.service

     

    [root@myoracle2 ~]# systemctl enable nmb.service

    Created symlink from /etc/systemd/system/multi-user.target.wants/nmb.service to /usr/lib/systemd/system/nmb.service.

     

    [root@myoracle2 ~]# systemctl enable smb.service

    Created symlink from /etc/systemd/system/multi-user.target.wants/smb.service to /usr/lib/systemd/system/smb.service.

     

    9. Copy a few files (any files will do) to the /backup directory, and adjust the SELinux permissions for this directory, as shown below:

     

    [root@myoracle2 ~]# cp /etc/host* /backup

    [root@myoracle2 ~]# semanage fcontext -a -t samba_share_t "/backup(/.*)?"

    [root@myoracle2 ~]# restorecon -R -v /backup

     

    10. From the Samba client (myoracle3.example.com), test the availability of the Samba shares. First, log in as alexandreb@WINEXAMPLE.COM (a user from the Windows system), as shown below:

     

    [root@myoracle3 ~]# su - alexandreb@WINEXAMPLE.COM

    Last login: Fri Mar 25 18:36:50 BRT 2016 on pts/2

     

    -sh-4.2$ bash

     

    Obtain the user ticket by executing the following command (obviously, if we had logged in from the GUI as the user, we would have received the ticket during the login, and we wouldn't need to get the ticket by using the kinit command):

     

    [alexandreb@winexample.com@myoracle3 ~]$ kinit alexandreb@WINEXAMPLE.COM

    Password for alexandreb@WINEXAMPLE.COM:

     

    List the shares of the Samba server by executing the following command:

     

    [alexandreb@winexample.com@myoracle3 ~]$ smbclient -k -L MYORACLE2

     

    Domain=[WINEXAMPLE] OS=[Windows 6.1] Server=[Samba 4.2.3]

     

       Sharename       Type      Comment

       ---------       ----      -------

       backup          Disk     

       IPC$            IPC       IPC Service (Samba 4.2.3)

    Domain=[WINEXAMPLE] OS=[Windows 6.1] Server=[Samba 4.2.3]

     

       Server               Comment

       ---------            -------

       MYORACLE2            Samba 4.2.3

       WIN2012             

     

       Workgroup            Master

       ---------            -------

       EXAMPLE              MYORACLE1

       WINEXAMPLE           MYORACLE2

       WORKGROUP            HACKER

     

     

    Access the /backup share by running the following command:

     

    [alexandreb@winexample.com@myoracle3 ~]$ smbclient -k //MYORACLE2/backup

     

    Domain=[WINEXAMPLE] OS=[Windows 6.1] Server=[Samba 4.2.3]

     

    smb: \> ls

      .                                   D        0  Sat Mar 26 19:55:59 2016

      ..                                 DR        0  Fri Mar 25 03:38:09 2016

      smb.conf                            N    11630  Fri Mar 25 03:38:15 2016

      host.conf                           N        9  Sat Mar 26 19:04:20 2016

      hostname                            N       22  Sat Mar 26 19:04:20 2016

      hosts                               N      296  Sat Mar 26 19:04:20 2016

      hosts.allow                         N      370  Sat Mar 26 19:04:21 2016

      hosts.deny                          N      460  Sat Mar 26 19:04:21 2016

      krb5.conf                           N      469  Sat Mar 26 18:50:23 2016

      smb.conf2                           N      408  Sat Mar 26 18:51:34 2016

      smb.conf3                           N      803  Sat Mar 26 19:55:59 2016

     

          52403200 blocks of size 1024. 45740720 blocks available

    ...

     

    It is great! So far, everything has worked fine and we haven't needed to enter any password to access the shares.

     

    11. Now, it's time to try to reach shares from win2012.winexample.com. Before proceeding, create a folder named C:\Users\Shared in the win2012.winexample.com host, share it, and list the current shared folders by running the following commands:

     

    C:\> md c:\Users\Shared

     

    C:\> net share otnshare=c:\Users\Shared

    otnshare was shared successfully.

     

     

    C:\> net share

     

    Share name   Resource                        Remark

     

    --------------------------------------------------------------------------

    C$           C:\                             Default share

    IPC$                                         Remote IPC

    ADMIN$       C:\Windows                      Remote Admin

    NETLOGON     C:\Windows\SYSVOL\sysvol\winexample.com\SCRIPTS

                                                 Logon server share

    otnshare     c:\Users\Shared

    SYSVOL       C:\Windows\SYSVOL\sysvol        Logon server share

     

    From the same Samba system client (myoracle3), list the available shares by executing the following command, where -k tries to authenticate by using Kerberos and -L allows us to look at what services are available on the server.

     

    [alexandreb@winexample.com@myoracle3 ~]$ smbclient -k -L win2012.winexample.com

     

    OS=[Windows Server 2012 Datacenter Evaluation 9200] Server=[Windows Server 2012 Datacenter Evaluation 6.2]

     

       Sharename       Type      Comment

       ---------       ----      -------

       ADMIN$          Disk      Remote Admin

       C$              Disk      Default share

       IPC$            IPC       Remote IPC

       NETLOGON        Disk      Logon server share

       otnshare        Disk     

       SYSVOL          Disk      Logon server share

    Connection to win2012.winexample.com failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)

    NetBIOS over TCP disabled -- no workgroup available

     

    Finally, access the created shared folder (C:\Users\Shared), list its contents, and get a file by running the following commands:

     

    [alexandreb@winexample.com@myoracle3 ~]$ smbclient -k //win2012.WINEXAMPLE.COM/otnshare

     

    OS=[Windows Server 2012 Datacenter Evaluation 9200] Server=[Windows Server 2012 Datacenter Evaluation 6.2]

    smb: \> ls

      .                                   D        0  Sun Feb 28 00:47:30 2016

      ..                                  D        0  Sun Feb 28 00:47:30 2016

      blackhat08.pdf                      A   966202  Sat Jan 16 19:03:15 2016

      blackhat2015.pdf                    A  1570358  Tue Dec 22 01:25:50 2015

     

          26124287 blocks of size 4096. 23562329 blocks available

     

    smb: \> get blackhat2015.pdf

    getting file \blackhat2015.pdf of size 1570358 as blackhat2015.pdf (20723.7 KiloBytes/sec) (average 20723.7 KiloBytes/sec)

     

    smb: \> !ls

    blackhat2015.pdf

     

    smb: \> exit

     

    [alexandreb@winexample.com@myoracle3 ~]$

     

    12. This new test is much more interesting than the previous one. We have to prove that our Samba shares (for example, the backup share) are available and accessible for the Windows system (win2012.winexample.com). Thus, execute the following commands from win2012.winexample.com for listing the available file servers and listing the shares of our Samba server, as shown below:

     

    C:\> net view

    Server Name            Remark

     

    ----------------------------------------------------------

    \\MYORACLE2            Samba 4.2.3

    \\WIN2012

    The command completed successfully.

     

     

    C:\> net view \\MYORACLE2

    Shared resources at \\MYORACLE2

     

    Samba 4.2.3

     

    Share name  Type  Used as  Comment

     

    ---------------------------------------------------

    backup      Disk

    The command completed successfully.

     

       If you prefer seeing a graphical result, see Figure 5:

     

    f5.png

    Figure 5

     

    Create a network drive letter to make access easier, and access its respective contents by running the following command:

     

    C:\Users> net use X: \\MYORACLE2\backup

    The command completed successfully.

     

    C:\Users> X:

     

    X:\> dir

    Volume in drive X is backup

    Volume Serial Number is BCEC-4E9E

     

    Directory of X:\

     

    03/26/2016  03:42 AM    <DIR>          .

    03/24/2016  11:38 PM    <DIR>          ..

    03/26/2016  03:42 AM               408 smb.conf

    03/26/2016  04:24 AM                 9 host.conf

    03/26/2016  04:24 AM                22 hostname

    03/26/2016  04:24 AM               296 hosts

    03/26/2016  04:24 AM               370 hosts.allow

    03/26/2016  04:24 AM               460 hosts.deny

    03/26/2016  03:42 AM               469 krb5.conf

                   7 File(s)          2,034 bytes

                   2 Dir(s)  46,838,808,576 bytes free

     

    You can interact with files from the backup share using the GUI, as shown in Figure 6:

     

    f6.png

    Figure 6

     

    It's perfect because we haven't needed to enter any password to access these files! We have demonstrated the SSO operation when using the SAMBA framework and during the integration of IdM and Active Directory.

     

    As a supplement, it's possible to administer the IdM server using a browser. To do that, go to http://myoracle1.example.com and log in as admin, as shown in Figure 7:

     

    f7.png

    Figure 7

     

    After logging in, we can manage any aspect of the IdM server, as shown in Figure 8:

     

    f8.png

    Figure 8

     

    We've finished our IdM explanation, but there are many other commands and concepts that can be explored for managing and administering an IdM client/server environment.

     

    Conclusion

     

    As we learned, the IdM server helped us with the setup of the infrastructure services for a complex environment that will be used by applications such as a database or will be integrated with different systems such as Active Directory.

     

    In the past, we usually used the NIS service to concentrate system configuration into a central server, but the NIS service was unsecure. Nowadays, it is possible to automatically configure LDAP, DNS, Kerberos, and NTP services in an integrated procedure allowing everyone to log in for to use applications and network services using a secure and central service such as the IdM server.

     

    Finally, the best part of the IdM world is its capacity to provide SSO, as we saw in several sections of this article.

     

    See Also

     

    In addition to the first part of this series, here are links to some other things I've written:

     

     

    Also see:

     

     

    About the Author

     

    Alexandre Borges is a malware and security researcher. He teaches courses on malware analysis, digital forensic analysis, and reverse engineering. He is also an Oracle instructor, (ISC)2 CISSP instructor, EC-Council instructor, and he has been writing articles for the Oracle Technical Network on a regular basis since 2013. He was awarded the title of Instructor of the Year twice for his performance teaching Sun Microsystems courses.

     

    Additionally, Borges is an Oracle ACE and he has spoken at several conferences, universities, and universities about malware analysis.

     


    Note: This article represents the expertise, findings, and opinion of the author. It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.

     

     

    Revision 1.0, 09/27/2016

     

    Follow us:
    Blog | Facebook | Twitter | YouTube