Authenticate SLES9 Linux clients using RACF and LDAP on z/OS


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
Plug-ins for your browser
Plug-ins for your browser

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 -D and -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:

  1. Install the pam_ldap package on your Linux client.

    On SUSE, log on as root and make sure the pam_ldap package is installed. Enter the following:
    ===> rpm -qa | grep pam_ldap

    You should see something like this if the pam_ldap is already installed:

    If the pam_ldap rpm 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 exists:
    esll10:/etc/pam.d # locate
    esll10:/etc/pam.d #

    If pam_ldap rpm is installed, but the is not in the /lib/security/ directory, a manual re-install using Yet Another System Tool (YaST) might fix the issue.
  2. 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.
    auth     required
    auth     sufficient
    auth     required
    auth     required use_first_pass
    account  sufficient
    account  required
    account  required
    password sufficient
    password required
    password required    use_first_pass use_authtok
    session  required    none # trace or debug
    session  required
    # Enable the following line to get resmgr support for
    # SSH sessions (see /usr/share/doc/packages/resmgr/README.SuSE)
    #session  optional 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

    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 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).
  3. Configure the Linux LDAP client /etc/ldap.conf and /etc/openldap/ldap.conf.

    With SUSE SLES9, there are two different ldap.conf files included in the shipment. The etc/openldap/ldap.conf is the configuration file for the LDAP client commmand line tools like ldapsearch, ldapadd, and so forth. The /etc/ldap.conf is 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.conf dataset 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.conf and their corresponding definitions in the z/OS slapd.conf file are:
    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 /etc/ldap.conf and /etc/openldap/ldap.conf.

    Here's an example of the etc/openldap/ldap.conf to configure for the z/OS LDAP server. The changes made are in BOLD text and customized for your unique naming conventions.
    # LDAP Defaults
    # See ldap.conf(5) for details
    # This file should be world readable but not world writable.
    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://
    #SIZELIMIT      12
    #TIMELIMIT      15
    #DEREF          never
    TLS_REQCERT allow

    Now edit /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.
    # 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  -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=*"

The -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.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Authenticate SLES9 Linux clients using RACF and LDAP on z/OS