This is a continuation of part 1 and part 2 of this series, which detail configuration of the Centrify LDAP Proxy and agentless integration of a system into a Centrified environment, respectively.

Step 5 - Securing the environment
The connection to the ldap proxy should now be secured, as the credentials for the LDAP simple bind are transmitted in plain text over the wire.
Either use LDAPS / LDAP w/START TLS, IPsec or a dedicated VLAN to shield the sensitive network communications.

When securing the LDAP proxy with SSL/TLS, generate an RSA private key, a certificate signing request with as subject, the name in DNS that you will use for accessing the ldap proxy, and as subject alternative name the hostnames of the physical machines that run the ldap proxy; this allows placing the ldap proxy behind a load balancer, that can also be configured for providing automatic failover functionality.

Configuring SSL/TLS on the Centrify LDAP proxy

Let's suppose we've created a certificate with Microsoft Active Directory Certificate Services, and enrolled the ldap proxy server with this certificate.
In our environment, the following public key infrastructure files are used for this connection on the ldap proxy server:

• /var/centrify/net/certs/trust_root_CA.cert - Root CA distributed by Active Directory
• /var/centrify/net/certs/trust_DAFE2765460EE35075C3BE166AAE3875CBFBBB63.cert - Intermediary signing CA distributed by Active Directory
• /var/centrify/net/certs/auto_Centrify-Autoenrollment.cert - LDAP proxy certificate provided through auto-enrollment
• /var/centrify/net/certs/auto_Centrify-Autoenrollment.key - LDAP proxy private key matching certificate in previous line

Configure the Centrify LDAP proxy for TLS in /etc/centrifydc/openldap/slapd.conf

# TLS configuration

TLSCACertificateFile  /var/centrify/net/certs/trust_DAFE2765460EE35075C3BE166AAE3875CBFBBB63.cert

TLSCertificateFile  /var/centrify/net/certs/auto_Centrify-Autoenrollment.cert

TLSCertificateKeyFile /var/centrify/net/certs/auto_Centrify-Autoenrollment.key

# Require START TLS on port 389

security tls=1

# Require TLS v1.0 or better

TLSProtocolMin 3.1

# Require TLS v1.1 or better

#TLSProtocolMin 3.2

# Require TLS v1.2 or better

#TLSProtocolMin 3.3
NOTE if you need to use SSLv3, comment out the line with 'TLSProtocolMin 3.1'. However, note that SSLv3 is considered to be outdated and insecure. Preferably, use as high TLS protocol number supported by the openldap client. Unfortunately, unless manually (re)compiling the ldap client against the latest cryptographic framework/libraries (OpenSSL, GnuTLS, etc.), the relevant ldap client packages on legacy systems are unlikely to support any semi-recent SSL/TLS protocols.

Restart the ldap proxy to pick up the updated configuration
# dzdo service centrify-ldapproxy restart

Validate you can perform a TLSv1.0 handshake on port 636 (ldaps)
# openssl s_client -verify 2 -connect ldapproxy.centrify.vms:636 -CAfile /var/centrify/net/certs/trust_root_CA.cert -tls1

Make sure SSLv3 is not accepted
# openssl s_client -verify 2 -connect ldapproxy.centrify.vms:636 -CAfile /var/centrify/net/certs/trust_root_CA.cert -ssl3
this should show a result similar to the following:

verify depth is 2
CONNECTED(00000003)
140389969225384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
140389969225384:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1475284289
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

Configuring SSL/TLS on the LDAP client
Distribute the Root CA certificate to the systems configured as ldap client ( /var/centrify/net/certs/trust_root_CA.cert in the above example). In our example, the certificate will be located in the following location on systems functioning as ldap client:
/etc/pki/tls/certs/trust_root_CA.cert

Configure the openldap client that is part of the openldap-clients package on RHEL/CentOS to use this certificate for certificate validation when connecting to an ldap server
# sudo certutil -A -d /etc/openldap/certs -i /etc/pki/tls/certs/trust_root_CA.cert -n "Corporate Root CA" -t "CT,c,c"
NOTE that older RHEL/CentOS 6 releases (6.6 and lower), point the ldap binaries to an incorrect NSSDB location. You will need to configure /etc/openldap/ldap.conf to point to the correct NSSDB directory, or make sure both the NSSDB and the configuration point to the right location when using a different location in the ldap.conf file (e.g. /etc/openldap/cacerts):
TLS_CACERTDIR /etc/openldap/certs

Validate that the ldap proxy returns results when performing an ldap search with LDAPS
# /usr/bin/ldapsearch -H ldaps://ldapproxy.centrify.vms -b cn=zones,ou=centrify,dc=centrify,dc=vms -D dwirth@centrify.vms -W '(&(objectClass=posixAccount)(uid=dwirth))' uid

Validate that the ldap proxy returns results when performing an ldap search with LDAP and START TLS
# /usr/bin/ldapsearch -H ldap://ldapproxy.centrify.vms -ZZ -b cn=zones,ou=centrify,dc=centrify,dc=vms -D dwirth@centrify.vms -W '(&(objectClass=posixAccount)(uid=dwirth))' uid

Validate that the ldap proxy returns _no_ results when performing an ldap search with LDAP and no TLS
# /usr/bin/ldapsearch -H ldap://ldapproxy.centrify.vms -b cn=zones,ou=centrify,dc=centrify,dc=vms -D dwirth@centrify.vms -W '(&(objectClass=posixAccount)(uid=dwirth))' uid

Configure the NSS ldap module (nslcd) to use TLSv1 and require certificate validation, by setting the following lines in /etc/nslcd.conf
ssl start_tls
tls_reqcert hard
tls_ciphers TLSv1
tls_cacertfile /etc/pki/tls/certs/trust_root_CA.cert

Restart the nslcd daemon to apply the configuration changes
# sudo service nslcd restart

Configure pam_ldap to use START TLS with TLSv1 and certificate validation by adding the following lines to /etc/pam_ldap.conf
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/pki/tls/certs/trust_root_CA.cert
tls_ciphers TLSv1

Validate that you can log on to a legacy system that has been configured to use TLSv1 for LDAP searches.
# ssh dwirth@legacyos.centrify.vms
dwirth@legacy's password:
Your LDAP password will expire in 4294967257 days.
Creating home directory for dwirth.

After validating the legacy platform's integration is working properly, specify the narrower base DN for the configuration of the pam ldap module in /etc/pam_ldap.conf ; e.g.

base cn=zones,ou=centrify,dc=centrify,dc=vms

Disable the Centrify LDAP Proxy debug mode, in order to reduce the rate at which the ldap proxy log grows
# dzdo echo "STARTUP_OPTS=\"-h 'ldap:/// ldaps:///' 2>&1 | logger -p local4.debug -t slapd &\"" > /etc/sysconfig/centrify-ldapproxy
# dzdo service centrify-ldapproxy restart

Advice for production usage

• Implement high-availability by pointing the DNS record for the Centrify LDAP proxy servers to a load balancer, that tracks the availability of the individual hosts that provide the LDAP proxy service
• Run the ldap proxy proces (slapd) as an unprivileged user, when password hashes need not be served (i.e. modify the centrify-ldapproxy init.d script, look at the vanilla openldap server in RHEL/CentOS for pointers), to improve security

Recap of this guide (TLDR;)
This guide explains how to integrate legacy systems to be integrated with Centrify Zones, without requiring a Centrify agent (e.g. because there is no Centrify agent available for the target platform, or the available Centrify agent does not support hierarchical zones (DirectControl

Leveraging Centrify LDAP Proxy, as described in this guide, provides the following advantages over alternatives

• Legacy systems can receive the UNIX identities that the Centrify LDAP Proxy machine sees (i.e. from a Centrify hierarchical zone deployment), and are automatically kept up to date (the LDAP proxy refreshes its cache once per hour by default)
  ... as a result of the above, UNIX identities are provisioned to all systems (both Centrify agent and agentless legacy systems)
• 'UNIX Login' access rights on legacy systems are leveraging RBAC in Active Directory (membership of a role group, in this example the group 'CfyR-Global-Centrify LDAP Proxy Servers-Legacy UNIX login', defines whether a user will be able to log in or not to all systems )
• Authentication leverages Active Directory Domain Controllers, disabling a user account will deny access to login attempts in real time.
• No password hashes need to be stored in Active Directory, which reduces the attack surface and avoids dependency on solutions that synchronize passwords between each KDC and the user object attribute on password change events (good for security)
• This implementation depends on simple LDAP binds, that send user credentials in clear text over the wire; protection of LDAP binds communiction is required, by adding TLS, IPsec or VLAN isolation between ldap client and Centrify LDAP proxy server. This guide shows how to implement TLSv1.
• When implementing pure NSS LDAP integration, the majority of this guide can be followed, with the change that pam_ldap configuration can be skipped, and a password synchronisation service needs to be configured to populate password hashes in user objects in Active Directory, and the Centrify Zone needs to be configured to allow the LDAP proxy server to read these attributes. These steps are explained in the Centrify Network Information Service Administrator’s Guide (centrify-nis-guide.pdf) that is supplied with Centrify Server Suite. Note that this requires the ldap proxy process to run as user root, and in general provides weaker security in scenarios where PAM LDAP integration is also available, and where LDAP simple binds can be sufficiently protected using one of the available mechanisms.