In 2009 I was part of the team that produced the Redbook "Security for Linux on System z" (find it at http://www.redbooks.ibm.com/abstracts/sg247728.html
). Part of my contribution was a discussion about using the z/VM LDAP Server to provide Linux guests with a secure password authentication capability. I probably went a little overboard with screenshots of phpLDAPadmin
, but overall I think it was useful.
I've come back to implement some of what I'd put together then, and unfortunately found... not errors
as such, but things I perhaps could have discussed in a little more detail. I've been using the z/VM LDAP Server on a couple of systems in my lab but had not enabled RACF. I realised I need to "eat my own cooking" though, so decided to implement RACF and enable the SDBM backend as well as switch to using Native Authentication in the LDBM backend.
Native Authentication provides a way for security administrators to present a standard RFC 2307 (or equivalent) directory structure to clients while at the same time taking advantage of RACF as a password or pass phrase store. Have a look in our Redbook for more detail, but basically the usual schema is loaded into LDAP and records are created using the usual object classes like inetOrgPerson
, but the records do not contain the userPassword
attribute. Instead of comparing a presented password against the field contained in LDAP, the z/VM LDAP Server (when Native Authentication is enabled) issues a RACROUTE call to RACF to have it check the password.
In my existing LDAP database, I had user records that were working quite successfully to authenticate logons to Linux. My plan was simply to enable RACF, creating users in RACF with the same userid as the uid
field in LDAP (I have access to a userid convention that fits RACF's 8-character restriction, so no need to change it). After going through the steps in the RACF program directory, and various follow-up tasks to make sure that various service machines would work correctly, I did the LDAP reconfiguration to get Native Authentication.
At this point I probably need to clarify my userid plan. The documentation for Native Authentication in the TCP/IP Planning and Administration manual says that the LDAP server needs to be able to work out which RACF userid corresponds to the user record in LDAP to be able to validate the password. It does this by either having the RACF userid explicitly specified using the ibm-nativeId
attribute (the object class ibm-NativeAuthentication
has to be added to the user object), or by matching the existing uid
attribute with RACF. This is what I hoped to be able to do; by using the same ID in RACF as I was already using in LDAP, I planned to not require the extra object class and attribute. In the Redbook, because my RACF ID was different from the LDAP one I went straight to using the ibm-nativeId
attribute and didn't go back and test the uid
So, I gave it a try. I had to disable SSH public-key authentication so that my password would actually get used, and once I did that I found that I couldn't log on. It didn't matter whether I tried with my password or pass phrase, neither was successful. I read and re-read all the LDAP setup tasks and checked the setup, but it all looked fine. In one of those "let's just see" moments, I decided to see if it worked with the ibm-nativeId
attribute specified in uppercase... and it did!
Okay, so it appeared
that the testing of uid
against a RACF id was case-sensitive. I decided to try creating a different ID, with an uppercase uid
, in LDAP to double-check. Since phpLDAPadmin wouldn't let me create an uppercase version of my own userid (since that would be non-unique), I created a different LDAP id to test:
[viccross@laptop ~]$ ssh MAINT@zlinux1
Could not chdir to home directory /home/MAINT: No such file or directory
/usr/X11R6/bin/xauth: error in locking authority file /home/MAINT/.Xauthority
My MAINT user in LDAP has no ibm-nativeId
attribute, so the only operational difference is the uppercase uid
(the error messages are caused by the LDAP userid not having a home directory; I use a NFS shared home directory had I hadn't bothered setting up the homedir for a test userid).
The final test was to change the contents of the ibm-nativeId
attribute in my LDAP user record to lower-case -- and it broke my login. So that would seem to indicate that the user check against RACF is case sensitive wherever LDAP gets the userid from. I'm going to have a look through documentation to see if there's something I need to change, but this looks like something to be aware of when using Native Authentication.
I also noticed that I didn't describe the LDAP Server SSL/TLS support in the Redbook, but that's a post for another day...