Introduction

As mentioned in the introduction, this guide contains a walk-through on configuring and debugging the Centrify LDAP proxy for use with NSS and PAM integration with LDAP on agentless systems (systems that will be integrated with identities kept inCentrify zones in Active Directory, without installing the Centrify DirectControl agent).

Due to specific limitations in the Centrify LDAP proxy, in practice, it often is required to troubleshoot/debug the Centrify LDAP proxy configuration, and investigate which return attributes have been requested, in case queries fail silently. Once they have been identified, mappings can be updated in the Centrify LDAP proxy server configuration files, in order to let LDAP queries for these attribute succeed.

This guide will follow a procedure that explains how to set up and debug integration of legacy systems using PAM and NSS integration with the Centrify LDAP proxy, and will go through some rounds of identifying return attributes that are requested by the pam_ldap module that is present in the RHEL/CentOS 6.8 repository.

The same procedure can then be applied to other UNIX platforms that will be integrated with a pam_ldap (or equivalent) module, that support RFC2307 LDAP queries.

In this guide we will use the following hostnames to designate machines representing various roles:

• The server hosting the Centrify ldap proxy role: ldapproxy.centrify.vms
• The legacy system target for LDAP integration in NSS and PAM: legacyos.centrify.vms

Step 1 - Setting up UNIX access controls in the Centrify Zone for legacy systems
Prerequisites

• Access to a Windows Server that has the Centrify DirectManage Access Manager console installed

• Account credentials that can manage authorizations in the Centrify Zone (e.g. a Centrify zone admin)

Steps

• Open Access Manager
• Create a new Computer Role in the zone for Centrify LDAP Proxy servers. Provide a name, e.g. 'Centrify LDAP Proxy Servers'. Select from the dropdown menu when selecting the group, to create a new security group with domain local scope, and provide it with a name that follows the naming conventions of your Active Directory domain. In this example, the name 'CfyC-Global-Centrify LDAP Proxy Servers' is used, to designate a Centrify computer role group ('CfyC') for systems in the 'Global' zone, in computer role with name 'Centrify LDAP Proxy Servers').
• Add the computer objects of the *NIX systems, that will be hosting the Centrify LDAP proxy service, as member to the previously created security group ('CfyC-Global-Centrify LDAP Proxy Servers').
• Create a new Role Definition in the Centrify Zone, called 'Legacy UNIX Login', set the description to 'Full profile visibility to allow login to legacy systems', and assign the following access rights from the System Rights tab:
  
  • Account disabled in AD can be used by sudo, cron etc.
  • Login with non-Restricted Shell
  • User is visible
• Note that no PAM access rights need to be assigned, as we won't actually allow login access to the LDAP proxy itself with this role; the only goal, is to make the profiles of the users that will be allowed to log into legacy systems, visible in their entirety (i.e. shown in output of 'adquery user', including their shell).
• Using the Microsoft Active Directory Users and Computers management console ('dsa.msc'), create a new security group with domain local scope, that will be used for the Role Assignment to the Role Definition created above, inside the previously created Computer Role. In this example, we will use a group named 'CfyR-Global-Centrify LDAP Proxy Servers-Legacy UNIX login'
• Add the user objects, for users that have a valid UNIX profile in the Centrify zone, and that need to be able to log into legacy UNIX systems, to this security group ('CfyR-Global-Centrify LDAP Proxy Servers-Legacy UNIX login').
• Make a role assignment inside the previously created Computer Role (Centrify LDAP Proxy Servers), and link the 'Legacy UNIX Login' Role Definition to the user role group created in the previous step ('CfyR-Global-Centrify LDAP Proxy Servers-Legacy UNIX login').

Step 2 - Setting up the Centrify LDAP proxy
Prerequisites for this step

• Privileged access (root) to a *NIX system joined to Active Directory using the Centrify Agent from the 2016.1 release or later (CentrifyDC package 5.3.1 and up). In this example we will use a CentOS 6.8 system with a user account that has access rights to all privileged commands through dzdo (dzdo *).
• The corresponding LDAP proxy package for the agent version (centrifydc-ldapproxy package) present on the server that will function as Centrify LDAP proxy
• Access to the Centrify console to configure a computer role, that defines who can log in to the legacy systems

Note that this guide will not work with agent & ldap proxy packages from Centrify Server Suite 2016 and older; 2016.1 is the minimum supported version, as it will refuse an LDAP simple bind with incorrect user password. The ldap proxy in the Server Suite 2016 release and earlier, would accept an LDAP simple bind for a valid user regardless of the password, and subsequently would refuse to return results for the LDAP query if the bind information is incorrect. This order of events would translate into any valid username getting access to a legacy system that is using pam_ldap, as the pam_ldap module determines whether a user credentials are valid, based on whether the simple bind gets accepted by the LDAP server.

Steps

Install the LDAP proxy by installing its software package
# dzdo rpm -Uvh centrifydc-ldapproxy-5.3.1-rhel4-x86_64.rpm

Configure rsyslog (the standard syslog daemon on RHEL/CentOS 6) to redirect message for local4.debug to the log file /var/log/ldapproxy.log
# dzdo echo -e "local4.debug\t\t/var/log/ldapproxy.log" > /etc/rsyslog.d/centrifyldapproxy.conf

Restart the rsyslog daemon for the configuration to be read
# dzdo service rsyslog restart
Configure the LDAP proxy to listen on all interfaces, on the default port for connections for ldap and ldaps protocols (port 389 and 636 respectively), and enable debugging of all connection/authentication and ldap queries (loglevel 256) to the local4.debug SYSLOG facility
# dzdo echo "STARTUP_OPTS=\"-d 256 -h 'ldap:/// ldaps:///' 2>&1 | logger -p local4.debug -t slapd &\"" > /etc/sysconfig/centrify-ldapproxy
For more information on log levels for OpenLDAP (on which the Centrify LDAP proxy is based), please consult the OpenLDAP documentation.

Open firewall ports for the Centrify LDAP proxy port 389 and 636, by inserting the following lines in the /etc/sysconfig/iptables file, directly underneath the entry "-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT":
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT

Reload the iptables running configuration:
# dzdo service iptables restart

The Centrify LDAP proxy is now ready for an initial round of debugging, in order to identify all the requested return attributes, and update the mappings if needed.
Restart the Centrify ldap proxy to apply the updated configuration specified in /etc/sysconfig/centrify-ldapproxy
# dzdo service centrify-ldapproxy restart

Validate that the adquery us er output shows the profiles of all users that should have login access to the legacy ldap servers.
# adquery user
Note that anyone with login access to the LDAP proxy server itself, will automatically also be included in the output of adquery user, and as a consequence, also be able to log into legacy UNIX systems. Plan access rights to the LDAP proxy servers with this fact in mind.

Write down a name in the output of this command that shows a valid shell, as this will be used in step 3. In this example we will use 'dwirth' as example user.

In the follow-up article, integration of a 'legacy' system with the Centrify LDAP proxy for agentless authentication is detailed.