Configuring slapd (LDAP) for the CLM "Money that Matters" scenario in Websphere Application Server

Over the last few years i have found myself doing something over and over again and at the same time constantly going back into all sorts of documentation in order to figure it out: How to set up and configure a basic ldap server for a Websphere CLM configuration.

Its not difficult but many things can go wrong and there are some configuration files that are needed to get a basic LDAP server going that has enough information (users and groups) to be able to create a basic functioning system.

In my role, I am constantly bringing up and tearing down topologies and in many cases I have to set up enterprise level systems where there are multiple instances of Websphere Application Server (WAS) servers (or WAS Network Deployment (ND) nodes) each hosting a product (CCM, RM, etc..) linked with each other.  All of these instances should share the authentication realm so that's where LDAP comes in.

Since the "Money that Matters" (MTM) CLM lifecycle sample that is packaged with CLM is a good starting point for test environments, proof of concepts and demos I use it a lot for sample data. 

In this blog, I will show how to set up a basic openldap server for a WAS server that will host the MTM sample. I won't go into the CLM details as those are well covered in the information centre.

As I am using Red Hat Enterprise Linux (RHEL) 64-bit (in this case 6.2)  most of the time to set up servers, these instructions pertain to that particular flavour of Linux. This should work with other Linux, Unix variants and also Windows (with some twists i am sure).

What you need to do

Login in as root (or use sudo on all of the following commands, your choice).

Use yum (our vanilla rpm) to install these rpms:

openldap-clients-2.4.23-20.el6.x86_64
openldap-servers-2.4.23-20.el6.x86_64
openldap-2.4.23-20.el6.x86_64

Make sure that your firewall (iptables) has port 389 open. Add the following line to your /etc/sysconfig/iptables:

-A INPUT -p tcp -m tcp --dport 389 -j ACCEPT

Start the slapd service, you may also want to start slapd on system boot:

service slapd start

chkconfig slapd on

By default, the RHEL installs slapd in such a way that the cn=config slapd configuration realm is only accessible from root. You can verify that slapd is running by issueing the following command:

ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

This should list the configuration parameters for the ldap server. We don't need to change the defaults so lets continue to create our new ldap database for the MTM sample. I have created two ldif files for this purpose. The first one, jazzdb.ldif creates the ldap database, and the second one jazz.ldif creates the users and groups for the MTM sample. 

Download jazzdb.ldif and jazz.ldif into a known location. You will need to modify the jazzdb.ldif file with a known password for the administrator. You can generate the password using the following command:

slappasswd

The utility will ask you for a password that you will need to confirm and generate an encrypted value that you will need to replace the current passwd with. So, replace the "olcRootPW: {SSHA}k7U/qvqrBs8T63fJnFa4+4V9S+ecp7Rg" value in the jazzdb.ldif file with the value that was generated by the slappasswd tool. Make sure not to leave any unwanted symbols after or before the line and note that there is a space after "olcRootPW:".

You may also want to customize the olcSuffix ( to something related to your domain) but be careful to search/replace this suffix everywhere in both the jazzdb.ldif and jazz.ldif files.

Once you have replaced this value you can go ahead create the slapd database:

ldapadd -Y EXTERNAL -H ldapi:/// -f jazzdb.ldif

Once this has completed successfully you can test both the new login you created for the RootDN and import the MTM users at the same time using:

ldapadd -x -D uid=servadm,ou=Users,dc=jazz,dc=net -W -f jazz.ldif

The password it asks is the one you used for the slappasswd generation utility. 

After this is complete, you can change the passwords of other users in the database by using the following command (for bob as an example):

ldappasswd -x -D uid=servadm,ou=Users,dc=jazz,dc=net -W -S "uid=bob,ou=Users,dc=jazz,dc=net"

If all of this worked so far then you are basically done setting up the slapd LDAP server and can now configure WAS to use LDAP.

I you have installed was you have either set it up to use a user name and password or with no security at all. In any case, login into the WAS administration console and go to the global security section. (We are using Websphere Application Server v8 but this is almost identical on other versions.)

Once the global security page comes up you should "Enable application security".

Then go to the "User account repository" section and choose "Standalone LDAP registry" as the realm definition and click "Configure..." (between 1 and 2 below):

Now you need to set up the LDAP settings as below. Replace the value of the distinguished names to reflect the value of the suffix, if you changed it, in the ldif files. Use the bind password of the LDAP administrator user for the database we just created.

NOTE: I am using localhost as the server name for LDAP. If you have a Websphere Network Deployment with multiple nodes, this is not a good idea and you should use the actual host name for your final configuration.

 Click Apply and Now click on:

Use these values in the form:

Click OK on this form and the subsequent form. In the next form ensure that the realm is set to LDAP and that the "Set Current" button is click and "Apply" is clicked.

WAS will not ask you to save and reboot which you should do (it may ask for your original WAS admin username and password when shutting down.). Once WAS has restarted you should be able to login with the "servadm" username and LDAP administrator password.

If the authentication fails you can try to change the  ldap password of servadm using the ldappasswd command above (use servadm instead of bob). 

If this still fails and you cannot log into WAS, make sure slapd is running and if all else fails take a look inside the security.xml file of WAS to ensure your settings are correct. This file can typically be found in:

<WAS Installation Dir>/profiles/<profile name>/config/cells/<cell name>/security.xml

If you change it, you will need to reboot WAS.

At this point, WAS is set up and has all the users and groups required for a clean installation of the CLM and creation of the MTM scenario.

For more information on where to go from here, look at the information center on how to install CLM into WAS.

C# with Visual Studio and Rational Team Concert (OSLC revisted) (Part 2)

In Part 1, I showed how to set up a basic visual studio environment which we will now use to create an OSLC client. The client we will create is quite rudimentary and is based on the code in the OSLC workshop (which is itself, java.) 

The code does not do much more then a form-based authentication with RTC 3.0.1.2 and fetches a list of project areas using XPath.  The .NET framework (I am using v. 4) has everything we need to create a connection with RTC, authenticate and query the content. It's just as easy to do with C# as it is in Java and the code, in fact, is quite similar. I am using Visual Studio 2010 and .NET v4 but the code should either work as is, or with some slight modifications, on other versions.

You will need to get the point we finished in Part 1. Once you are there, let's start fresh and close down Visual studio and unzip the following zip file into your sandbox (overwriting along the way.) 

VS/RTC sandbox: C# OSLC Consumer.zip

Open up visual studio and immediately go to the RTC "Team Artifacts" window. Go to the sandbox list Right click and select "Set current" to activate and open the solution in Visual Studio. You can go ahead and go to the "Solution Explorer" and delete the default Program.cs and Class1.cs files that the wizard created. You can the add the new .cs files by your the project context menus and Add->Existing Item. You can then add the missing files (OSLCConsumer.cs and HttpUtils.cs) from there.

You can also go ahead and deliver these changes by going to the "Pending Changes" Window, and check-in and deliver all the new changes.

You can to build and run the project at this point by clicking on the "Play" button as per normal Visual Studio usage but you will probably need to modify a few settings namely:

string server = "https://localhost:9443/ccm"; //<-Your RTC server

string url = "https://localhost:9443/ccm/rootservices"; //<- the rootservices URL

string login = "ADMIN";    //<-Your RTC username

string password = "yourpassword";  //<-Your RTC password

Once you have looked over the code and perhaps run it, it demonstrates the following:

1. How to do form authentication with C#
2. How to issue OSLC requests using C# 
3. Use XPath to fetch Project area names (service providers)

If everything is working file, the output window could look like this:

If you need to have more in depth information about how this code functionality works I suggest to take a look at the OSLC workshop as this code sample is loosely based on it. Enjoy!

Next up (part 3)... I will expand on this example, and create an automated build environment for our new code using RTC SCM and automated builds!