In the course of helping customers migrate to Centrify Adbindproxy, Support has identified some instances where the scale of Samba environments impact the effectiveness of the new adbindproxy component.  This blog will summarize a recent issue and workaround which may help other customers facing a similar situation.


Centrify supports another way of implementing stock Samba4 with Centrify that does not use adbindd, but uses NSS instead.  Access control is then based on NSS users and groups with winbind instead of using adbindd (Active Directory).


In one customer's environment, they were using Samba to share directories to a large number of end users whom were moving and accessing lots of large media files to and from those shares.


In part 1 and part 2 of this series, configuration of the Centrify LDAP Proxy and agentless integration of a system into a Centrified environment has been detailed, respectively.


In this final part of the series, securing the environment is detailed, as well as a write-up on what the advantages are of integrating legacy systems using the agentless approach using LDAP.


In the previous article, configuration of the Centirfy LDAP proxy was detailed, for use with legacy systems that will be integrated using an agentless approach, by retrieving identities from the Centrify LDAP proxy and proxying authentication requests to this same LDAP proxy server.


In this article, the configuration for the agentless part is detailed, as well as the steps to troubleshoot/debug this configuration.


As discussed in part 1 of this series, there are multiple ways of integrating legacy UNIX/Linux systems into Active Directory.


One of those methods, entails using the Centrify LDAP proxy as a source of identities (i.e. source of passwd, shadow and group maps in Name Server Switch), and to proxy all authentication requests for these users by PAM to the Centrify LDAP proxy.


This means, that rather than using password hashes stored as user attribute values in Active Directory, which is very bad from a security perspective, user authentication attempts are proxied by the pam ldap module on the legacy system, to the LDAP proxy server in the form of a a simple bind using the user's credentials.


As an LDAP simple bind is performed in plain text, the connection needs to be secured using either TLS, IPsec, VLAN isolation or through other means.  In this guide, TLS is used purely for demonstration purposes, as in practice, legacy systems are unlikely to support anything better than SSL 3.0 (which is insecure).


Note that some reading material will benefit for the understanding of how the LDAP proxy works, including some configuration advice:



This article will provide a walk-through on how to install and configure a system to use agent-less authentication against the Centrify LDAP proxy, without relying on password hashes stored in Active Directory. It uses a mock-legacy system in the form of a CentOS 6.8 client for this purpose; however the same troubleshooting steps apply when configuring 'real' legacy platforms, such as HPUX 11.00 for authentication against the Centrify LDAP Proxy.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel