modifying entry cn=schema
Any other response should indicate an error condition.
To perform Linux authentication with the z/VM LDAP server, an additional schema is required. It’s mentioned in the Security on z/VM Redbook (SG24- 7471). You can download the schema file from ftp://www.redbooks.ibm.com/redbooks/REDP0221/nisSchema.2.ldif. This schema provides the definition for uidnumber, gidnumber, homedirectory, and loginshell, among others important for Linux to use when logging in. After obtaining the schema, upload it to z/VM as NISSCHEM.LDIF. You should make a minor change to line 5 of the file. Change the text ‘dn:cn=schema, <suffix>’ to ‘dn: cn=schema’.
Adding the schema to the LDAP server is just like the previous two examples, except for the file name:
ldapmdfy -h 127.0.0.1 -D "cn=Admin" -w
secret -f //NISSCHEM.LDIF -u on.
As before, unless there’s an error, only one response is expected.
The next step is to add the administrator to the LDAP database. On TCPMAINTs 591 disk is a sample file: SAMPSERV LDIF. It contains sample LDIF entries for various scenarios related to LDAP operations. The first two entries fit what you’re about to do. You’re going to add your top-level organization and your administrator. Based on the first two entries in the file, you’ll create a file called ADMIN LDIF (see Figure 4). Your file contains two entries; the blank line delineates the entries. The first entry adds the organization unit (ou=vm, dc=vmassist, dc=com); the second entry adds the administrator (cn=admin). Use the ldapadd command to add the entries to LDAPs LDBM database:
ldapadd -h 127.0.0.1 -w secret -D
"cn=Admin" -f //admin.ldif
The responses should confirm that both entries were successfully added:
adding new entry ou=vm, dc=vmassist, dc=com
adding new entry cn=Admin, ou=vm,
A couple of configuration changes are now needed. In the configuration file, DS CONF, you will change the adminDN parameter and comment out the adminPW parameter. Since the LDAP database now has proper entries, the configuration file doesn’t need to be used for password storage:
adminDN "cn=Admin, ou=vm, dc=VMAssist,
dc=com" #adminPW secret
For security reasons, consider turning off anonymous binds in the configuration file. The remainder of the examples won’t use anonymous binds. At this time, restart the LDAP server. The changes will be listed in the configuration summary at start-up.
The ldapsearch command can be used to list the newly added entries:
ldapsrch -h 127.0.0.1 -D "cn=Admin,ou=vm,dc=
vmassist,dc=com" -w secret -b "ou=vm,dc=
Using this command with anonymous binds turned off, you need to provide credentials to perform any operation on the LDAP database. That requires a combination of the -D (to identify who you’re going to perform the operation as) and -w flag (to prove you’re actually that person). The final item on the command line is a filter requesting the search to list only that user. Figure 5 shows the response.
If the z/VM LDAP server is set up to work in conjunction with RACF, the two packages work well together to create a comprehensive security solution. That configuration is covered in the Security on z/VM Redbook. Although RACF provides for a much more secure system, the LDAP server doesn’t require RACF to work and that’s the focus of the remainder of the article.
To use Linux with the z/VM LDAP server, you may need to install some prerequisite software. You can use SUSE Linux Enterprise Server (SLES) 10 Service Pack 2 to perform this configuration.
Start YaST, select Network Services and LDAP client. During this first use of the LDAP client screen, it may notify you that the additional packages are required. If you’re using the text mode screen, it will look something like Figure 6 when filled in. You’ve basically told the Linux LDAP client all about connecting to your z/VM LDAP server, including that when new users are being created on Linux, their home directories also should automatically be created. Clicking on “Advanced Configuration” will bring you to another screen that you can leave as-is. Just click on “Accept.” YaST essentially populates configuration files. One of the files it writes is called /etc/ldap.conf. Figure 7 shows some of the contents with comments removed.
This configuration is exactly what you want. YaST also will modify several other files, /etc/nsswitch.conf, and files in the /etc/security and /etc/pam.d directories. Unfortunately, LDAP doesn’t work the way you want it to after YaST is done modifying the files, so you need to intervene. In /etc/nsswitch.conf, modify the passwd and group lines to look like this:
passwd: files ldap
group: files ldap
The lines in /etc/nsswitch.conf that start with passwd_compat and group_compat can be removed. In the file /etc/ security/pam_unix2.conf, remove the word ‘ldap’ from the lines that start auth, account and password, but leave the lines in the file.
The files in /etc/pam.d configure the Pluggable Authentication Module (PAM) and provide a way to extend the Linux security infrastructure. Change these files to work properly with your LDAP configuration. The format of the files you’re changing is similar. The files are called common-auth, common-account, common-password, and common-session. Figure 8 shows the before and after changes made to common-auth.
The first item on the line in each file must match the part of the filename after the dash. In this case, auth, which is in the filename common-auth. You must set the second item on the new line to “required” and the third item on the new line must be pam_ldap.so. Make the same changes to the other three files. These PAM files control the login, ssh, and passwd services.
You must create an LDIF file to authenticate a new user for Linux use. On CMS, you created a file called RKS1 LDIF. Figure 9 shows the file contents. This LDIF file will contain the appropriate Linux information to allow a login, uid, gid, home directory and initial shell, all of which are normally provided in /etc/passwd during login, but are mimicked here for an LDAP login.
Use the ldapadd command to add the user defined in the LDIF file to the LDAP database:
ldapadd -h 127.0.0.1 -w secret -D "cn=admin
,ou=vm,dc=VMAssist,dc=US" -f //rks1.ldif
The response should indicate the user was successfully added. If you telnet or ssh to the host and login as the user rks1, you should see that the user’s home directory was automatically created, which is what was requested when you configured the LDAP client (see Figure 10). The id command shows that Linux knows user rks1 is uid 2000 and gid 100.
For FTP to work, you’ll have to change the file /etc/pam.d/vsftpd. But this time, just insert the pam_ldap.so line before pam_unix2.so in the auth and account section of the file. When you’re done, you’ll be able to log on to FTP using LDAP authentication.
The ldapsearch command is one way to view the LDAP database, but it isn’t an efficient way to view a large LDAP database. LDAP browsers provide a better method to see the database; they present it in a more intuitive format. Some LDAP browsers also provide editing capabilities. If you have the proper credentials, you can change the data in the database.
YaST contains an LDAP browser. Select Network Services and LDAP Browser from the YaST menu. You will be prompted to enter information about the LDAP server you want to connect to. The smaller window in Figure 11 shows how the LDAP server is configured for the LDAP browser; the rest of the window shows the results of the browse. If you highlight a user and select open, the details about that user will look like Figure 12.
Note that when browsing the directory the passwords are in clear text. A simple configuration change will fix this. In the DS CONF file in the LDBM section, find the pwEncryption option. The LDAP server provides multiple ways to encrypt passwords. For example, you can change the config file to read:
After this change, restart the LDAP server. Now, when browsing the LDAP server, the passwords are garbled.
Now that the LDAP server is properly configured, other software can be integrated with the LDAP server. All that’s needed is the hostname or IP address and bind credentials. Any software or application that requires a logon can now use z/VM as an authentication source. We’ve tested Apache, application software SugarCRM, and the Hobbit network services monitor.
Starting with version 4.2, the z/VSE operating system now delivers an optional LDAP client. Part of this support allows long userids and passwords. We have the z/VSE LDAP client configured to connect to the LDAP server for z/VM to authenticate z/VSE users. With users defined on the LDAP database on z/VM, we’re able to log on to z/VSE with long userids and passwords. For additional details about the z/VSE LDAP client, see the article by Ingo Franzki in this issue.
LDAP server operation is quite simple. It automatically starts when TCP/IP is initialized and can be shut down by an authorized user with the command SMSG LDAPSRV SHUTDOWN. It doesn’t respond to the shutdown signal.
The z/VM LDAP server is a powerful tool in the System z security arsenal. Coupled with the RACF security server, it provides an excellent way to authenticate your Linux users and other applications.
LDAP System Administration, Gerald Carter, March 2003, O’Reilly
Essential System Administration, Aeleen Frisch, 3rd Edition, August 2007, O’Reilly
Security on z/VM (Redbook): SG24-7471-00
z/VM TCP/IP User’s Guide: SC24-6124-03 (z/VM 5.3); SC24-6124-04 (z/VM 5.4)
z/VM TCP/IP LDAP Administration Guide: SC24-6140-00 (z/VM 5.3); SC24-6140-01 (z/VM 5.4).