auth LDAP with TLS fails after upgrade

runout-at commented 1 year ago

Before creating a ticket, please consider if this should fit the discussion forum better.

Environment

ejabberd version: 23.01-1
Erlang version: 13.1.5
OS: Linux (Debian Bookworm)
Installed from: distro package (Upgrade from bullseye/backports)

Config, relevant part

auth_method: [ldap]
ldap_servers:
  -<IP of LDAP server>
ldap_port: 636
ldap_encrypt: tls
ldap_tls_verify: false
ldap_base: "ou=users,dc=<DOMAIN>"
ldap_uids:
  mail: "%u@<domain.tld>"

Errors from error.log/ejabberd.log

2023-07-13 15:59:22.756781+02:00 [error] <0.495.0>@eldap:connect_bind/1:1092
 LDAP connection to <IP of LDAP server>:636 failed: TLS client:
 In state wait_cert_cr at ssl_handshake.erl:363 generated CLIENT ALERT:
 Fatal - Internal Error
 {unexpected_error,{case_clause,asn1_NOVALUE}}
...

Bug description

Until the bullseye->bookworm upgrade everything was working fine.

After upgrading the ejabberd server the LDAP connection is not working due to SSL problems. This does not effect unencrypted connections (Port 389).

I tried upgrading the LDAP server too but without luck. The same issue persists.

I found some reports of other software which seems to be broken after an erl/otp upgrade - this might be the case here too.

badlop commented 12 months ago

ejabberd uses ~~eldap (a LDAP client included in Erlang/OTP)~~ to connect to the LDAP server.

Update: ejabberd uses an eldap client included with ejabberd source code, not Erlang/OTP's eldap library.

If there is any incompatibility between specific versions of that client and some server, it would be great to know which version ranges are affected. Even if it weren't possible to solve the incompatibility, at least it would help administrators install a more suitable version.

I tried LDAP with tls encryption in my test machine:

Erlang 25.3.2 compiled from source code
ejabberd git master
slapd 2.4.57+dfsg-1~bpo10+1 (running the container osixia/openldap:latest)

with this configuration in ejabberd:

auth_method: [ldap]
ldap_servers:
- "ldap"
ldap_port: 636
ldap_encrypt: tls
##ldap_tls_verify: false
ldap_rootdn: "cn=admin,dc=example"
ldap_password: "admin"
ldap_base: "dc=example"
ldap_uids:
- "cn"

and it worked correctly: ejabberd starts, I can login correctly with a client to a LDAP account...

Maybe I am using safe versions, and you found some incompatible ones?

Erlang version: 13.1.5

You mean erts 13.1.5, and looking in the homepage, it was included in Erlang/OTP 25.2.3

To try to reproduce the problem, I later tried with:

Erlang/OTP 25.2.3 compiled from source code
ejabberd 23.01 compiled from source code
the same OpenLDAP container as before

and LDAP with TLS worked correctly: ejabberd starts and I can login to the LDAP accounts.

Maybe it is relevant what LDAP server version you are using. Can you make a small test, to see of you can connect to the same LDAP server version I used?

I have this docker-compose.yml file and start it with "docker-compose up":

```yaml version: '3.7' services: ldap: container_name: ldap image: osixia/openldap:latest environment: LDAP_ADMIN_PASSWORD: admin LDAP_BASE_DN: dc=example LDAP_DOMAIN: example LDAP_TLS_VERIFY_CLIENT: try command: --copy-service ports: - 389:389 - 636:636 ```

Does your ejabberd connect correctly to this LDAP server using TLS?

runout-at commented 12 months ago

Hi badlop!

Thanks for investigating!

My slapd versions are 2.4.57+dfsg-3+deb11u1 (currently used, bullseye-security) and 2.5.13+dfsg-5 (I did test on bookworm too).

Other clients have no problem with those versions. (samba, php)

I have no testing environment at the moment where I could play with docker (and I have no docker experience).

The difference in your/mine config is ldap_tls_verify: false vs ## ldap_tls_verify: false. (LDAP is running on an internal Network with a self signed certificate)
My LDAP server does not need a login (but this works without TLS).
Same error and log message when I provide login (rootdn/passwd).

badlop commented 12 months ago

I correct myself: the eldap library used by ejabberd is a custom one included with ejabberd source code, not the one included with Erlang. By the way, it supports LDAPS on port 636, but not STARTTLS on port 389.

ldap_tls_verify: false

This is the default value. Not setting the option means the option is set false.

By the way, it's mentioned in https://wiki.debian.org/LDAP/OpenLDAPSetup#Enabling_LDAPS_on_port_636 that:

By default, slapd only supports StartTLS on the standard LDAP port 389. Some legacy LDAP clients do not support the StartTLS operation, but are able to use LDAPS (LDAP over SSL) on port 636.

In any case, I am not expert in LDAP at all. This invetigation may advance when it receives further details about working/nonworking versions, some reproduction method, or some expert takes a look.

runout-at commented 9 months ago

Sorry for the delay. I was on another project for a while.

Finally after upgrading openldap from 2.4 to 2.5 did solve the problem somehow. I can*t say what the problem was. It seems during upgrades from debian bullseye to bookworm I did run into a problematic mix of versions/settings.

@badlop: Thx for looking into this.

processone / ejabberd