Ldapsync disables existing users

Hi,
this week I upgraded Seafile CE 7.1.4 to PE 7.1.4 and then 7.1.6.
I added ldapsync settings and triggered a manual sync with pro.py ldapsync, with the following settings:

# ccnet.conf
[ldap_sync] 
ACTIVATE_USER_WHEN_IMPORT = false

# seahub_settings.py
ACTIVATE_AFTER_FIRST_LOGIN = True

to let only active users consume licenses.

The process ended fine but I noticed that all (?) imported users were disabled.

So I asked all my users to first login from the web interface - this let the users to be re-activated and everything worked fine for a number of hours.

All of the sudden many users reported not being able to login anymore. The clients refused connection and asked to login again (as before - first login via web is required). They also tried to login via web but this time Seafile reported a problem of “The account is inactive”.

No way for the user to login again and re-activate the account themselves.

For one user I tried to activate the account manually, and it worked. But I don’t want to do that for all users.

I must report that one user reported the issue but he was able to login successfully and have his account active again.

So, why all of the sudden the accounts were disabled? Why the login does not enable them again?

Are there any problems calling the “manual” ldapsync from command line again, several times? How can I debug this?

I tried to lauch a second ldapsync manually and got:

[08/19/2020 16:44:34] [INFO] LDAP user sync result: add [0]user, update [0]user, deactive [0]user, add [0]role, update [0]role
[08/19/2020 16:44:34] [INFO] LDAP profile sync result: add [150]profile, update [0]profile, delete [0]profile
[08/19/2020 16:44:34] [INFO] LDAP dept sync result: add [0]dept, update [0]dept, delete [0]dept

However, I’m sure that those 150 users already were in the DB (imported the day before).

Is ldapsync reliable? I start to suspect it’s not.

Dear Andrian,
what happens if you execute the ldapsync again? Are there always 150 person added or does this happens only once??

The reason why I ask this is the following:
the ldapsync runs regular as described in the manual. The value is the “SYNC_INTERVAL”. Therefore it should be possible to run the ldapsync again and again without any issues.
https://download.seafile.com/published/seafile-manual/deploy_pro/using_ldap_pro.md#user-content-Active%20Directory

From your description it looks to me like every time you run ldapsync all users are deactivated. Can you just try to add DEACTIVE_USER_IF_NOTFOUND = False?

To answer your last question: “is ldapsync reliable?” As far as I can tell you ldapsync is reliable as soon as the right configuration is found. But it is definately a huge pain to get the configuration right. If anything is going wrong - like in your case - the debugging possibilities are very limited.

I am totally convinced that this problem could be fixed.
Best regards
Christoph

@Ivan_Andrian

I assume you already have some users in your system. Do you mean only newly imported users are deactivated (which is expected)? Or, all existing users are deactivated?

Can you share the full LDAP and LDAP_SYNC configuration in ccnet.conf?

Profiles correspond to “extra user information”, such as full name, uid, department name etc. They’re not synced in community edition. The LDAP sync feature in Pro edition creates them.

Hi Jonathan, thanks for the response.
Let me add some details then

We’re running Seafile Professional 7.1.6 now, upgraded from CE 7.1.4. We didn’t have ldapsync setup before.
In ccnet.conf:

[LDAP]
HOST = ldaps://XXXXXXXXXXXXXXXXXXXXXXXXXXXX
BASE = ou=ORG,ou=people,o=DOMAIN_ORG
LOGIN_ATTR = mail
USE_SSL = true
USER_DN = uid=XXXXXXXXXX,ou=server,o=DOMAIN_ORG
PASSWORD = XXXXXXXXXX
#FILTER = memberof=cn=ORG,ou=entities,o=DOMAIN_ORG

The FILTER line is now commented out because we found that some users were not included in that group/entity. We will work on this soon.

[LDAP_SYNC]
ENABLE_USER_SYNC = true
DEACTIVE_USER_IF_NOTFOUND = true
SYNC_INTERVAL = 60
USER_OBJECT_CLASS = inetOrgPerson
ENABLE_EXTRA_USER_INFO_SYNC = true
FIRST_NAME_ATTR = givenName
LAST_NAME_ATTR = sn
UID_ATTR = uid
ACTIVATE_USER_WHEN_IMPORT = false

And in seahub_settings.py:

ACTIVATE_AFTER_FIRST_LOGIN = True

Without the filter we have 678 users imported from LDAP, of which only 51 are active and 627 are inactive (plus other 35 “local only” users, active).

Well, after setting the sync up, I think I got all the users disabled by the manual ldapsync. This is reasonable, since the data was imported (and merged) for the very first time in the DB and all profiles were inactivated. I did not expect this but we can live with it.
So, I told all the users to login first via web, and they had their account activated again.

After some time (the day after), however, I started getting reports of accounts being deactivated even after the users had reactivated them by themselves. It looks like some following ldapsync. Brought to many (not all) users deactivated.
Even worse, they were not able to reactivate the account by themselves. The users got the message “Account Inactive” when trying to login via web.
As admin I have to go to the admin interface and activate them one by one - not comfortable I must say.

Is there any log of the scheduled ldapsync I could check? When I launch it manually at command line at least I got the list of profiles activated/disabled/etc.
But the issues were created during the automatic ldapsync, so I would like to check the list of accounts imported/modified at every run. Is this possible?

Without this, I found very hard to debug the issue.

Any other ideas?
Now Seafile PE is running with ldapsync disabled to avoid new deactivations of accounts. However, we need this functionality, also with the DEACTIVE_USER_IF_NOTFOUND = true feature on.

Just adding two infos:

  1. re ldapsync log (automatic), I found in seafevents.log lines like this:

[2020-08-18 18:27:26,246] [INFO] Starting ldap sync.
[2020-08-18 18:27:26,246] [INFO] virus scan is disabled

However, no details of what was sync’d etc.

  1. re UID_ATTR = uid I must add that in our LDAP every user may have multiple UIDs. Don’t know if this could bring any problems in Seafile’s DB or not.

Hi @Ivan_Andrian

Setting this options tells ladp sync to deactivate users when they’re not found in LDAP server, based on various other options. One such option is the FILTER, other is USER_OBJECT_CLASS. Perhaps when you manually run ldap sync for the first time, you misconfigured the FILTER or USER_OBJECT_CLASS option. So all users are deactivated. There should be detailed log messages when you run it manually.

After sometime you may updated the configuration to the correct one, but didn’t restart seafile server. The new options only takes effect after restart.

Another possibility is that, you did restart the seafile server after you correct the configuration. But ldap sync won’t automatically activate a deactivated user when he/she was deactivated before and appears in LDAP server again. This is to avoid unintended re-activation of manually deactivated users.

Are you running a seafile cluster? If so, the log messages are available in background-tasks.log.

Thank you Jonathan for your contribution.
However, no, the ldapsync was correctly importing the profiles AFAIK. USER_OBJECT_CLASS and FILTER were OK from the start. Just, I did not expect the users to be deactivated - which was solved instructing the users to do the first login on the web interface.
Unfortunately, after a while some users (that re-enabled their account with the online login) started complaining to have been de-activated again, and that the web login was not fixing this issue.
All these users, AFAIK, were using SeaDrive or Seafile sync client mainly and were “kicked off” when their token expired (my guess) - this means, not immediately, after one or two days of the “first deactivation”.

I suspect the ldap sync is “deactivating” some users sometimes and then, as you say, it cannot re-activate them a second time by design. However, this now only is a guess of mine. I’d like to have some log messages to better debug.
I’m not running a cluster so I suspect I cannot access the background-tasks.log file. Is it possible to have that file generated also for a single server?
Otherwise, I’d like to be able to manually trigger the ldapsync with pro.py ldapsync which gives out the details in DEBUG mode. But this is not possible unless the sync is enabled, which would trigger the automatic background sync anyway.

I see two workarounds:

  1. start seafile with ldapsync disabled, then change the config file to enable it (without restarting seafile) and play with pro.py ldapsync: good for single testing, not for “production”
  2. create a modified pro/python/seafevents/ldap_syncer/run_ldap_sync.py (and maybe also pro.py) without the check of ldapsync being enabled or not:
 if not settings.enable_sync():
     logging.debug('Both user and group sync are disabled, stop ldap 

sync.')
return

and trigger the manual ldapsync which would work even with the setting set to disabled.

Do you maybe have further suggestions for this debugging task?

We’ll test in our environment. Will get back to you soon.

Hi @Ivan_Andrian

We tested in our own environment. With below configurations:

# ccnet.conf
[LDAP_SYNC]
ENABLE_USER_SYNC = true
DEACTIVE_USER_IF_NOTFOUND = true
SYNC_INTERVAL = 1
USER_OBJECT_CLASS = person
ENABLE_EXTRA_USER_INFO_SYNC = true
FIRST_NAME_ATTR = givenName
LAST_NAME_ATTR = sn
UID_ATTR = sAMAccountName
ACTIVATE_USER_WHEN_IMPORT = false

# seahub_settings.py

ACTIVATE_AFTER_FIRST_LOGIN = True

We found:

  • Previously imported LDAP users are NOT deactivated.
  • LDAP sync logs are printed into seafevents.log

One thing to note is that we tested with AD, so the USER_OBJECT_CLASS is ‘person’ instead of ‘inetOrgPerson’.

So we’re not sure why you have these two issues. One way to test in your environment is to copy the database from your production system, then test LDAP sync with the copy. Keep the log messages and send them here, or PM to me.

Thanks Jonathan for the test.
I will do more tests soon and send you the outcome.
However, it’s not clear how to improve the logging in seafevents.log (including the list of accounts added/modified/deactivated) - see my previous post here.