This article describes an approach to integrating Centrify Server Suite for UNIX with a third-party MFA solution. We'll focus on PingID MFA from Ping Identity as our example. This approach is unique in that it does not rely on Centrify Identity Service as the third-party MFA integration point. Rather  the target UNIX operating system serves as the integration point. The integration is enabled through a combination of the Centrify Server Suite Unix agent the PingID MFA Unix PAM library. The key points this article conveys are:

  1. The recommended approach  to implement a third-party MFA with Centrify Server Suite is through Centrify Identity Service. Whenever a CSS MFA policy is triggered, CSS UNIX agent calls into CIS which in turn brokers the request to the third-party MFA;
  2. For customers that don’t want to implement CIS to enable third-party MFA for their Unix systems, it is technically possible to configure a third-party MFA PAM module with the CSS UNIX agent without relying on Centrify Identity Service. However, there are several technical dependencies need to consider. Section 4 addresses some of the risks and issues with this approach.
Read more...

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.

Read more...

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:
LDAP-Proxy-and-You-A-Definitive-Guide

 

 

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

Leveraging Centrify to provide Active Directory authentication and privelege data access roles for the IBM DB2 application, we have seen this seamless integration across the AIX landscape.  Centrify-ing your DB2 environment removes the need to provision and manage your DB2 users and their  respective DB2 groups at the OS level.  In addition, administrative efficiencies are gained by leveraging existing Active Directory user/group provisioning work flows.

 

Our Community forums are full of great articles and discussions on how to leverage Centrify Server Suite for IBM DB2 authentication and DB2 Roles for different types of entitlements to the data within.  Just in case you happen to pull this article up first, I'm going to quickly link those other DB2 forum threads for you for quick access.

 

Robertson's Discussion on Overcoming IBM DB2 Identity and Access Challenges with Centrify and AD

 

Robertson's HOWTO: Configure IBM DB2 SSO Module for Kerberos/GSSAPI SSO

 

Robertson's HOWTO: Install, configure and test the Centrify IBM DB2 SSO Module

 

Alternatively,  Felderi's Discussion on DB2 LUW Transparent LDAP; DB2AUTH=OSAUTHDB

 

Starting with DB2 v9.7FP1, IBM DB2 implemented transparent LDAP support.  In a nutshell, this allows the DB2 database manager to authenticate users defined in an LDAP directory,  removing the requirement that DB2 users and groups be defined at the operating system level. 

 

If you are a DB2 shop running DB2 on AIX, the above articles will help you integrate your AIX DB2 environment with Centrify.  If you are a Linux shop, or using a unix variant that leverages the PAM stack, you might want to bookmark this article for future use.

 

Buried in the discussions above is the key configuration parameters to leverage IBM DB2's native LDAP support.  Here is the link:

 

https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/doc/c0050519....

 

Additionally, your Unix server must have the CentrifyDC agent installed and joined to your Active Directory environment.  If you are running a unix variant that has configurable PAM stack, you will have to configure the db2 PAM stack to include the calls to Centrify PAM library.

 

For example, RedHat Linux DB2 PAM stack:

 

/etc/pam.d/db2

***************
# lines needed by Centrify Direct Control { CentrifyDC 5.3.0-213 }
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
account sufficient pam_centrifydc.so
account requisite pam_centrifydc.so deny
#session required pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny

 

# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

 

account required pam_access.so nodefgroup accessfile=/etc/security/access.conf
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

 

#password requisite pam_cracklib.so try_first_pass retry=3 type=
password requisite pam_cracklib.so try_first_pass retry=3 minlen=9 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=0 difok=3
#password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5
password required pam_deny.so

 

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
***************

 

After the DB2 PAM stack has been edited, you will need to restart the DB2 service.

 

Keep in mind, USERS that need access to the DB2 data need to be Zone Enabled.  This will also allow you to migrate your DB2 shared accounts used by multiple client connections to Active Directory.

 

Finally, the unix groups that are used to setup DB2 database entitlements can now be migrated and managed through Active Directory.

 

 

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel