Eric, My name is Mitch Rozonkiewiecz and I'm the Development Manager at CA for the eTrust PAM Client for Linux for zSeries.
There are some reasons that you might want to go with a pam_ldap implementation, but we believe there are a number of reasons why using eTrust CA-ACF2 and/or eTrust CA-Top Secret are better solutions. When you look at the issue of user authentication with a security mindset verse a common protocol mindset, we believe you will agree with the issues raised below. LDAP can be used as the authentication API, but it has limits in performance and functionality. When using LDAP as the authentication API, the clients that asked us to develop PAM required that we address four issues or areas of concern that they had: SSL connection pooling. If *ALL* applications are coded with SSL connection pooling in mind, then this is a non-issue. If even a couple of applications are not using pooling, then there are going to be performance and network issues that will have to be dealt with. And from the third party application that I have seen clients integrate with eTrust LDAP Server for z/OS, the majority of applications do not use connection pooling. When not used, the performance overhead to constantly establish SSL connection to issue the bind doubles to triples the time required to authenticate a user id. The next concern is the performance/scalability of having to make two round trip network calls to the LDAP Server for each and every authentication call. The reason that two round trips will be made is that after the ldapbind is issued, a ldapunbind is required to 'clean up' the connection structures that are allocated behind the scenes of the ldapbind. The next concern is cost. In today's cost/ROI driven environment that everyone must address is in the area of administrative costs. Unless you already have a distributed LDAP Server setup and configured, there are the costs with acquiring, installing and administering an LDAP directory. Even if you do already have an LDAP directory setup, there still is the issue of ongoing administrative costs. The last and perhaps the most import point is the functionality that is missing from LDAP Servers. While many LDAP applications try to implement an LDAP Server solution as a security product, I believe that everyone will agree that LDAP Servers are not security products. Since they are not security products, they are normally missing features that a true security product does have such as password controls, password history, calendars, etc. See the list of items below that RACROUTE VERIFY calls provide. Before we look at how these items are addressed using the eTrust PAM Client, let us start with a quick overview of the eTrust PAM Client architecture. The eTrust PAM Client is made up of three modules. The actual PAM shared library, the PAM proxy server and the PAM Server for z/OS. The PAM shared library is the module that get loaded and invoked by the PAM framework just like any other PAM module. This allow for common configuration of the eTrust PAM Client via the /etc/pam.d files. Next is the proxy server. This is used to route all authentication requests to the z/OS eTrust CA-ACF2 or eTrust CA-Top Secret security systems. Lastly is the PAM Server module that is installed on the z/OS system to actually receive the PAM request and issues the appropriate RACROUTE calls to the security product. I'll now go over each piece of the eTrust PAM solution. PAM Client - The PAM client was based on the pam_ldap LGPL code. Using the pam_ldap module, we saw the issues that I brought up above. The potential of using multiple SSL connections and the need to issue multiple ldap calls to authenticate a single user id. So we left the shell that loads and initializes into the PAM framework and removed the LDAP protocol. This was replaced with calls to the PAM proxy server, which is described next. The other issue of SSL connections was address by adding a proxy server that allows for a single SSL connection to be established to the z/OS PAM Server for all user authentication requests to flow over. PAM proxy server - The PAM proxy server is designed to support multiple PAM modules calling it at the same time allowing all PAM clients to share a single SSL connection over and over to the z/OS security server. The protocol used to communicate to the z/OS security server was designed to use an asynchronous protocol so that the proxy doesn't wait on a response for one authentication requests before sending another request or receiving an answer to a previous request. This ensures that there isn't the possibility of one authentication request to hang another. PAM Server - The PAM Server is an USS application that runs on OS/390 & z/OS and allow any eTrust PAM Client to communicate with it using the protocol designed and built into the PAM proxy server. The PAM Server communicates to eTrust CA-ACF2 and eTrust CA-Top Secret using the operating system standard calls, RACROUTE VERIFY CREATE/DELETE and EXTRACT. Now that we have laid out the three modules that make up the eTrust PAM Client, let's discuss some of the features, and benefits, that you get with it. Since all authentication is done via RACROUTE VERIFY calls, all the existing eTrust CA-ACF2 and eTrust CA-Top Secret user and password controls are in place. This includes but is not limited to: 1. Password history 2. Last used date/time 3. Calendar support - The ability to control the day of week and time that a user can logon. 4. Password controls - This includes things such as requiring alpha & numeric, restricted word list check, not allowing a new password with repeating characters, etc. 5. Passwords that expire 6. User identities that automatically expire when the temporary worker is supposed to be done 7. User identities that automatically suspend when too many logons attempts with a bad password are made 8. etc. An extension to "password checks" that is a part of all the z/OS security products is what is called source checks. A source check is the ability to control which VTAM node or TCP/IP address a user can logon from. Using the IP address and machine name of the proxy server, eTrust CA-ACF2 and eTrust CA-Top Secret can control which PAM client controlled machines a user can logon from. Password resets - Using the eTrust PAM Client to eTrust CA-ACF2 or eTrust CA-Top Secret allows you to use the existing procedures and policy that you have in place. Users don't have to learn a new or additional procedure to reset their password(s) when they are forgotten. Costs - This is addressed as there is nothing addition to buy, maintain, support or administer as it is already the corner stone of the mainframe security within your organization. This also ensures that after configuring the PAM Client there is no requirement to learn the Linux administrative commands as they are not used. Performance - Performance is always a concern when implementing solutions today. The asynchronous protocol that we have designed and implemented uses a single round trip to the PAM Server to accomplish the authentication of the user id and password as well as the traditional session management of PAM that requires an additional call using the source controls discussed above. Network performance - When LPAR's are configured with Hipersockets, all the authentication calls being made by the eTrust PAM Client never leave the host. Because all the calls are cross memory and never go 'down the line', you can run these configurations without SSL improving performance even more. This also removes all questions about network fault tolerance since there is no network involved. Network fault tolerance - For those cases where Hipersockets aren't used, you can run multiple PAM Servers so that all Linux/390 hosts aren't tied to a single z/OS system on a single subnet. We've also added the capability to manage the /etc/passwd file on the Linux/390 system. When configured to update the /etc/passwd file, the eTrust PAM Client keeps the UID, GID, home and program values in sync with the z/OS system. Pre-administration - Using the /etc/passwd update abilities means that you don't need to pre-administer a Linux/390 system before a user can log on. The dynamic, real-time updates gives you central coordination of the UID/GID values that never have to be manually updated. This can be an issue when file systems such as Samba or NFS are used. Proprietary concerns - We will release the PAM client as well as proxy server source code for porting to other PAM enabled platforms. While we don't provide out of the box support for Linux/Intel, we have built and run in this environment without issue. The fact that the source for the PAM client and proxy server is being released will allow you to see the design and implementation that was selected for the protocol to the PAM server. Unsupported concerns - While we don't provide out of the box support for platforms other than Linux/390 today, client demand for other platforms will drive this support. The clients that drove the need, design and release of eTrust PAM Client wanted Linux/390 first and foremost. Why eTrust PAM Client? - While some of the eTrust PAM Client advantages I cite can be accomplished with open source tools (for instance, new password strength checking), a big advantage of eTrust CA-ACF2 and eTrust AC-Top Secret are centralized management. Each and every system where eTrust PAM Client is installed, you are sure that they will be using the same policy. It doesn't have to be configured on each client system. eTrust PAM Client verse LDAP - Using the PAM framework, with sufficient and required configuration values, allows you to mix and match PAM implementations. In the case where only some of the users of a particular system exist in eTrust CA-ACF2 or eTrust CA-Top Secret, you can configure PAM so that when the authentication fails for users that don't exist it can invoke the next PAM module for authentication so that you aren't forced to make an either/or choice. eTrust PAM Client for z/VM - For those sites that wish to use eTrust CA-ACF2 or eTrust CA-Top Secret for z/VM as the authentication source instead of z/OS, it's coming. The eTrust PAM Server has been ported to z/VM for the next releases of eTrust CA-ACF2 and eTrust CA-Top Secret. Currently, eTrust CA-ACF2 and eTrust CA-Top Secret for z/VM are being tested by our QA departments for beta release in the near future. I hope this addresses your issues and concerns about eTrust PAM Client and why we believe it should be used instead of LDAP. Thank you, Mitchell Rozonkiewiecz Computer Associates Int'l, Inc. Development Manager
