This information is from the Securing Linux for zSeries with a Central z/OS (RACF) LDAP Server IBM® Redpaper and the z/OS LDAP Administration and Use guide, SC24-5923. These IBM documents explain how to use LDAP with an SDBM backend (RACF) and TDBM backend (DB2®). The content in this article is only applicable to a z/OS configuration for LDAP using an SDBM (RACF) backend. Instead of using the password that typically is stored in each Linux™ client, the password used is a RACF-managed password. A Linux user can update his RACF password once and have it take effect across multiple Linux clients, as shown in Figure 1 below.
Figure 1. z/OS configuration for LDAP using an SDBM (RACF) backend
Configure the LDAP server on z/OS
First, set up the LDAP server on z/OS before making any changes to the Linux client. Refer to the z/OS LDAP Administration and Use guide for instructions. You will eventually configure the Linux SLES9 client, as documented here, to match what was defined on the LDAP server. In this exercise, I'm only using RACF (SDBM) for user authentication with no usage of DB2. The intent is to be able to Secure shell (SSH) into the Linux client IP address and login using the RACF password on z/OS for user authentication into the Linux system.
I do not outline all the steps it takes to set up a z/OS LDAP server, which you need to have someone with z/OS systems programming skills to set up. The information presented here only provides detailed steps on configuring Linux.
A RACF userid on z/OS must be defined to allow bind authorization coming in from the Linux clients. In this example, I defined the RACF userid, LDAPADM. At the time of this writing, testing a Linux client using a Plug-in Authentication Module (PAM) to complete login, using the z/OS LDAP server, fails unless the LDAP Administration userid has the RACF AUDITOR attribute set on. Testing has been done with PERMITs to give the LDAP administration userid READ access to FACILITY resources, IRR.LISTUSER and USER.OMVS.*, to see if the AUDITOR attribute can be removed, but the login attempt fails.
A key LDAP configuration file dataset on z/OS,
slapd.conf, contains definitions that need to be match accordingly, information defined on the linux client (ldap.conf). I explain in more details further on.
Verify the LDAP server independent of Linux client changes
After you complete setting up the LDAP server on z/OS, verify the LDAP server by using the ldapsearch command. Note that you can use any LDAP client to do this. As an alternative, you can also use TSO (TIME SHARING OPTION), substituting the TSO command, LDAPSRCH, for ldapsearch.
For SDBM, you must bind with a valid RACF-style DN to perform the search. Substitute a RACFID of your choice in the racfid portion of the DN on the
-D and the
-b parameters below. Also, substitute your SDBM suffix in the DN on the
-b parameters. You must specify the RACF password (the same userid for the
-D parameter) in the
-w parameter (see Listing 1).
As an alternative, you can also verify this using some form of tool, for example, the LDAPBROWSER tool. You can download LDAPBROWSER from MCS. This tool allows you to perform some basic verification of your z/OS LDAP setup before making Linux changes.
Linux client changes
Once you have performed basic verification of your z/OS LDAP setup, then perform the following steps on your Linux client:
- Install the
pam_ldappackage on your Linux client.
On SUSE, log on as root and make sure the
pam_ldappackage is installed. Enter the following:
===> rpm -qa | grep pam_ldap
You should see something like this if the
pam_ldapis already installed:
pam_ldaprpm package is not installed, then enter the following to install the package:
===> rpm -ivh pam_ldap-xxx-xx.rpm
Also, make sure that the following
esll10:/etc/pam.d # locate pam_ldap.so /lib/security/pam_ldap.so esll10:/etc/pam.d #
pam_ldaprpm is installed, but the
pam_ldap.sois not in the /lib/security/pam_ldap.so directory, a manual re-install using Yet Another System Tool (YaST) might fix the issue.
- Configure the PAM LDAP module corresponding to the service in /etc/pam.d. Each service (SSH, Telnet, and so forth) you use to access your Linux client must be configured separately to use LDAP. You must separately configure each service you use to access your Linux client in order to use LDAP.
The recommended way to access a Linux system is by SSH. Configure SSH to use LDAP by editing /etc/pam.d/sshd. Changes below are in BOLD text.
#%PAM-1.0 auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_env.so auth required pam_unix2.so use_first_pass account sufficient pam_ldap.so account required pam_unix2.so account required pam_nologin.so password sufficient pam_ldap.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so none # trace or debug session required pam_limits.so # Enable the following line to get resmgr support for # SSH sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session optional pam_resmgr.so fake_ttyname ~
The order of the statements in the configuration file is important, therefore, ensure that the following statement is listed before the other statements with the auth keyword:
auth required pam_nologin.so
List the following statement after the LDAP authentication statement in order to allow an additional check against the local information stored in /etc/passwd and /etc/shadow:
auth required pam_unix.so use_first_pass
This statement ensures you still have a way to gain access to the system even when the central LDAP server cannot be used for authentication (for example, because the LDAP server stopped, there was a network problem, or because the root user account is not in the LDAP-RACF directory).
- Configure the Linux LDAP client
With SUSE SLES9, there are two
different ldap.conffiles included in the shipment. The
etc/openldap/ldap.confis the configuration file for the LDAP client commmand line tools like ldapsearch, ldapadd, and so forth. The
/etc/ldap.confis required for login RACF authentication. You need to modify both files in order to set up the client. There is also a YaST configuration that allows you to set up an LDAP server/client with SLES9, but I was not able to get it to work with an LDAP server on z/OS. I believe it is geared to set up a Linux LDAP server and doesn't have any idea of LDAP on z/OS. In light of that, let's go over the manual steps to set up the client.
Configure the Linux LDAP client to match the configuration names in
slapd.confdataset found on the z/OS LDAP server. This means that the Linux programmer will have to communicate with the z/OS LDAP administration and the following key pieces of information, since the names need to match exactly.
Note that the naming conventions on z/OS are different than the naming conventions used on Linux.
The parameters from
ldap.confand their corresponding definitions in the z/OS
- Specify the z/OS LDAP server IP/HOSTNAME.
- Specify the suffix parameter specified in the slapd.conf on the z/OS server.
- Specify the adminDN parameter specified in the slapd.conf file on the z/OS server.
- Specify the password of the RACF userid (LDAP server administrator DN) associated with the LDAP server.
Another Linux client parameter is:
- Specify "racfid"
If you want to log in from a Linux client, it is important that the RACFID, specified in the ADMINDN parameter (that is, LDAPADM), have the AUDITOR attribute. Ldapsearch commands work from the Linux client without the AUDITOR attribute, but not logins. Having access to the FACILITY IRR.LISTUSER class profile does not work (at the time of this writing) for logins.
Configure the Linux client by editing
Here's an example of the
etc/openldap/ldap.confto configure for the z/OS LDAP server. The changes made are in BOLD text and customized for your unique naming conventions.
/etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. host server.pok.ibm.com base sysplex=HPCSA,o=ibm,cn=yourracf binddn racfid=LDAPADM,profiletype=user,sysplex=HPCSA,o=ibm,cn=yourracf ldap_version 3 pam_login_attribute racfid #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_REQCERT allow
/etc/ldap.conf. The changes made are in BOLD text and customized for your unique naming conventions. In this example, the LDAP server was part of a zSeries® sysplex, so you need to use the sysplex keywords in your setup.
# Your LDAP server. Must be resolvable without using LDAP. host server.pok.ibm.com # The distinguished name of the search base. base sysplex=HPCSA,o=ibm,cn=yourracf binddn racfid=LDAPADM,profiletype=user,sysplex=HPCSA,o=ibm,cn=yourracf bindpw <secret> # The user ID attribute (defaults to uid) pam_login_attribute racfid # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls
Save your changes to the two
ldap.conf files above.
Log in using RACF authentication
Verify your setup by opening up an SSH session to your Linux client and log in your userid and password combination.
Any RACF-defined user, with an OMVS segment in RACF, can log in to a Linux system if the Linux username is equal to the RACF userid. In this case, you would enter the password that exists for the RACF-defined z/OS userid.
With this solution, users always have the same password on all systems where they perform a login. Passwords are kept centrally and protected by RACF. On the Linux side, you do not have to enter additional passwords in /etc/shadow. You still have to keep and maintain user information in /etc/passwd for each of your Linux systems for local user information retrieval (user identification).
You should also be able to perform LDAP client commands, such as ldapsearch, if you specify the correct LDAP server administration DN and password.
ldapsearch -v -x -h esls38.pdl.pok.ibm.com -D racfid=LDAPADM,profiletype=user,sysplex=HPCSA,o=ibm,cn=pkeslracfa -w password -b racfid=LDAPADM,profiletype=user,sysplex=HPCSA,o=ibm,cn=pkeslracfa "objectclass=*" ldapsearch -v -x -D racfid=LDAPADM,profiletype=user,sysplex=HPCSA,o=ibm,cn=pkeslracfa -w password "objectclass=*"
-x option means perform simple authentication and appears to be required from the Linux client for this solution.
Any RACF-defined user, with an OMVS segment in RACF, can log in to a Linux system if the Linux username is equal to the RACF userid.
- Read the z/OS LDAP Administration and Use guide for more information on how to use LDAP with an SDBM and TDBM backend.
- Get the IBM Repaper Linux on IBM zSeries and S/390: Securing Linux for zSeries with a central z/OS LDAP server (RACF), June 2002.
- Read "How to use z/VM VDISKS for Linux swap devices instead of real physical DASD" (developerWorks, January 2005) on setting up a z/VM VDISK for a Linux swap device.
- Check out what's new in zSeries.
- Browse for books on these and other technical topics.
- Want more? The developerWorks eServer zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on the eServer brand.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
Dig deeper into Linux on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.