Introduction

Hi, I am Kouki, a system engineer from WESEEK, Inc. in Japan.

We, WESEEK, Inc., offer the internal Wiki service called GROWI.cloud that supports Markdown and provides powerful functions.

Our blog shares insights on our online wiki service “GROWI.cloud” and emerging IT knowledge.

If you like the content, please feel free to follow us on DEV or go to GROWI.cloud to learn more about us!✨

Today’s Topic

In this post, I would like to share some LDAP troubles I encountered when updating WordPress and how I dealt with them. I think it is interesting to share so I made a post to summarize it.

Furthermore, if you are interested in the process of how I targeted and solved the problem, I would appreciate it if you could also check the Log Analysis Section.

The Environment

First, I want to talk a little about the environment in which trouble was encountered.

This issue happened when I installed a plugin called LDAP Login for Intranet Sites provided by miniOrange within WordPress.

In fact, this issue would happen not only to the above plugins, if you have code that uses PHP’s LDAP extension, you would encounter this trouble too.

The Issue

• Updated bitnami/wordpress docker image from 5.9.3 to 6.0.0
• While updating, I had an issue where I could not connect to OpenLDAP from WordPress.
• The logs were showing “Can’t contact LDAP server”.

Failure Analysis and Solution

The file/etc/ldap/ldap.conf, which was present in thebitnami/wordpress 5.9.3, was deleted in 6.0.0. As a result, the PHP LDAP extension could not find the file path for “TLS_CACERT” and failed to validate the certificate, resulting in an error during the TLS connection.

As a workaround, by specifying TLS_CACERT=/etc/ssl/certs/ca-certificates.crt an environment variable when starting the WordPress container, the PHP LDAP extension could connect to the LDAP server.

/etc/ldap/ldap.conf does not exist in the 5.9.3 image as of 2022/09/08. (Aware that the internal bitnami/wordpress 5.9.3 custom image also included in it)

The 5.9.2 image is confirmed with the existence of /etc/ldap/ldap.conf. If you want to check it out, you can try it with 5.9.2 by yourself.

Log Analysis

From here, I will dig deep into the log analysis that I debugged.

In the beginning, I had no idea why this issue happened.

First, I tried to connect to the LDAP server with openssl command and there seemed no problem. (be aware the domain is replaced with example.com here)

When there is a transmission from the WordPress plugin, the logs on the LDAP server side are as follows:

Since only connection lost was logged, all I could tell was that there must be some trouble with the connection.

This is where the analysis stalled for a time. However, I soon tried to modify the source code LDAP Login for Intranet Sites and started debugging work

I put the following code in the file /opt/bitnami/wordpress/wp-content/plugins/ldap-login-for-intranet-sites/class-mo-ldap-config.php and checked the container logs.

This lets me confirm that the ldap_bind function outputs the message Can't contact LDAP server.

My analysis stalled again in this place. After taking some time, I found out that there is a function called ldap_set_option and I planted that code

Then the following log is output.

This is where I realized that there seems to be a problem with the certificate.

So I added the code putenv('LDAPTLS_REQCERT=never') to the plugin and confirmed that the connection works (aware this is just a temporary solution).

However, the workaround LDAPTLS_REQCERT=never makes little sense and it also has a security problem.

This is when another member of my team found this article.

With this, I realized that the /etc/ldap/ldap.conf file exists for the bitnami/wordpress 5.9.3 version but does not for the 6.0.0 version.

Then, I chose to specify TLS_CACERT=/etc/ssl/certs/ca-certificates.crt in the environment variable when activating the image and I deleted the LDAPTLS_REQCERT=never above.

In the end, I solved the issue with TLS_CACERT.

Summary

The troubleshooting method that I introduced today can be applied to other docker images as well.

NextCloud, for example, is also built with PHP. Thus, if you are experiencing this problem, you may want to take the same steps to solve this problem.

About Us💡

In addition, we want to introduce a little more about GROWI, an open software developed by WESEEK, Inc.

GROWI is a wiki service with features-rich support for efficient information storage within the company. It also boasts high security and various authentication methods are available to simplify authentication management, including LDAP/OAuth/SAML.

GROWI originated in Japan and GROWI OSS is FREE for anyone to download and use in English.

For more information, go to GROWI.org to learn more about us.