With the introduction of z/VSE Version 4.2, IBM provided a new feature called LDAP Sign-on Support. Lightweight Directory Access Protocol (LDAP) is an accepted standard that’s commonly used in Identity Management Systems (IMSs) to centralize storage of identity-related information. As part of the LDAP Sign-on Support, IBM has provided a full-function LDAP client that enables the z/VSE system to communicate using the LDAP protocol. This lets users sign on to the z/VSE interactive interface using “companywide” credentials that are stored on an LDAP server in an LDAP directory.
The userids and passwords used can be up to 64 characters each, and the LDAP server can enforce the requirement for complex passwords and other policies. IBM Tivoli Directory Server, z/VM LDAP Server, Novell eDirectory, Microsoft Active Directory, and OpenLDAP (an open source implementation of LDAP) are examples of some available IMSs. This article examines how you can exploit the LDAP client provided with the z/VSE operating system. For more information on LDAP Sign-on Support, view the z/Journal article by Ingo Franzki published in the April/May 2009 issue. This article, titled “Integrating z/VSE Into an Identity Management System Using LDAP,” is available at www.mainframezone.com/it-management/integrating-z-vse-into-an-identity-management-system-using-ldap/P2. There are many other sources of information on this topic, including IBM Redbooks.
z/VSE Before LDAP Support
Before the z/VSE operating system supported LDAP, z/VSE was limited to using local credentials stored in the z/VSE Basic Security Manager (BSM) (for access to the interactive interface) or in-house-developed methods for storing user’s credentials and controlling logon access to applications.
When using the z/VSE BSM, the system is limited to eight-character userids (or four characters when configured to access Interactive Computing and Control Facility [ICCF]), eight-character passwords, and can only enforce basic policies for the length or complexity of the passwords involved. Complexity is enforced by implementing a customized exit. The passwords are also limited to only uppercase, numbers, and a handful of special characters. Additionally, z/VSE security only provides a 20-character field for adding a description to the z/VSE BSM user profiles and doesn’t provide any place to keep other identity-related information.
These limitations may not be an issue for everyone, but in our environment, they prevented our z/VSE system from meeting company policies; this required us to file several exceptions with our corporate auditors. We had to put several compensating controls in place. For example, we had to maintain a cross-reference between z/VSE user profiles and our corporate employee ID numbers.
From an application perspective, we faced several security compliance issues that required us to modify our applications to store password hashes (instead of storing the actual password) and we had to maintain a local copy of much of the identity-related data associated with our users in our application. This included the user’s full name, email address, and other contact information. This data wasn’t actively synchronized with the data maintained in the corporate IMS, which was a constant source of discrepancies. For example, our z/VSE-based reports are distributed using email. If an employee’s name changed, their email address also changed and this could lead to failures in report delivery. If an employee left the company, we relied on reports from the Human Resources Department and human intervention to remove their access to the z/VSE system. These items didn’t please our corporate auditors and caused service delivery and support issues.
The LDAP Solution
The z/VSE LDAP client support is implemented primarily as part of the z/VSE interactive interface. The z/VSE interactive interface sign-on programs now support optional invocation of LDAP authentication of user-entered credentials against an LDAP server. Tools to define LDAP users to the z/VSE system were also provided. There’s a configuration member that must be tailored to define how the z/VSE system will communicate with the external LDAP server and several other options. Getting through this configuration requires knowing how your LDAP server was implemented, what methods are supported for authentication, what hierarchical directory structure your LDAP system administrators implemented, and more. You should be able to answer these questions:
- What’s the IP address or the fully qualified DNS hostname of the LDAP server in your environment?
- Does the LDAP server require Secure Sockets Layer (SSL) or non-SSL communications? (Securing this using SSL is the preferred method since user credentials are transferred.)
- Does your LDAP server support direct binds with the userid entered or does the z/VSE LDAP client need to perform an LDAP “search” with the userid as the search attribute?
If the search method is required, you should know answers to these questions: