Rocket.chat: Active Directory users are not handled as expected

[chgarling]

Description:

The user handling with Active Directory accounts works not as exepected. If a user was disabled in or removed from the Active Directory, he can still log on to Rocket.Chat. A (manual) LDAP sync does not change anything.

A password change of an Active directory user results in two available logins. The user can log on to Rocket.Chat with the current and the last password. If the user was disabled in the Active Directory he can still log on with his last password (the one before the password change), but the current one does not work anymore.

Server Setup Information:

• Version of Rocket.Chat Server: 0.60.4
• Operating System: Debian 9.3
• Deployment Method(snap/docker/tar/etc): tar
• Number of Running Instances: 1
• DB Replicaset Oplog: -
• Node Version: 8.9.4-1nodesource1
• mongoDB Version: 1:3.2.11-2+deb9u1

Steps to Reproduce:

1. Create an Active Directory user and sync it to Rocket.Chat
2. Test the login
3. Disable Active Directory user
4. Test the login
5. Re-Enable the Active Directory user and change its password two times
6. Test the login with all passwords in history
7. Delete user in the Active Directory
8. Test the login with all passwords in history

Expected behavior:

Disabled or removed users in the Active Directory should lead immediately to a failed login of the user in Rocket.Chat. Password changes should lead to only one working password, all other passwords in history should not work anymore.

Actual behavior:

See description.

Relevant logs:

-

[rodrigok]

@chgarling Thanks by this report.

You can disable the password fallback to prevent that behavior for now. We can't sync the user password since LDAP does not provide that information, we save the user's password after a successful login on LDAP server to enable the password fallback.

We have plans to improve that ASAP, I hope we could do that to next version (0.63)

[chgarling]

It would be a good idea to implement LDAP the right way and do a bind with the user that tries to authenticate. Using a dedicated bind user is always a bad idea.

Regards, Christian

Von meinem iPhone gesendet

Am 27.02.2018 um 14:43 schrieb Rodrigo Nascimento [e-mail]:

@chgarling Thanks by this report.

You can disable the password fallback to prevent that behavior for now. We can't sync the user password since LDAP does not provide that information, we save the user's password after a successful login on LDAP server to enable the password fallback.

We have plans to improve that ASAP, I hope we could do that to next version (0.63)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[adipose]

Also see #10302. This behavior can be confused by the LDAP id being different than the user id in Rocket. As a result, you can sign in using common name or Rocket name, but it will check different passwords either way. My patch allows you to find the right LDAP user, but fallback will still work incorrectly and check a cached password which could be different. If you disable fallback and use my patch, things are fairly sane.

[theftf]

Are there any news regarding this bug?

Disabling password fallback is not an option for me. I need LDAP Users + local users :(

[theftf]

will this be fixed with #12186 ?

[Shaverdoff]

still no fix.. 0.74.3

[L3nny5]

Any update here?

[craig]

Please fix, this is a security issue. :(

[yasenv-code]

Any update here.

[DKoff]

Here is workaround Powershell script (works only for Microsoft Active Directory) -- checks if user account disables in AD, and disables it in Rocket Chat

Put it in Task Scheduler, and run regularly (update: _make sure, that script runs less frequently than domain controller replication interval, or incorrect behaviour can occur, see comments below_)

Feel free to modify (add exceptions, logging, email results, and so on)

# https://docs.rocket.chat/api/rest-api/methods/authentication
# https://docs.rocket.chat/api/rest-api/methods/users/
# https://docs.rocket.chat/api/rest-api/query-and-fields-info
# https://docs.rocket.chat/api/rest-api/offset-and-count-and-sort-info

# auth header
$headers = @{
    'X-User-Id' = 'user_id_with_admin_rights'
    'X-Auth-Token' = 'so_secret_auth_token'
    'Content-type' = 'application/json'
}
# get all active ldap users from Rocket Chat
$request_userlist = 'https://rchat.contoso.com:3000/api/v1/users.list?fields={ "username": 1 }&query={ "active": true, "ldap" : true }&count=1000'
$response_userlist = Invoke-RestMethod -Uri $request_userlist -Method Get -Headers $headers

# check every active ldap users from Rocket Chat, if corresponding AD user is disabled
$rchatusers = $response_userlist.users
foreach ($rchatuser in $rchatusers)
{
if (!(get-aduser $rchatuser.username).enabled)
{

# generate json to disable user by his ID in RocketChat ...
$request_disableuser = 'https://rchat.contoso.com:3000/api/v1/users.setActiveStatus'
$body_disableuser = '{"activeStatus" : false, "userId" : "' + $rchatuser._id + '"}'
# ... and disable user in RocketChat
Invoke-Restmethod -Uri $request_disableuser -Method Post -Headers $headers -Body $body_disableuser
write-host $rchatuser.username "is disabled in AD, disabling in Rocket Chat"
}
}

[astunk]

Here is workaround Powershell script (works only for Microsoft Active Directory) -- checks if user account disables in AD, and disables it in Rocket Chat

This script disables all received accounts, with no sign of active or disabled user in AD

[DKoff]

This script disables all received accounts, with no sign of active or disabled user in AD

Umm, no

if (!(get-aduser $rchatuser.username).enabled)
This part of code checks, if AD user (his account name received from rocket chat) is enabled in AD. If user enabled in AD - script skips user in rocket chat, if user disabled in AD - script disables user in rocket chat.

Get-ADUser cmdlet requires usage of "activedirectory" powershell module. We are using this script on one of domain controllers, where this module enabled by default.

Try to import module in the beginning of the script
Import-Module activedirectory

[astunk]

I completely agree with you, the selection of users with the enabled status is correct, but I observe inexplicable behavior of this script when blocking rocket users. Among the users there are those who are disabled when the script is executed and their AD status is enabled. There is also AD-user (enabled), which are not disabled when the script is executed, but when they are transferred to the active directory to the disabled status, followed by the execution of the script, I observe the disconnection of the user in the rocket (I take this user as a reference for further testing).
For example:

1. took this AD user in the enabled status, when executing the script on which it does not translate it into the rocket status disabled.
2. copy the user without changing the active directory location structure
3. As a result, I get two completely identical users with identical rights and permissions usertestchat_1 and usertestchat_2, both in the AD enabled status !!!
4. I synchronize the rocket with AD, go in and check the appearance of a new user (both in the rocket have the status "offline")
5. then I execute the script and see usertestchat_1 - "offline" and usertestchat_2 - "disabled"

After reviewing all the attributes of both users, I don't see any difference between them. I ask for help in solving this issue.

[DKoff]

@astunk , looks like some problem is in the cloned user in AD

After your step 4 try to
1) Run script, with this string commented out:
Invoke-Restmethod -Uri $request_disableuser -Method Post -Headers $headers -Body $body_disableuser

2) If usertestchat_2 will be listed in script output (as "disabled") -- try to check his "Enabled?" parameter in AD without script
Get-ADUser -Filter 'samaccountname -like "usertestchat_2"' -Properties * | Select Name, samaccountname, Enabled

[astunk]

With this input, I get the following results:

1. > Run script, with this string commented out:
   Invoke-Restmethod -Uri $request_disableuser -Method Post -Headers $headers -Body $body_disableuser

usertestchat_2 is disabled in AD, disabling in Rocket Chat

1. > If usertestchat_2 will be listed in script output (as "disabled") -- try to check his "Enabled?" parameter in AD without script
   Get-ADUser -Filter 'samaccountname -like "usertestchat_2"' -Properties * | Select Name, samaccountname, Enabled

Name samaccountname Enabled
|------- -------------------- ----------
usertestchat_2 usertestchat_2

for user usertestchat_2 I see the status is empty...

watching user usertestchat_1:

Name samaccountname Enabled
|------- -------------------- ----------
usertestchat_1 usertestchat_1 True

at the same time, the user usertestchat_1 has the status true

I noticed that this error reproduction does not apply to users I created earlier by copying. That is, the user I created two days ago is safely processed by the script, but the new one created (copied) is already mistakenly blocked in the rocket.
I mean it might be due to some add-on in AD itself, depending on the time period. Any more ideas?

[DKoff]

@astunk , judging by your information (get-aduser cmdlet returning null value for Enabled? attribute for new users) - problem is in active directory:

• it is either security issue (user running script, does not have enough permission to read userAccountControl attribute),
• or, _more likely_, domain controller replication issue (userAccountControl attribute of newly created user account not yet replicated across all domain controllers).

More info: https://social.technet.microsoft.com/Forums/ie/en-US/c96bbab7-fa79-41dc-9497-663c6d1b1781/getaduser-enabled-and-disabled-usersand-null-users?forum=winserverDS

I cannot reproduce this behavior, and, apparently, it has nothing to do with script, but, after your step 4 try to execute forced replication across all domain controllers -- repadmin /syncall /AdeP (_command is case sensitive_) from elevated command prompt, and then recheck, if user usertestchat_2 Enabled? attribute is still null

[astunk]

Thank you for your assistance! The script is absolutely working and all my resentments related to its performance relate solely to the specifics of my individual infrastructure setup. Thanks again for the provided script, thanks!

[DKoff]

@astunk , glad to help

Added disclaimer to my original post, to warn other users: _"make sure, that script runs less frequently than domain controller replication interval, or incorrect behaviour can occur, see comments below"_