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 method.
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@zlinux1My 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).
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
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...