Configuring IBM P8 to use LDAP over SSL with Active Directory

0
votes

I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).

We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).

Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.

The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating

An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636

Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...

I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?

Thanks in advance for any-and-all assistance.

1
wcfsslactive-directorywebspherecontent-platform-engine
Since you already have the signer certificate of Active Directory Server added to Application Servers trust store, you might want to check that the application server has "Dynamically update the run time when SSL configuration changes occur" checked. It is possible that the added trust is not being used yet. If possible, you can try restarting your application server which will cause the updated trust to be used for sure. – M. Tamboli
The error states that the connection to the AD server is failing. What happens if you try telnet ad1.domain.com 636 from the CPE server? – Haxiel
You do not need filenet to use SSL for LDAP in order to use separate .net applications via WCF. You must use SSL for the communication between .Net apps and filenet, but the LDAP connection to filenet can remain the same. – Christopher Powell
Christopher Powell - I would love for this to be true and will try it straight away! That said, the only reason I went to the trouble of configuring Active Directory for SSL and then attempted to make the connection between IBM Content Platform Engine SSL as well was because IBM's docs suggested I had to (from IBM doc entitled "Enabling SSL for Content Platform Engine - Steps 1-6"). – SirruX

1 Answers

0
votes

WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well

This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.

Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere Check WebSphere's Keystores to ensure that the AD's key is contained. Follow @M.Tamboli's advice and restart WebSphere. Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.

I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.