LDAP on z/VM as an Open Authentication Source

I have been using LDAP as a central data store for a very long time. Back when I had a home Asterisk PBX, I had an LDAP directory that functioned as a household phone book and source of caller-ID data for the IP phones installed through the home. This LDAP directory was also the authentication source for the home Linux servers.

In 2012, when I was part of the team that wrote the first edition of Security for Linux on z/VM, I offered to write about RACF and the z/VM LDAP server. I had read about Native Authentication in z/VM LDAP, and wanted to experiment with how RACF information exported using LDAP could help with authentication in Linux. I was delighted with how the text turned out: I demonstrated that it was not only possible to use the RACF password natively — in other words, without replication or synchronisation — to authenticate to Linux, but that the LDAP data source could still be used to support traditional LDAP uses (like ID mapping, phone directories, etc).

LDAP backends

To understand why I was so pleased, it is important to reflect for a moment on how LDAP implementations operate and where they get their data from. The data sources used by LDAP servers are referred to as backends, and different servers implement different backends. The OpenLDAP server, for example, implements backends including local database files and can even use another LDAP server as a backend (we will come back to this later).

The LDAP server on z/VM is provided as part of the TCP/IP product but is actually the same LDAP server that ships with RACF on z/OS. It too has a number of different backends. The usual backend used on z/OS is called SDBM, and it exports the content of the actual RACF database using a very unique schema that cannot be modified or extended. Since RACF data is available directly through the SDBM backend, there is no copying of data from RACF to LDAP. However, the fixed and non-extensible schema limits the usability of SDBM to only applications that know how to work with the RACF schema.

Another backend supported on both z/OS and z/VM is LDBM. This backend uses a database file format which is separate from the RACF database, and also uses a schema which is extensible. In Security, I wrote about how a standard RFC2307-style schema can be installed into z/VM LDAP, and extended even further to support more applications and uses.

SDBM or LDBM, then?

So in the z/VM LDAP we can use the RACF database directly, as long as we can cope with a non-standard schema, or we can use a rich database that supports an open and extensible schema but has no data populated. Since the point is to use the RACF password for logging on, it would seem that the best approach would be to use SDBM and spend the considerable effort to engineer our application to support the non-standard schema.

One further issue with this approach, however, is that RACF was never intended to support the types of information stored in directories today. User resources in RACF are not even assured to have ‘UID’ and ‘GID’ fields, let alone fields like phone number, email address, and the rest of the rich data expected in an enterprise directory today. So it is entirely possible that, after spending time and effort to make an application support the SDBM schema, that RACF simply can’t support the needs of the application.

Native Authentication

LDBM provides the solution to this issue, through Native Authentication. This is a feature of the z/VM and z/OS LDAP Server LDBM backend which allows password validation to be performed by RACF instead of through a comparison using a password stored in LDAP. With planning, LDBM can automatically locate the right RACF user ID to check — and even if the automatic method can’t be used, it takes only a single attribute to be added to the object in LDBM to ‘glue’ the ID in LDBM to the correct RACF ID.

Native Authentication provides the way to combine a flexible and extensible LDAP schema with the security of RACF password management. With Native Authentication, any attempt to access a userPassword attribute will fail. Instead, authentication is performed by using RACF to validate the password provided in an LDAP bind() call. The password is not stored in the LDAP LDBM backend at all.

Administrators Only

It’s fair to say that not many organisations use RACF as their central user database — particularly RACF on z/VM. Back when I first wrote about this, the RACF database on z/VM (if RACF was even used) contained only very few IDs. It would have contained the IDs for the z/VM system itself, such as IDs for service virtual machines (SVMs) and z/VM-product-owning IDs, a couple of IDs for system administration, and the IDs for the Linux virtual machines run under z/VM. Exposing these IDs using LDAP and for use elsewhere had little to no value.

Today however, two important aspects of running Linux under z/VM have changed these assumptions:

• IBM strongly recommands that all z/VM installations, regardless of the workload supported, are protected using an external security manager (ESM) such as RACF; and
• The well-known z/VM IDs such as MAINT and TCPMAINT should be protected and accessed using personal credentials (through “surrogate” logon, also known as “logon-by”) rather than a shared password.

These recommendations mean that not only is the use of RACF (or an equivalent ESM) much more prevalent, but the RACF database is more likely to have more usable IDs in it.

While it is true that many organisations use a corporate directory (such as Microsoft Active Directory) for many server authentication tasks, protection of z/VM is not handled that way. Besides, if such support was available it would not be appropriate to have everyone in the corporate directory able to log on to z/VM! The same comment could also be made about the ability to log on directly to the Linux OS. A particular group membership and corresponding LDAP filter would help to restrict the set of authorised users, but so too would having a separate “always-on” database co-located with z/VM and Linux which used the same password as the RACF logon to z/VM and only contained the IDs for the administrators that access the z/VM and Linux environment directly.

Integration with OpenLDAP

Okay, so we’ve established that running LDAP on z/VM makes some sense as a way to provide a highly-available and highly-secure LDAP authentication source. However let’s say there are reasons why populating a z/VM-based LDAP LDBM database is not right for your installation — say, an application that only supports the use of certain LDAP databases (including OpenLDAP). Do you have to miss out on RACF password goodness? No!

One particularly interesting approach I found was by using features of the OpenLDAP server to effectively extend Native Authentication over an OpenLDAP database. The features involved are:

• The LDAP backend (back-ldap)
• The Rewrite overlay (slapo-rwm)

Using the rewrite overlay, we can rewrite the bind() call from an LDAP client into a bind to a different LDAP DN: in our case, the DN for the user’s RACF entry, as exposed by SDBM. In the rewrite rule, it is even possible to do a look-up of the RACF DN to rewrite the bind() to — that way, the glue needed to link OpenLDAP to RACF is contained in OpenLDAP and we don’t have to try to extend the RACF SDBM database in any way. The way we reach that RACF DN is via back-ldap, which transparently makes another LDAP server’s DIT appear within the tree of the OpenLDAP server.

The journey continues…

Watch this space for more info about this capability. In a future post I will provide some more detail about the implementation (of course in the meantime you could check out the IBM Redbooks Security for Linux on z/VM publication!). I’ll also provide updates about ways to address password management — you don’t want folks to need a 3270 emulator to reset a password, right?