dexidp / dex

OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectors
https://dexidp.io
Apache License 2.0
9.5k stars 1.71k forks source link

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

Closed MoeBensu closed 3 months ago

MoeBensu commented 3 months ago

Preflight Checklist

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:

Screenshot 2024-08-04 at 23 10 51

Additional Information

No response

Configuration

No response

Logs

Turning on the debug  didn't give more information.
nemunaire commented 3 months ago

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 commented 3 months ago

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

nabokihms commented 3 months ago

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 commented 3 months ago

Ok, I found the problem, and it is with the scheme. Funny one. The fix will be in v2.41.1 https://github.com/go-ldap/ldap/issues/523#issuecomment-2269844629