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.Read more...
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.Read more...