Rocket.chat: [BUG] Deactivated users gets activated after Background LDAP Sync

[ankar84]

Description:

Our users are imported to Rocket.Chat from our corporate LDAP server.
When user leave organization his LDAP account is disabled and script like this is deactivating Rocket.Chat account for that user.
After upgrade to 3.1.1 I see, that deactivated users in past are activated now. It's a security bug.
I think that such activating of deactivated users is a result of Background LDAP Sync (scheduled one a day for our deployment)

Steps to reproduce:

1. Deactivate user manualy or by API with such script
2. Wait Background LDAP Sync finished
3. Check deactivated user status

Expected behavior:

Disabled in LDAP accounts should remain deactivated while Background LDAP Sync

Actual behavior:

All deactivated users become activated after Background LDAP Sync

Server Setup Information:

• Version of Rocket.Chat Server: 3.1.1
• Operating System: CentOS7
• Deployment Method: docker
• Number of Running Instances: 12
• DB Replicaset Oplog: Enabled
• NodeJS Version: v12.16.1
• MongoDB Version: 4.0.17

[bbrauns]

Thank you for reporting, we have exactly the same problem. A custom bash script is triggered by our identity management system when a user has left the company. The script deactivates the rocket.chat user account but the next day he/she is reactivated...So at the moment it is not possible to completely deny access for old or abusive user accounts besides deletion.

[ankar84]

So at the moment it is not possible to completely deny access for old or abusive user accounts besides deletion.

Definitely!
But for us it's a bit not so serious. We use KeyCloack to authenticate users.
Both LDAP users import and KeyCloack are limited by one LDAP security group.
After user disabled in LDAP, that user also removed from security group and KeyClock authentication will not be successful.
Anyway it still important security issue.

[magikmw]

I've just encountered this issue after upgrading to 3.2.2 from 3.0.7. This is really bad, especially since deactivated accounts will become reactivated again after the next sync.
Also related https://github.com/RocketChat/Rocket.Chat/issues/7235 since if the LDAP/AD account is disabled it should also deactivate RC account.
How did this issue go 5 days without triage? Sorry about that. Uncalled for.

Edit:

• Also, rocket now syncs and reactivates users that not only are not active in LDAP/AD, but also out of the OU and group the filter looks for in LDAP users

[magikmw]

I did some digging, and I'm fairly sure this PR introduced the bug https://github.com/RocketChat/Rocket.Chat/pull/16671

Either of these seem like the main culprit since the rest of the PR is just moving code around:
https://github.com/RocketChat/Rocket.Chat/blob/3a9523a2053444594631eaec1d71659c64bd6c69/app/ldap/server/ldap.js#L380
https://github.com/RocketChat/Rocket.Chat/blob/3a9523a2053444594631eaec1d71659c64bd6c69/app/ldap/server/ldap.js#L459
This one seems to be the most likely one:
https://github.com/RocketChat/Rocket.Chat/blob/3a9523a2053444594631eaec1d71659c64bd6c69/app/ldap/server/sync.js#L568

I'm almost confident this bug was present before, as there doesn't seem to be any check for filters or ldap status of the user in sync(). It's just that this PR fixed the existent user sync not working, revealing this bug here.

I'd try a PR, but I'm not feeling up to the task with my JS skills and uncertainty of the codebase.

Ping @rodrigok @sampaiodiego

[mdanovz]

Yeah. We have the same bug. After upgrading server from 2.4.1 to 3.2.1, all deactivated users were activated.
And on their mobiles push notifications began to come.
After half a year of chat irrelevance.

[rodrigok]

Thanks for the report, we are investigating this.

[ankar84]

• Also, rocket now syncs and reactivates users that not only are not active in LDAP/AD, but also out of the OU and group the filter looks for in LDAP users

That is really bad for us.

[GJKrupa]

I have the opposite problem. We have a bot user that's enabled in AD but keeps getting deactivated every time a background sync is run. It's in a sub-OU under the user root. We're running 3.3.0.