AIX > Trends > Linux

Extending Tivoli Directory Server LDAP Services to Linux Clients

This article (based on a post from my blog:, 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/ Do so by adding the following entry:

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 "" \
-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.

Mark Duszyk lives and works in the Delaware Valley. He has spent many years working with AIX and recently got involved with Linux. Beside his blog, his interests include fly fishing and photography.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


The Great Debate: AIX Versus Linux

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters