I read about CA PAM Client for Linux for zSeries and CA ACF2. Linux Security already has all of the functionality, why would a site want to layer more products on top?

book

Article ID: 53053

calendar_today

Updated On:

Products

CA ACF2 CA ACF2 - DB2 Option CA ACF2 for zVM CA ACF2 - z/OS CA ACF2 - MISC CA PanApt CA PanAudit CA Panvalet

Issue/Introduction

Description:

Linux/390 has security functionality; however there are a number of reasons to integrate this into CA ACF2 with the CA PAM Client for Linux for zSeries product.

Solution:

Reasons to integrate Linux Security with CA ACF2 using the CA PAM Client for Linux for zSeries product.

  • If you use the Linux security, you have to 'pre' create the id/pswd and home directory before a user can logon. With the PAM Server and client from CA, this is not a requirement. As part of the logon, when the id/pswd is authenticated to CA ACF2, the users home dir, UID and GID is extracted and returned to the PAM client code running on Linux/390. This code dynamically adds the user to the /etc/password file (if so configured) and then creates the home dir if needed. The user is then allowed on to the Linux node with zero Linux administrative effort.

  • Standardization - Since CA ACF2 is controlling the home, program, UID and GID, you will have consistent values across all nodes.

  • Source controls - Using CA ACF2's built in source controls, not only can you control which Linux nodes a user can logon to, but the days and time of day.

  • Passwords - Using CA ACF2 as a central enterprise security repository, you also get standardized password controls. Min/max length, min # of days before a change, pswd history, etc.

  • Passwords - Using CA ACF2 as a central enterprise security repository, the user has a single password value to remember. The user is not required to 'sync' their passwords.

  • Security policy - When trying to create a security policy for an enterprise, there are always the differences in the security of each platform that makes it difficult to have a standard policy. Exceptions are always found. Using CA ACF2 as a central enterprise security repository this is no longer an issue.

  • The PAM client will be released as open source from CA. This will allow any client of CA to 'port' the PAM client to any platform that has a PAM framework as part of the operating system. This includes Linux on other platforms such as Intel, Sun Solaris, HP-UX and IBM's AIX. Citing all the reasons above, you can truly start to use CA ACF2 as a central enterprise security repository.

  • Employee's leave the company - When employees leave the company, you don't have to run around trying to delete the user account from every node they every logged on to. Suspending/deleting that account from CA ACF2 makes sure that every Linux system using our PAM client is secure and that ID can't be (mis)used.

  • Scalable - CA ACF2 is very scalable. Using it to control the Linux nodes just adds to it's value.

Just to reiterate reason 1, we worked with a client who was in the process of setting up approximately 1000 Linux/390 LPARs. The administrative effort to maintain user id/pswds in the nodes would require a number of administrators. While a site's organization might not be looking at this many, We will venture a guess and say that we doubt the administrative staff is growing to service security requirements. This alone should be reason enough to add a very thin layer to enhance and centralize the security in a site's environment.

Details on the CA PAM Client for Linux for zSeries can be found at the Support Online web site at: https://support.ca.com select the "Support by Product" from the Support column to the left, then select "CA PAM Client for Linux for zSeries" from the "Select a Product page" drop down box.

Environment

Release:
Component: ACF2MS