z/VM V7.4 was recently announced, and with it came a Statement of Direction from IBM. You may not have seen it; it was buried in the Announcement Letter, and I know how much everyone loves to read those! But this one is worth understanding, as it may have serious implications for your environment.

To wit(1):

Removal of support for the LDAP Server

z/VM V7.4 is planned to be the last z/VM release to support the z/VM LDAP server. This server, a re-host of the z/OS Directory Server, will be removed from z/VM TCP/IP in a future release. This includes the LDAPSRV virtual machine and associated components. All future releases will continue to support ldap-bind as an authentication factor through the IBM Z Multi-Factor Authentication program (5655-MA1). CMS-based LDAP client utilities, and the RACF r_admin interface, are not affected by this statement.

Let’s take a moment to unpack this. Why would you be using the LDAP server, anyway?

LDAP/VM was good at centralized identity management. Sort of.

The LDAP protocol is designed for fast identity management and group controls. The whole point is to take away the 1980’s monolith style of identity control, where a given system has a human user, password, and controls for their system and their system only, right? IBM Z did away with that ages ago with the sharing of RACF databases… but as Linux guests proliferated, it became more difficult to prevent identity sprawl.

Fortunately for everyone, LDAP came about because smaller, distributed systems had already hit this problem. And there was an easy fix: teach LDAP how to talk to RACF! The SDBM schema was not as flexible as the LDBM everyone knew and loved… but if you wanted to lean on RACF user or group definitions, or query user attributes, as part of Linux PAM logon flow, you now had a method to do this. And because LDAP is a protocol – system agnostic – you could point your Linux guests to openLDAP, or to ActiveDirectory, or to z/VM RACF (via LDAP/VM), or z/OS RACF (via z/OS ITDS)… all to achieve the same result.

Of course, if it sounds too good to be true, it probably is.

What happened?

Part of the problem is the inflexibility of the SDBM schema. While “native authentication” works fine for what it is, clients often had to build a combination of SDBM and LDBM to manage complex z/VM or Linux on IBM Z environments. So they ended up doing twice the work…

Further compounding the issue, synchronization over a larger enterprise left something to be desired. The IBM Tivoli Directory Integrator (ITDI) solution did operate (and a Redpaper(2) was produced to that effect) in such a way that changes could be propagated (because a person is that person all over the world, not just near the nearest RACF database). It never worked as well as one hoped, though, and backup/recovery solutions outgrew it.

To complicate matters, passwords ceased to be the preferred means of authentication. 2FA and MFA arrived on the scene and a lot of what z/VM ITDS became somewhat superfluous.

What happens now?

One of few cases could be true, so let’s sum up.

  • If you’re not using z/VM LDAP today, there’s no impact to you.
  • If you’re using z/VM LDAP for SDBM with RACF/VM as a back-end, and this is for native authentication with no attribute checking, then the fastest path to safety is migration. IBM Z MFA is the preferred solution in this case because it can handle simple ldap-bind as an authentication factor – so if you migrate your existing SDBM to z/OS, or rebuild under Linux (either in OpenLDAP or the Linux-hosted version of ITDS), then you’re in the clear. (You also can start to add other factors.)

  • If you’re pulling attributes from RACF/VM via LDAP/VM to make logon decisions, then you’re not forgotten. But migration is more complex, and the SOD doesn’t cover what happens to these environments.

I’ll be using the coming weeks and months to explore these use-cases in more detail here, with configuration notes and pictures as appropriate.

What you can do in the meantime is investigate joining the z/VM Council in order to get involved in early beta projects, to voice usability concerns and pain points, and to influence design decisions.

Summary

The Statement of Direction accompanying the announce of z/VM V7.4 indicates that LDAP/VM is going away in a future release. While this can potentially change, IBM felt strongly enough about this to put the word out now. And while r_admin, and the ldap client utilities under CMS, will continue to exist, existing deployments using the LDAP/VM port of z/OS ITDS need to look to the future. There are cases where IBM Z Multi-factor Authentication can help… but it’s not the only solution, and it won’t solve every problem.

I’ll continue to write up more scenarios and thoughts about each of the impact cases as the space develops, but: this won’t be the final word on the topic.

Footnotes

  1. https://www.ibm.com/docs/en/announcements/zvm-74-delivers-capabilities-help-improve-service-experience?region=US_
  2. https://www.redbooks.ibm.com/redpapers/pdfs/redp4460.pdf