[Bug]: Ldap connection problems since v32

[zenlord]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Hi, Following other bug reports (a.o. #56164 which just got closed), I believe the current Nextcloud behavior should be treated as a bug:

1. The occ option "ldap:ldapTLS" should be named "ldap:ldapStartTLS"
2. The value of this occ option should not matter if the "ldap:ldapHost" option starts with "ldaps://" OR if the "ldap:ldapPort" option equals "636"
3. If # 2 above is not taken care off, then in any case, a connection error with the LDAP server should not result in the login-page being replaced with an HTTP 500 Server Error - this error should be caught and should probably cause a warning to be shown on the login-screen that "the ldap server is unavailable and logging in may not be possible." (or something similar)
4. The Nextcloud error log messages related to this error state:
   1. "Lost connection to LDAP server"
   2. "LDAPS (already using secure connection) and TLS do not work together. Switched off TLS."
      -> Similarly to # 1 above, the message should reference StartTLS and not TLS
      -> Additionally, I find the messages confusing: it looks like, while the first message is a lost connection, the second message confirms that switching of (Start)TLS is solving the issue.

Additionally the occ option "ldap:TurnOffCertCheck" suddenly started working as of v32, which is a good thing, but it doesn't hurt to document that prior to v32 it was possible to connect to ldap servers of which the certificate had expired, even without setting this option. To anyone looking for this: if you see "Connection to LDAP server lost" in the Nextcloud logs, then either check the validity of your TLS certificates or simply (temporarily) switch on the abovementioned option using occ.

Steps to reproduce

1. Configure an LDAP connection in Nextcloud using LDAPS and at the same time set option "ldap:ldapTLS" to value 1
2. Visit your Nextcloud server to be greeted with an HTTP 500 Internal Server error
3. Open your Nextcloud server log and find the 2 messages

Expected behavior

1. The option "ldap:ldapTLS" should not be used if the option "ldap:ldapHost" starts with "ldaps" or if the option "ldap:ldapPort" equals 636
2. A problem with the connection to the LDAP server should not result in an HTTP 500 Internal Server error, as instances may have configured several user backends (and in any case it is impossible to log in using the admin account)

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

The relevant configuration options are not in occ:config, but in occ:ldap and are already mentioned above.

List of activated Apps

Not relevant.

Nextcloud Signing status

Not relevant.

Nextcloud Logs

Not relevant. Bug is entirely documented in ldap:config.

Additional info

I manage two Nextcloud servers and encountered slightly different behavior on both as there was a difference in configuration:

1. PHP 8.3, ldap:ldapTLS=1 where connection is made over ldaps: Nextcloud login page replaced with Apache HTTP 500 error page
2. PHP 8.2 ldap:turnOffCertCheck where connection is made over ldaps and certificates had been expired since 2024: the Nextcloud login page is shown and upon login, Nextcloud is showing an internal server error.

I believe the behavior of server 2 should be used in the situation where server 1 was in before I corrected the configuration: Nextcloud should not panic and control the error instead of falling back to the webserver.

[zenlord]

Additional info: On the above mentioned 'server 2' I thought the problem had gone, but I encountered again an HTTP 500 error while opening the 'Accounts' page, upon which I opened the LDAP configuration panel and noticed a red notice "Configuration not OK". I then clicked the 'detect port' button and the notice became green with text "Configuration OK'.
Surprisingly, when I opened the CLI and showed my ldap config, the value of option "ldap:ldapTLS" was no longer '0', but '' (empty). So it looks like setting it to '0' has allowed me to log in into my instance, but to regain full functionality the value had to be set to '' (empty).

[susnux]

cc @come-nc