LDAP Login broken by

abaer · November 27, 2024, 3:53pm

Hi,

can someone from Seatable explain the following config options - I couldn’t find any information, and randomly applied, they broke my LDAP login

DISABLE_ADDRESSBOOK_V1 = False
ENABLE_ADDRESSBOOK_V2 = False

This is what happend: When upgrading to 5.x, I thought it might be a good time to complete my 3.x config files with the options from subsequent releases, including the two from above. So I created a fresh install, and copied over the missing options and their default values to my running 4.x system before upgrading.

The default values (both options set to True) broke my LDAP connection. I found an old forum post regarding installations with departments (which we don’t use afaik), which fixed another problem with setting both values to False.

I’d like to understand what happened here, and how those options work, in order to verify that nothing broke in our system. For example, is it valid to enable both versions - and why?

Also, is there a convenient way to debug authentication, especially LDAP? Couldn’t figure out were I can find log entries about unsuccessful LDAP logins even

daniel.pan · November 28, 2024, 6:59am

These two options should not related to LDAP login. They are independent features.

If LDAP is broken, how is it broken? Can you check dtable_web.log for corresponding error?

abaer · November 28, 2024, 8:28am

Hi,

thanks for looking at this straight away. LDAP didn’t work any more when both options were set to “True”. Part of my question was were LDAP errors should actually appear - you answered this implicictly by asking for dtable_web.log.

Sorry if the following post got quite long. While trying to answer your questions, things got weirder and weirder by the minute

That’s where the tricky part starts - I’m trying to figure out what to look for in the logs. Loglevel=DEBUG is set for seatable BTW. It used to be set to WARN for the last week, but now I’m referring to DEBUG mode, which I set after I discovered the problem yesterday.

Now that LDAP is working, I can provoke LDAP errors, and see them in the log. The first one is an unknown user, for the second one I mistyped the password. So far, so good.

2024-11-28 08:19:38 [ERROR] seahub.base.accounts[880] - ldap user ***secret*** not found.
2024-11-28 08:20:33 [ERROR] seahub.base.accounts[911] - ldap user bind failed. {'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': [], 'info': '80090308: LdapErr: DSID-0C09050E, comment: AcceptSecurityContext error, data 52e, v4f7c'}

However, I can’t find any messages or even errors in previous logs referring to “ldap” or even “accounts”. Seems that the LDAP login is not really talkative regarding the logs. In order to find out what is actually logged in the non-working state, I reset my configuration to Adressbook True/True on our test server to replicate the problem.

Very bizzare: LDAP is even working with True/True now! That’s the difficulty with replicating errors . But I still need to know what was the reason for this was, because I need to update our production server, without running into the same problem.

First a straight question: What “Addressbook_v1/2” configuration is actually normal for v5.19? True/True, False/False or any other combination?

Maybe the following observations help you to determine the cause of the initial problem? In case you wonder, I must stress the fact that the LDAP server was running and reachable all the time - a parallel 4.4.9 installation on the same machine was working all the time.

This is the reconstruction of what happened since yesterday:

When I discovered yesterday that LDAP was not working, the configuration was True/True
While checking the Seatable LDAP documentation, I noted that LDAP_USER_UNIQUE_ID doesn’t appear in the documentation any more, so I disabled it (see below). No change regarding LDAP, to I left it commented out.
Then I switched the Addressbook configuration to False/False, and LDAP worked again. That’s when I wrote the ticket.
Today, I just switched back to True/True, and it still works. I’m totally confused.

The only explanation I can imagine is that still having LDAP_USER_UNIQUE_ID configured during the v4.4.9 to 5.0.8 update somehow spoiled some transition from an old version of the address book to a new one??? But that’s just wild guessing - any help appreciated.

As I said: In order to update our production server, I just need to know a) what the intended state is for LDAP_USER_UNIQUE_ID and DIS/ENABLE_ADDRESSBOOK_V1/2, and b) how to avoid any problems when upgrading.

Thanks A LOT!

Arndt

BTW, here is my LDAP config from dtable_web_settings.py against an Active Directory LDAP.

ENABLE_LDAP = True
LDAP_PROVIDER = 'ldap'
LDAP_SERVER_URL = 'ldap://my-ldap-server:389'
LDAP_BASE_DN = 'dc=subdomain,dc=domain,dc=de'
LDAP_ADMIN_DN = 'F*******'
LDAP_ADMIN_PASSWORD = 'g********'
# Is the following LDAP_USER_UNIQUE_ID still valid?
# Couldn't find it in the current documentation, but also didn't make any difference regarding the LDAP error
LDAP_USER_UNIQUE_ID = 'objectGUID'
LDAP_LOGIN_ATTR = 'sAMAccountName'
LDAP_SYNC_GROUP = False
LDAP_USER_FIRST_NAME_ATTR = 'givenName'
LDAP_USER_LAST_NAME_ATTR = 'sn'
LDAP_USER_NAME_REVERSE = False
LDAP_CONTACT_EMAIL_ATTR = 'mail'

daniel.pan · November 28, 2024, 8:58am

ENABLE_ADDRESSBOOK_V1/2 is not related to LDAP in theory. You can leave it to any value. Normally, you should use:

DISABLE_ADDRESSBOOK_V1 = True
ENABLE_ADDRESSBOOK_V2 = True

Regarding LDAP:

In version 5.1, we remove the use of LDAP_USER_UNIQUE_ID, instead we use LDAP_LOGIN_ATTR directly to map a LDAP user to SeaTable user in social_auth_user table (in dtable_db).

For newly installed instances, the LDAP_USER_UNIQUE_ID setting should not be set in the configuration file.

For old instances, LDAP_USER_UNIQUE_ID and LDAP_LOGIN_ATTR should be unchanged.

What changed under the hood

For old instances:

For old users, when a user login, LDAP_USER_UNIQUE_ID is read from LDAP after searching the user, then it is used find the old user and a new LDAP_LOGIN_ATTR to username map will be created in social_auth_user table. (username is a random ID like xxxxxxxx@auth.local to identify a user in SeaTable)
For new users, only LDAP_LOGIN_ATTR to username map will be created in social_auth_user map table.

In the future, when all the map are updated for old users, LDAP_USER_UNIQUE_ID can be removed.

Regarding your error

To help you to resolve the problem, I suggest you first identify the exact error.

2024-11-28 08:19:38 [ERROR] seahub.base.accounts[880] - ldap user ***secret*** not found.

This error means the user cannot be found in LDAP server.

2024-11-28 08:20:33 [ERROR] seahub.base.accounts[911] - ldap user bind failed. {'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': [], 'info': '80090308: LdapErr: DSID-0C09050E, comment: AcceptSecurityContext error, data 52e, v4f7c'}

This should be another login attempt. This time, the user can be found, but the password is not correct.

Note, the two errors above are not related to the setting of LDAP_USER_UNIQUE_ID.

abaer · November 28, 2024, 10:09am

Hi,

thanks for the explanation! However, the log output does not help: It comes from a time (now) when the error was already fixed, after the sequence of actions described before (1-4).

While the problem persisted, I could not find any LDAP-related log output. Possible reasons:

Log level was at first WARN. However, I switched to DEBUG straight at the beginning and tried LDAP again with out success, so there should have been something.
Or I didn’t know what to look for in the log file. Grepped for “ldap” and “account” - nothing appeared while the error still persisted.
Or the LDAP login does not log the specific error I encountered.

Anyway: I guess I’m just wasting your time if I can’t recreate the error. I’ll see whether I still have a working backup of a 5.0.8 or 4.4.9 system, or I have to bite the bullet, and try it on our production system.

Regards,

Arndt