This is doing a very minimal setup, just to get it working so you can tweak whatever you need. Hopefully following this you will at least have a working basic connection/authentication system working. Going to assume a fair amount of knowledge of LDAP.

The ins and outs of configuring Websphere Portal 6.1.5 with OpenLdap are too numerous to count. My experience has been that there are about 4-5 ways of doing the same thing and in the end there is only really 1 way of doing it successfully. I am only going to document the correct way since my adventure will not be the same as yours and chances are you will still have to do some discovering even if you follow this exactly.

I'm going to assume you already have Websphere (with or without Web Content Management installed) with all the correct files and currently it is working fine with whatever security it came with. For brevity I'm going to also assume you have downloaded some form of OpenLdap package for Windows and you just need to run through the installer. Feel free to use all the default settings on the installer. I used the DB that came with OpenLdap, Berkley I believe.

The next thing you'll need to do is configure OpenLdap via editing it's slapd.conf file located in the OpenLdap parent directory. The installer I used apparently didn't know the difference between a Windows environment and a Linux/Unix environment and so all the path's in my slapd.conf initially started with "./" so I had to delete all the "./" from the beginning of the paths.

For a minimal setup there are only three values you need to change in this file (minus the "./" if you came across that, see above). They are "suffix", "rootdn" and "rootpw".

My values are (quotes included):

rootdn "cn=Manager,dc=captechconsulting,dc=com"

suffix "dc=captechconsulting,dc=com"

rootdn "cn=Manager,dc=captechconsulting,dc=com"

rootpw secret

What's happening here is you are actually giving your instance of OpenLdap a domain with the "suffix" attribute. My OpenLdap was not setup with a root for anything, an empty directory tree, so I created my LDAP from scratch (if you already have one setup feel free to skim through this of course). OpenLdap from what I saw from Google searching always has a rootdn of "Manager" something... so I simply removed the DC that was there and made my own.

That's it. Restart openLdap and you should be able to connect with "cn=Manager,dc=captechconsulting,dc=com" and assuming you didn't change the default password you can use "secret".

I downloaded Apache Active Directory studio to create me LDAP directory from scratch. I connected as above and then used the GUI to create my groups and users etc. There is also an Eclipse plugin in the JBoss tools project as well I believe.

There are some basic groups that Websphere requires and you need a user(s) as members of these groups. Again, simple setup means I have only two users, "admin" and "jbleach". I assigned "admin" to all the required groups and "jbleach" to only one. My intent here was to limit the amount of confusion that comes with manually editing configuration files. If I had one user that was my value for all the configuration entries there would be a better chance of it working. I added the jbleach user only to sanity test Websphere once admin was working to ensure I really did, in fact, have a working LDAP->Websphere connection.

Here is what my LDAP directory looked like with only the required Websphere groups added:


- ou=groups

- cn=wcmadmins

- cn=wcmContentAuthors

- cn=wpsadmins

- cn=wpsContentAdministrators

- cn=wpsDocReviewer (this is the only group jbleach was in)

- ou=people

- uid=admin

- uid=jbleach

As far as the object types all groups were "groupOfUniqueName", "top" with unqiueMember's and the people/users had the following object types "inetOrgPerson" , "organizationalPerson", "person", "top". I mention these because they will need to appear in the configuration files.

The majority of my time spent Google searching was also spent learning the jargon and high level stuff on IBM Websphere 6.1.5. Eventually I found this little gem, referenced itself on another site (but I never found it in the results of a Google search):

You should follow the steps in the link above. Looking back on this link I realize I only followed the steps till step 10.

Step 8 will scare you because the message you get at the end of running what they tell you to run is "Build Failed". This is OK. They are simply having you run step 8 to ensure you haven't missed any config fields. The correct order is actually step 9, THEN step 8. And in fact step 11 has you do step 8 again after you've done step 9. Clear as mud?

I have attached the relevent bits of configuration file you will need to edit when following the link above. I did find at one point that while testing my LDAP setup I had locked myself completely out of http://localhost:/ibm/console/ which contains a GUI tool to setup LDAP security. This concerned me at first but I following the first set of 9 steps here:

And I was able to login to the console without a password until I was sure LDAP was setup.

A WORD ON THE GUI CONFIGURATION TOOL: it's nice but there are more options, or at least I found more options manually editing the configuration files. It's a tedious process but I didn't trust the GUI tool as much as I trust running the ConfigEngine.bat file with parameters. This might be because I am more comfortable in a non-Windows environment or perhaps that the config GUI didn't work and the command line did. I guess it depends on which order you do them in!

If you have a "Build Successful" on step 9 you are pretty much set to go. If you notice a stack trace in your websphere logs after doing step 9 about an "AnonymousUser" use the IBM console to enable Administrative security in the "Secure administration, applications and infrastructure" sub-link of the Security section to the left.

If you have any questions feel free to post and I will attempt to answer them. This article I feel should be pages long as it took days to learn what is contained in only a few paragraphs here. Things such as the location of configuration files changed from the previous version.

Important Notes on Configuration file

  • standalone.ldap.ldapServerType=CUSTOM - if you use anything else Websphere may attempt to look for certain default accounts/properties for that particular LDAP server, with OpenLDAP I recommend CUSTOM

Good Luck!