failed to connect: LDAP Result Code 200 \"Network Error\": dial tcp :389: connect: connection refused

[MoeBensu]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.
• I am not looking for support or already pursued the available support channels without success.

Version

v2.40.0 - v2.41.0 (master)

Storage Type

Postgres

Installation Type

Official container image

Expected Behavior

The LDAP connector should be able to connect to the LDAP in a cluster environment.

Actual Behavior

I use currently the latest image from master (last time built was last Friday) which includes many updates and changes as a preparation for the next release. I tried the image in a cluster setup and I ran into this issue:

failed to connect: LDAP Result Code 200 \"Network Error\": dial tcp :389: connect: connection refused

After a closer look, it seems that the connector can't dial up the LDAP server.

An example of dex config:

...
connectors:
- type: ldap
  name: LDAP
  id: ldap
  config:
      host: ldap.core
      insecureNoSSL: true
      insecureSkipVerify: false
...

The LDAP server is pingable from within the dex container.

I first suspected that it could have to do with replacing Dial with DialURL. However, the documentation of the new method doesn't give me a clear hint of anything causing this behavior. I couldn't find something that could be the reason behind it in the release notes of other updated dependcies like gomplate.

When switching to older dex versions, i.e. v2.38.0, the dex was then able to communicate with the LDAP!!

In short, it seems that the dex is not able to communicate with LDAP in a cluster setup in the first place. Are there new changes in the dex config that I need to consider in a cluster setup?

Steps To Reproduce

I also tried to reproduce it locally but I only got the same error when I turned off LDAP. Sending any request to dex even with wrong credentials would throw this:

Additional Information

No response

Configuration

No response

Logs

Turning on the debug  didn't give more information.

[nemunaire]

I have the same problem with the Docker container since the update to v2.41.0.

In my case, the error message is:

Login error: failed to connect: LDAP Result Code 200 "Network Error": dial tcp :636: connect: connection refused

(I don't have the option insecureNoSSL: true)

Regardless of the host setting, the error remains the same. I tried several host/port combinations, but this exact error message persists.

I rolled back to container tag v2.40.0 and it works well.

[justusbunsi]

Same issue for me. LDAPS with port 636, no insecure... option enabled. Rollback to 2.40.0 worked for mee, too.

[nabokihms]

It seems our integrations tests do not cover different ssl option combinations… I will try to investigate, thank you all for reporting.

For now, I’m thinking about returning deprecated methods.

[nabokihms]

Ok, I found the problem, and it is with the scheme. Funny one. The fix will be in v2.41.1
go-ldap/ldap#523 (comment)