↓ Skip to main content

Troubleshooting IBM WebSphere LDAP Security

·407 words·2 mins
IBM Software WebSphere Security Ldap Sdi Ad Ldaps Hcl Hclcnx

Most of the LDAP connections from IBM WebSphere Application Server are configured with TLS. So you need to have the root certificate in the WebSphere truststore to connect.

In the past I had several issues where MS Active Directory certificates for LDAPS are only valid for one year. They were automatically recreated on the AD side, and the certificate is not using the domain root certificate but a self-signed one.

Like https://help.claritysecurity.com/docs/enable-ldaps-on-an-ad-domain-controller, the instructions create a certificate template.

I couldn’t reproduce in my demo servers the issue that some customers have with only self-signed certificates for AD LDAPS which are only valid for one year, but I tested certificates with and without templates.

So the certificate which is used for LDAPS after just installing the Certificate Authority looks like this:

20250409-212138.png

The certificate created with the described LDAPS Template (inherited from Kerberos):

20250409-212041.png

From my point of view, the certificate with the template has no server name in the certificate, while the one without touching templates looks promising and works as expected.

You need to reimport the certificate every 11-12 months to have a trusted connection.

There is one setting in WebSphere which can help you, ensuring that the filebased user (for example wasadmin) is always able to login.

Allow operations if some of the repositories are down
#

This option is disabled by default and you can enable it in ISC (https://websphere-fqdn:9043/ibm/console) or wsadmin.sh.

  • ISC

    • Open Security > Global Security > Federated Repositories (Configure)
    • Enable Allow operations if some of the repositories are down
      20250409-174040.png

  • wsadmin.sh

cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
./wsadmin.sh -lang jython
AdminTask.updateIdMgrRealm('[-name defaultWIMFileBasedRealm -allowOperationIfReposDown true]')
AdminConfig.save()

To activate the setting you need to restart the Deployment Manager.

Now at least the file-based WebSphere admin user (e.g. wasadmin) can always login, even when the LDAP connection is down or fails because of missing certificates.

Disable Security to update truststore
#

If it is already too late to set this option, you can disable the WebSphere security with wsadmin:

cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
./wsadmin.sh -lang jython -conntype NONE
securityoff()
AdminConfig.save()

Restart the Deployment Manager and open the login page on https://dmgr-fqdn:9043/ibm/console - it will just ask for a username.

20250409-175218.png

Login with any username.

Now you can change any setting.

To finish the thoughts from above, import the new LDAP certificate for example.

SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Retrieve from port

20250409-213704.png

In the end, enable application security again:

20250409-175422.png

and restart the Deployment Manager.

Christoph Stoettner
Author
Christoph Stoettner
I work at Vegard IT GmbH as a senior consultant, focusing on collaboration software, Kubernetes, security, and automation. I primarily work with HCL Connections, WebSphere Application Server, Kubernetes, Ansible, Terraform, and Linux. My daily work occasionally leads to technical talks and blog articles, which I share here more or less regularly.
Matrix

Related

Security Directory Integrator connecting to Active Directory LDAPS

·769 words·4 mins
HCL Connections Hcl Hclconnections Hclcnx Sdi Ad Tdi Ldaps
I had one Connections’ environment that I wanted to switch from OpenLDAP to Active Directory LDAP. The old OpenLDAP environment used LDAPS to connect, and so I assumed that the change was done quickly. The first step was to make a copy of the tdisol folder I used for OpenLDAP and start changing the configuration files for the new LDAP server.