ZLDRA AD Integration

The Zero Data Loss Recovery Appliance (ZDLRA) from Oracle is a powerful and very popular backup and recovery solution for the Oracle Database that enables rapid recovery from outages and ransomware attacks.  A customer that I worked with recently, inquired about how to integrate their ZDLRA appliance with Active Directory (AD) in order to enable centralized authentication and authorization of ZDLRA administrators using their existing AD credentials.

I shared that there are a variety of approaches that you could take to enable centralizing authentication, authorization and life cycle management of ZDLRA administrators.  One of those ways is to leverage the existing System Security Services Daemon (SSSD) included with the Oracle Linux operating system of the appliance.  Authentication is enabled by outsourcing authentication via Kerberos or password based authentication over LDAPS to AD.  Authorization can also be managed via the SSSD configuration as well.

Requisites

The only requisites are access to one or more Active Directory (AD) domain controllers or preferably a load balancer or a round robin fully qualified domain name and an AD service account that can be used to lookup AD users.  One other implied requisite is that all of the installation and configuration must be applied to both ZDLRA compute hosts per ZDLRA system.  The default compute host IP addresses are outlined in the Factory IP Address Settings section of the ZDLRA Owner's Guide.

Installation

Once you login to the ZDLRA compute hosts, you will need to install the System Security Services Daemon (SSSD) and associated tools.

sudo dnf install sssd sssd-tools

Configuration

SSSD authentication is most easily enabled through the authconfig command.  In this example, we enable password based authentication to an AD domain controller (ad.example.com).

The first configuration step is to enable SSSD authentication with the authconfig command.

$ sudo authconfig --enablesssd --enablesssdauth --enableldap --enableldapauth --ldapserver=ldaps://ad.example.com:636 --ldapbasedn=dc=example,dc=com --enableldaptls --enablerfc2307 --enablemkhomedir --enablecachecreds --update

Once SSSD authentication is enabled, you will want to tailor the resulting /etc/sssd/sssd.conf configuration file according to your needs as well as to a few particular things for enabling for use with ZDLRA.  Here is a sample sssd.conf configuration file.

[domain/default]
autofs_provider = ldap
ldap_search_base = dc=example,dc=com?subtree?
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
resolver_provider = ldap
case_sensitive = False
ldap_uri = ldaps://ad.example.com:636
ldap_tls_cacertdir = /etc/pki/tls/certs
#ldap_tls_cacertdir = /etc/pki/ca-trust/extracted/pem/corpchain.pem
#ldap_tls_reqcert = never
ldap_id_use_start_tls = False
ldap_default_bind_dn = cn=zdlraadm,ou=Services,DC=example,DC=com
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = AAAgAC...
cache_credentials = True
enumerate = True
ldap_referrals = True
ldap_schema = rfc2307
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = samAccountName
ldap_user_uid_number = employeeid
ldap_user_gid_number = employeeid
override_gid = 11145
override_homedir = /rausers/%u
override_shell = /bin/bash
access_provider = permit
#access_provider = simple
#simple_allow_users = jsmith,nbrown
#simple_allow_groups = zdlradmins,itadmins,dbadmins
ldap_network_timeout = 60
ldap_opt_timeout = 60
ldap_search_timeout = 60
#debug_level = 9

[sssd]
services = nss, pam
config_file_version = 2
domains = default

[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,news,nscd,raadmin

Certificate Validation

SSSD authentication requires an encrypted connection to AD. This means that the certificate chain of trust used to verify the authenticity of the AD domain controllers certificate provided during TLS negotiation must be specified in the SSSD configuration.  For certificates signed by public certificate authorities, the default trust store located in /etc/pki/tls/certs should be specified with:

ldap_tls_cacertdir = /etc/pki/tls/certs

If instead a private certificate authority is used to sign the AD certificate, then you will want to copy the private certificate chain in PEM format to a file on the ZDLRA compute servers and specify the location in the SSSD configuration with:

ldap_tls_cacertdir = /etc/pki/ca-trust/extracted/pem/corpchain.pem

Otherwise, if you are just testing and don't want to check the authenticity of the AD server certificate, you can disable certificate verification with:

ldap_tls_reqcert = never

Service Account Password Obfuscation

When specifying the password in sssd.conf, you don't want to provide the clear text password.  The SSSD tools provides a command for obfuscating the password in the configuration file.  When running this command, it is best to specify the domain of the configuration file, which in this case is "default".  Here is a sample invocation:

sss_obfuscate -d default
Enter password: **************
Re-enter password: **************

Once the obfuscation command completes, the sssd.conf the value of ldap_default_authtok_type  will be changed to obfuscated_password and the value of ldap_default_authtok will be updated with the obfuscated value.

AD Schema

SSSD authentication will not have visibility to users in AD unless they have values for group ID number and user ID number.  Although AD schema supports these POSIX attributes, some customers do not populate them. The default attributes used for the values are uidNumber and gidNumber. If uidNumber and gidNumber are not popluated in your user's objects, the easy workaround is to use the employeeID value for the user ID and group ID numbers. 

ldap_user_uid_number = employeeid
ldap_user_gid_number = employeeid

ZDLRA Specific Overrides

There are a few specific overrides that need to be applied in order to ensure that the user has the proper group ID number, the proper home directory and shell.  These are set in the SSSD config with:

override_gid = 11145
override_homedir = /rausers/%u
override_shell = /bin/bash

Apply SSSD Configuration Changes

Once you complete all configuration changes to sssd.conf, you need to apply them by restarting the SSSD service.  Note that if you also have the name service cache daemon (nscd) running, you will need to restart it as well.  Once you are ready to test connecting remotely over secure shell (ssh), you will also need to restart ssd as well.  Here are sample restart and status commands

sudo systemctl stop sssd
sudo systemctl start sssd
sudo systemctl status sssd
sudo systemctl stop nscd
sudo systemctl start sssd
sudo systemctl status sssd
sudo systemctl stop sshd
sudo systemctl start sshd
sudo systemctl status sshd

Synchronizing ZDLRA Compute Hosts

Once the SSSD configuration is complete on the first ZDLRA host, you will need to duplicate the configuration on the second host.  Likewise, you will want to add the user with:

racli add admin_user --user_name=<samAccountName>

Troubleshooting SSSD

To confirm that the configuration is working properly, test looking up a user with id and getent:

id user10000
uid=10000(user10000) gid=10000 groups=10000

getent passwd user10000
user10000:*:10000:10000:Aaren Atp:/rausers/user10000:/bin/bash

If these are working as expected, then you should be able to ssh into the ZDLRA and run the ZDLRA command line tools for configuring and managing the ZDLRA appliance.  When you login to the ZDLRA for the first time with ssh, the user's home directory is created in /rausers/<samAccountName>.  In some circumstances, the user's home directory may get created with permissions drwxr-xr-x (0700).  Check with "ls -d /rausers/<samAccountName>".  If the permissions are drwxr-xr-x, change the permissions with the following where <samAccountName> is the user name of your user:

chmod 0700 /rausers/<samAccountName>

If id and getent are not returning values for known users, then you will want to enable debug_mode to level 9 in sssd.confg, restart sssd (and if applicable nscsd), run the id or "gentent passwd <samAccountName>" and review the domain log files in /var/log/sssd. 

debug_level = 9

The most common reasons that I've observed thus far from the /var/log/sssd domain logs are the following:

1. SSSD cannot connect securely to the AD domain controller because the AD domain controller's certifice is self signed or signed by a private certificate authority for which the ZDLRA compute host does not have a copy of the certificate chain necessary to verify the authenticity of the certificate.

2. The AD service account that SSSD is attempting to login with doesn't exist

3. The password of the AD service account is incorrect

4. The AD service account is locked because of too many failed login attempts

Authorization

Once the basic plumbing of AD integration is complete and users can ssh into the ZDLRA compute host, the next and final step is to determine who should have access to the ZDLRA compute hosts.  This is accomplished through SSSD authorization configuration using the access_provider SSSD configuration parameter.  The default value of the access_provider is "permit", which means anyone can ssh into that host.  Other options include simple, ad, and ldap.  The easiest and most straight forward for this use case is the "simple" option.  The "simple" option enables you to specify lists of specific users (by <samAccountName>) and groups to determine who is allowed to login over ssh to the ZDLRA compute hosts. For example, after SSSD integration is complete, you could apply the following configuration change to sssd.conf to limit who can login to the ZDLRA compute to the specified users and members of the specified groups:

#access_provider = permit
access_provider = simple
simple_allow_users = jsmith,nbrown
simple_allow_groups = zdlradmins,itadmins,dbadmins

Once theses authorization settings have been updated, restart sssd, sshd and if applicable nscd.

That concludes one example of how to integrate the ZDLRA with AD.

I hope you found this information useful and informative.

Blessings!