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'