Use Tivoli Directory Sever to authenticate Linux users
shows how to configure a Linux client to use lightweight directory access protocol (LDAP) to authenticate against multiple AIX-based Tivoli Directory Servers (TDSs). To make authentication requests, we will not only transport them using the Secure Socket Layer transport mechanism but also require that each Linux client proofs its authenticity presenting LDAP server with the appropriate server security certificate, which the server will validate before responding to the client request. This model is known as the Server Side Authentication. Another more stringent security model is called Server and Client Authentication.
In the first model, each LDAP server generates its own security certificate that’s distributed to its clients, which include them in their authentication (login) request. If the provided security certificate matches the LDAP server certificate, the client dialog with the server is allowed to continue, otherwise the server immediately terminates the communication session.
In the second case, the LDAP server maintains in its security certificate database not only its own security keys but also those of all the clients deemed trusted. In this situation, the client opens its communication by presenting the server security keys as well as its own. The LDAP server compares these keys against the contents of its security keys database and, if positive matches of all keys are made, the communication is allowed to continue. Otherwise, like in the previous case, the LDAP server terminates communication.
LDAP is not just an authentication tool. It can also be used to globally manage autofs/automounter or sudo.
This article doesn’t apply only to LDAP domains supported by TDSs with Red Hat Linux clients. Exactly the same technique and logic applies to all LDAP environments, regardless of their servers or clients’ operating systems. So, if your data center contains AIX, Linux or Solaris clients and your LDAP servers aren’t TDSs, this article will still benefit you.
A healthy LDAP environment consists of at least two LDAP servers. It’s even better to have these severs configured as peers—so modification to LDAP “knowledge” of one of them is automatically passed and performed on its peer or peers. In such an environment, every LDAP server always contain identical information about the domain they serve. In this article, the LDAP servers will be called “aixtds1” and “aixtds2.”
To configure LDAP server-side authentication for our Linux-based clients, we will use the same server security certificates that were created in the past while configuring LDAP/SSL authentication of our AIX hosts. Each TDS certificate will be stored in an appropriately named file: aixtds1.cer and aixtds2.cer. But before these certificates can be stored in the Linux host certificate database, they have to be converted to the format understood by Red Hat. Proceeding further without explaining how to create server security certificates would make this article incomplete. Brief AIX Detour
So, let’s take a momentary detour and focus on AIX (our LDAP/TDSs run on AIX) before we move to a Linux client. On each LDAP server, we start with the creation of a security keys database—the place to store security certificates or keys as they are sometimes called. To create the database, you may use the command line entry executing gsk8capicmd_64. Check with your OS level as the name of this command changes slightly depending on the version of AIX and the type (32 or 64 bit) of kernel. If you’re graphically inclined, you may use the ikeyman command. In that case, make sure your session’s JAVA_HOME points to the same locations as needed by ikeyman. Creating the self-signed security certificates calls for a special type of the security keys database. It has to be a Certificate Management System (CMS)-type database. To enable support for the CMS database you will most likely need to edit the file $JAVA_HOME/jre/lib/security/java.security. Do so by adding the following entry:
security.provider.X=com.ibm.security.cmskeystore.CMSProvider
Here, X is the next consecutive number in this file.
To create a security certificate database on the TDS called aixtds1, I used the following command:
# gsk8capicmd_64 -keydb -create -db aixtds1.kdb -pw abc123 –type cms –stash
In this example, aixtds1.kdb is the database name and abc123 is the password required to access it. Four files will be created with extensions of sth, rdb, kdb and crl. Next, we need to create the server self-signed certificate and store it in its security database (kdb) file. By the way, I set this certificate to expire at the end of 7,000 days—you may decide differently.
# gsk8capicmd_64 -cert -create -db aixtds1.kdb -pw abc123 -label aixtds1 -dn "cn=aixtds1.wmd.edu" -default_cert yes -expire 7000
To view the contents of the key database file, modify the last command to include the –list directive:
# gsk8capicmd_64 -cert -list -db aixtds1.kdb -pw abc123 Certificates found * default, - personal, ! trusted *-! Aixtds1
The server self-signed security certificate has to be extracted and copied to each AIX/Linux host which will use SSL to communicate with LDAP servers.
# gsk8capicmd_64 -cert -extract -db aixtds1.kdb -pw abc123 -label aixtds1 -target aixtds1.arm -format binary
In my case, the certificate is stored in the binary format inside the file called aixtds2.arm. This whole procedure has to be repeated on all TDSs, and the resulting arm files have to be copied to each AIX/Linux host which will use them to resolve its authentication queries with LDAP servers. Here, we enter the Linux realm.
First, check the Red Hat client for the presence of all necessary packages. In the case of AIX, we would use the lslpp command, but since this isn’t AIX, we have to use the Linux command called rpm.
# rpm -qa | grep ldap pam_ldap-185-11.el6.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 openldap-2.4.23-26.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 openldap-devel-2.4.23-26.el6.x86_64 nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64 openldap-clients-2.4.23-26.el6.x86_64
To convert an AIX certificate into the format that Linux “understands,” we have to use the openssl command, as shown here:
# openssl x509 -inform DER -in aixtds1.arm -outform PEM -out server_aixtds1.pem
And since my Linux clients’ LDAP environment is defined by two TDSs, the same command will be used to converts the second server certificates:
# openssl x509 -inform DER -in aixtds2.arm -outform PEM -out server_aixtds2.pem
With the security certificates converted, they have to be loaded into the Linux client security certificate database.
# certutil -A -d /somepath/aixtds1.arm -n "AixTds1 Certificate" -t "CT,," -a -i aixtds1.pem # certutil -A -d /somepath/aixtds2.arm -n "AixTds2 Certificate" -t "CT,," -a -i aixtds2.pem
To verify the contents of the certificates databases, we will execute the command certutil as shown next:
# certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI AixTds1 Certificate CT,, Certificate CT,,
At this time, all is ready and we can start the actual configuration process of the Red Hat client. There are several ways this could be done. I personally like to use the authconfig-tui utility. From the first screen (see Figure 1), select the following entries: “Use LDAP, Use MD5 Passwords, Use Shadow Passwords, Use LDAP Authentication, Local authorization is sufficient.”
The last entry is required if you want the host’s local administrative accounts (root and so forth) to be authenticated locally.
Use the following format to specify more than one LDAP server:
ldaps:aixtds1.wmd.edu/,ldaps:aixtds2.wmd.edu/
Notice that each LDAP server definition starts with the word “ldaps,” signifying SSL-based communication between the client and the LDAP servers. If you don’t want to use the default communication port for client/server messages, you could specify on the screen in Figure 2. For example:
ldaps:aixtds1.wmd.edu:636/,ldaps:aixtds2.wmd.edu:636
The “Base DN” entry defines the location within the LDAP tree where the UNIX information (passwords, groups, etc.) is stored, which in your case will be something different from what I entered. The authoconfig-tui command modifies few files. Looking into the /etc/openldap/ldap.conf, we see it has the following contents:
TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand URI ldaps://aixtds1.wmd.edu:636/ ldaps://aixtds2.wmd.edu:636/ BASE cn=aixdata,dc=wmd,dc=edu The file /etc/nslcd.conf contains: uid nslcd gid ldap # This comment prevents repeated auto-migration of settings. uri ldaps://aixtds1.wmd.edu:636/ ldaps://aixtds2.wmd.edu:636/ base cn=aixdata,dc=chop,dc=edu ssl on tls_cacertdir /etc/openldap/certs
The file /etc/pam_ldap.conf has these entries:
# The distinguished name of the search base. base cn=aixdata,dc=chop,dc=edu uri ldaps://aixtds1.wmd.edu:636/ ldaps://aixtds2.wmd.edu:636/ ssl on tls_cacertdir /etc/openldap/certs pam_password md5
The file /etc/nsswitch.conf includes these LDAP references:
passwd: files ldap shadow: files ldap group: files ldap .......................... .......................... automount: files ldap
This is it, folks! It’s time to restart the daemons.
# service oddjobd stop # service nslcd stop # service oddjobd start # service nslcd start
To verify that the LDAP data is delivered to the client:
# getent passwd # getent group
You may also use the ldapsearch command, for example:
# ldapsearch -H ldaps://aixtds1.wmd.edu:636 -s base -x -b " " objectclass=*
Audit Options
It may be helpful to enable the audit daemon on your TDSs while configuring Linux clients. With active audit, you can view the bind requests in real time, executing the following command (where the IP address shown is the address of the Linux host being configured):
aixtds1:TP:/home/ldap63/idsslapd-ldap63/logs>tail -f audit.log AuditV3--2012-07-26-11:53:25.994-373143:25--V3 SSL anonymous Search-- bindDN: <*CN=NULLDN*>--client: 10.20.131.198:39878--connectionID: 4321-- received: 2012-07-26-11:53:25.993-373143:25--Invalid DN syntax
This excerpt above shows that the SSL is being used to communicate (exactly what we wanted) and that a bind request cannot succeed because of the “Invalid DN syntax.” Indeed, I “fat fingered” the Base DN entry. After correcting it and restarting LDAP daemons, all worked like a charm. Don’t forget to disable auditing after you’re done as this functionality generates copious amount of data, requiring a lot of storage. Heterogeneous Environments
Today, it’s rather uncommon to see a data center without Linux. Managing heterogeneous environments presents numerous challenges. It’s very convenient to use the same tools to authenticate different OSs using the same tools. One of these tools is LDAP, There are many implementations of this protocol. The TDS is one of them developed and supported by IBM. It’s an easily adaptable and rock-solid product, providing full support for AIX and Linux clients.
