Operating Systems

Exploiting LDAP on z/VSE

2 Pages
  • Can your z/VSE LDAP client use an anonymous bind, or do LDAP credentials need to be created for your z/VSE system to authenticate on the LDAP server?
  • What’s the name of the LDAP attribute to be searched against?
  • What’s the base distinguished name? (This is a reference into the hierarchical structure of the LDAP directory that’s considered the starting point for the search.)
  • What’s the scope of the search? For example, how many levels down the hierarchical structure is the search allowed to extend?

Some specific performance and tuning options (i.e., caching options, timeout values, etc.) can be set to further improve and enhance z/VSE LDAP client functionality. A skeleton called SKLDCFG is provided in ICCF library 59 for this configuration. How to tailor this and enable the z/VSE LDAP client support is documented in Chapter 45 of the IBM z/VSE Administration V4R2 manual (SC33-8304-02), titled “Maintaining User Profiles in an LDAP Environment.”

STRICT_MODE is an option to keep in mind. If it’s enabled, then only user profiles that are set up in the LDAP mapping are enabled to log on to the z/VSE interactive interface. It’s recommended that this option not be enabled while testing; it prevents system logon using local (non-LDAP) credentials if they’re not set up in the LDAP mapping file.

Once you’ve completed the z/VSE LDAP configuration, two additional, optional components are needed to further exploit LDAP from your z/VSE system(s): the LDAP client sample sign-on program and the LDAP query callable module. Both are available free and can be downloaded from the z/VSE homepage downloads section (www.ibm.com/vse) or these locations:

  • The LDAP client sample sign-on program at http://www-03.ibm.com/systems/z/os/zvse/downloads/samples.html#samplecode
  • The LDAP Query Callable Module at http://www-03.ibm.com/systems/z/os/zvse/downloads/tools.html#ldapquery.

The first component, the LDAP client sample sign-on program, is a sample of how to use the LDAP sign-on functions from within an application. The interface to perform this is documented in Chapter 45 of the IBM z/VSE Administration V4R2 manual (SC33-8304-02) but Figure 1, which shows a sample of this new LDAP sign-on screen, provides an example of how to use this support. In our environment, we implemented this sample code (with minor tailoring) to replace the CESN CICS sign-on transaction so users can use their LDAP credentials to sign on to our CICS regions that don’t have the z/VSE interactive interface implemented. This requires the LDAP mapping file (IESLDUM) be added to the CICS region, along with the provided program and BMS map. We decided to define a transaction ID of LDSN to invoke this LDAP-enabled CICS sign-on program. The BMS map provided mimics the CICS-supplied CESN transaction’s interface but allows entry of the 64-character userid and password.

The second component, the LDAP Query Callable Module, provides a callable interface for performing LDAP queries against the LDAP directory. A powerful C Application Programming Interface (API) is provided as part of the z/VSE client support (see member IESLDAPH.H in VSE sublibrary PRD1.BASE), but you can only use it if you have the C language available on your z/VSE system. The LDAP Query Callable Module provides the callable interfaces needed to perform an LDAP query from any LE-conforming language (i.e., COBOL for VSE).

This package also includes a CICS COMMAREA-based interface module that can be accessed using a CICS LINK command. The PASSAREA to the callable interface and the COMMAREA used on the CICS LINK operation have identical formats. Because the CICS environment handles the language environment details, the CICS COMMAREA-based interface can also be accessed by REXX for CICS and any other language CICS supports. The downloaded package also includes two COBOL-based sample programs that show how to use this callable interface. Figure 2 shows a simple example written in REXX for CICS that retrieves the mail attribute (where our LDAP directory stores the email address) for a specific user and displays it.

 

The Possibilities

In our environment, we’ve configured the z/VSE LDAP Client Support to provide sign on to the z/VSE interactive interface and our other CICS regions. This allows the sign on to our systems to be integrated with the corporate LDAP environment where password complexity policy is enforced to conform to company policy. We also have a self-service password reset function available through an intranet portal that allows an end user to reset his or her forgotten password based on security questions. With the z/VSE LDAP Client Support, the z/VSE system can now leverage this functionality, reducing and/or eliminating service desk password reset calls. There are also automated human resources processes that disable the LDAP account in the LDAP directory when an employee has left the company or when they’re out on extended leave. With the z/VSE LDAP Client Support, this is automatically applied to the z/VSE system sign-on and eliminates the audit issues we used to have surrounding deactivating accounts, etc.

Using the LDAP Query Callable Module, we’ve integrated many of our applications with the corporate LDAP directory. For example, our report distribution via email now uses an LDAP query to obtain a user’s email address from the LDAP directory to avoid the discrepancies we used to have that cause email delivery issues. We’ve also used the LDAP interfaces to automate a quarterly User Account Validation process we’re required to perform. This new, LDAP-based automated process uses the LDAP directory to obtain a user’s full first and last name, their email address, their manager’s full first and last name, their manager’s email address, etc. to build automated emails sent quarterly to confirm that a user still requires his or her account and access.

The possibilities don’t stop there. With the proper permissions in the LDAP environment, you can use this interface to query any of the available LDAP attributes stored in the LDAP directory. Since this is typically the IMS for the company, this could contain a large amount of data. For example, in our environment, this contains hierarchal links that let you extract organizational chart-related information. Our entire company’s corporate directory information is available. You could take this further and use attributes that might be available in your environment to determine base-level permissions in your applications. For example, a user’s title and department might be stored in the LDAP directory, which your application could use to grant permissions to certain functions in your applications. You could even work with your LDAP system administrators to add to the LDAP directory custom attributes specific to your application needs. These could then be used for whatever purpose you require.

Also note that the LDAP Query Callable Module can be implemented without enabling z/VSE LDAP sign-on support. You’ll still need to perform the configuration steps described previously, but there’s a flag option in the LDAP configuration member called LDAP_AUTH_ENABLED that you can set to 0 (it’s a bit setting of the FLAGS field). This will allow the LDAP Query Callable Module (and the C APIs) to perform LDAP functions even though the z/VSE interactive interface will only use local z/VSE accounts for sign-on. When the configuration is set this way, the z/VSE interactive interface sign-on screen will only display the eight-character userid and password fields and will only authenticate against local user profiles.

Conclusion

This article has provided insight into the possibilities available with the z/VSE LDAP client support. Integration into your company’s corporate IMS could allow sign on to both your z/VSE system and z/VSE-based applications to use the same credentials used by your site’s other platforms and applications. This can help z/VSE comply with company policies and other regulations that might require longer userids and more complex passwords. It can provide tighter integration with human resources and other processes that use the corporate LDAP directory to control access and permissions, etc. It lets your z/VSE system, and the applications hosted there, leverage the data attributes maintained in the LDAP directory. Depending on your LDAP environment, the possibilities could be of great value to extend the capabilities of your applications on z/VSE.

2 Pages