v1.3.0 worked, but v1.3.2 gives error "automatic start_tls befored bind not successful"

[yexingqi]

new version 10.6 ldap can't work with error "automatic start_tls befored bind not successful"
but working well for 0.9.1 version

[yexingqi]

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/tornado/web.py", line 1704, in _execute
    result = await result
  File "/usr/local/lib/python3.8/dist-packages/jupyterhub/handlers/login.py", line 144, in post
    user = await self.login_user(data)
  File "/usr/local/lib/python3.8/dist-packages/jupyterhub/handlers/base.py", line 747, in login_user
    authenticated = await self.authenticate(data)
  File "/usr/local/lib/python3.8/dist-packages/jupyterhub/auth.py", line 459, in get_authenticated_user
    authenticated = await maybe_future(self.authenticate(handler, data))
  File "/usr/local/lib/python3.8/dist-packages/ldapauthenticator/ldapauthenticator.py", line 382, in authenticate
    conn = self.get_connection(userdn, password)
  File "/usr/local/lib/python3.8/dist-packages/ldapauthenticator/ldapauthenticator.py", line 314, in get_connection
    conn = ldap3.Connection(
  File "/usr/local/lib/python3.8/dist-packages/ldap3/core/connection.py", line 356, in __init__
    self._do_auto_bind()
  File "/usr/local/lib/python3.8/dist-packages/ldap3/core/connection.py", line 391, in _do_auto_bind
    raise LDAPStartTLSError(error)
ldap3.core.exceptions.LDAPStartTLSError: automatic start_tls befored bind not successful

[consideRatio]

This is not enough grounds to assume it is an issue of the JupyterHub Helm chart, so it may be caused by the the https://github.com/jupyterhub/ldapauthenticator which is installed in the hub pod, which has updated from version 1.3.0 to 1.3.2.

It could also be that the ldapauthenticator doesn't support the feature used in conjunction with a more modern JupyterHub version or similar.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[htsutsui]

The following patch may fix the issue.

--- a/ldapauthenticator/ldapauthenticator.py
+++ b/ldapauthenticator/ldapauthenticator.py
@@ -309,7 +309,7 @@ class LDAPAuthenticator(Authenticator):
             self.server_address, port=self.server_port, use_ssl=self.use_ssl
         )
         auto_bind = (
-            ldap3.AUTO_BIND_NO_TLS if self.use_ssl else ldap3.AUTO_BIND_TLS_BEFORE_BIND
+            ldap3.AUTO_BIND_NO_TLS if not self.use_ssl else ldap3.AUTO_BIND_TLS_BEFORE_BIND
         )
         conn = ldap3.Connection(
             server, user=userdn, password=password, auto_bind=auto_bind

[yexingqi]

The following patch may fix the issue.

--- a/ldapauthenticator/ldapauthenticator.py
+++ b/ldapauthenticator/ldapauthenticator.py
@@ -309,7 +309,7 @@ class LDAPAuthenticator(Authenticator):
             self.server_address, port=self.server_port, use_ssl=self.use_ssl
         )
         auto_bind = (
-            ldap3.AUTO_BIND_NO_TLS if self.use_ssl else ldap3.AUTO_BIND_TLS_BEFORE_BIND
+            ldap3.AUTO_BIND_NO_TLS if not self.use_ssl else ldap3.AUTO_BIND_TLS_BEFORE_BIND
         )
         conn = ldap3.Connection(
             server, user=userdn, password=password, auto_bind=auto_bind

Thanks so much for your reply , may I know how to change the JupyterHub file "config.yaml" since I using the configuration like this :

cat config.yaml

proxy:
  secretToken: "redacted-secret-string"
auth:
  type: ldap
  ldap:
    server:
      address: ldaps://xxxx.com
      port: 636
    dn:
      lookup: False
      search:
        filter: 'cn=uid'
        user: 'username'
        password: 'userpassword'
      templates:
        - 'uid={username},dc=opulan,dc=com'
      user:
        searchBase: 'ou=users,dc=opulan,dc=com'
        escape: False
        attribute: 'sAMAccountName'
        dnAttribute: 'cn'
    allowedGroups:
      - 'cn=test-group,ou=groups,dc=opulan,dc=com'

[manics]

@evenye Can you try setting use_ssl: True (the default is False)?

@1kastner would you mind taking a look at this?
This relates to #175 following a discussion on the ldap3 repo: cannatag/ldap3#855 (comment)

However I'm now wondering if that would break LDAP servers that don't support TLS?
If I understand correctly the current code:

• Uses AUTO_BIND_NO_TLS if use_ssl: True because the connection should already be TLS
• Uses AUTO_BIND_TLS_BEFORE_BIND if use_ssl: False which means it will initiate a TLS connection

Should this instead always be AUTO_BIND_NO_TLS?

[1kastner]

Well, in the config it says ldaps://xxxx.com so that use_ssl should be set to true, shouldn't it? The previous ldap3 version was much more forgiving. If the current version of ldapauthenticator is supposed to keep that behavior even though the underlying ldap3 library doesn't, maybe we should just build some try/except blocks (as ldap3 did previously) and don't expect the user to set use_ssl at all. Kind of a brute force approach to detect the config of the ldap server. Or we could just check for ldap:// versus ldaps:// and auto-select the right setting.

As far as I have understood the discussion at cannatag/ldap3#855 (comment) including some screening of the code of ldap3 and ldapauthenticator, the ldapauthenticator has never supported the full spectrum of ldap servers as we only use a subset of the configuration in ldaptauthenticaotr that is available in ldap3. One such decision was that there always MUST be SOME kind of encryption between the client and the server because we use ldap for exchanging usernames and passwords. Here, I am not sure whether this authenticator should support unsave behavior. Usually the encryption should be either START_TLS or TLS. The author of ldap3 explained why his suggestion for the ldapauthenticator is reasonable.

If somebody wants a more custom setup, they can setup their own authenticator, e.g. by using the default authenaticator and using something like https://wiki.debian.org/LDAP/PAM in the background. My idea of ldapauthenticator is that here only setups using encryption are supported and by that we guide the admins to apply best practices. As my contribution to this repo is very small, of course the main contributors should feel free to take any path of their liking. For my part, currently I focus more on OAuth2 instead of ldap so that I can accept any changes in the library.

PS: I am sure that the two constants are set correctly according to the discussion at cannatag/ldap3#855

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/ldap-not-working-ldapstarttlserror/11047/2