LDAP Auth - Disabled AD Users



We have had Rocket.Chat configured with LDAP authentication back to our AD domain without issue for some time. I just recently came to notice when users are disabled in Active Directory, they are still able to login to Rocket.Chat. Is this expected or am I doing something wrong? I’ve poured over the settings in the admin area but can find any pertaining to this.

Other applications that we have LDAP auth with like NextCloud or Zabbix prevent users from signing in when their AD accounts are disabled, as I would expect.

EDIT: Also, I’ve noticed if you LDAP sync a user that has been disabled, it will not let you login until you enable in AD Users and Computers and re-sync LDAP. However, for existing users, it doesn’t sync or pick up that the user is disabled.


LDAP Auth and local users

We have the same issue/need


I never could find a solution to make Rocket.Chat automatically disable users when the AD user is disabled, so I just added this to my PowerShell script that I already use to disable AD users. It will deactivate the Rocket.Chat user for me:

$user = "your_username_here"
$Headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$Headers.Add("X-Auth-Token", 'my-auth-token')
$Headers.Add("X-User-ID", 'my-user-id')
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$response = Invoke-RestMethod -Headers $Headers  https://my.chatserver.com/api/v1/users.list
$RC_id = ($response.users | Where-Object {$_.username -eq "$user"})._id
$body = @{
    userId = "$RC_id"
    data = @{
        "active" = $false

$body = $body | ConvertTo-Json -Depth 2
$DisableResponse = Invoke-RestMethod -Headers $Headers https://my.chatserver.com/api/v1/users.update -Method Post -Body $body -ContentType 'application/json' 

Maybe this will help you too.


Amazing! Thanks :blush: Will try it out & see if it’ll shout people up with the moaning :joy:


this is one reason I havne’t been able to deploy rocket chat past a POC. I hope the devs take notice and feel like this is an issue that can be looked at.


It’s a minor inconvenience to deactivate the user, but I already had a disable AD user script. So adding what I did above wasn’t too bad. However, I still think it should do it automatically like many other services with LDAP integration do.


Id say its a higher issue than minor and would rate this a med to high level issue. The reason for integrating with a central directory, it be ldap or something else, is so they can manage from that directory. The assumption is and should be, if I disable or delete a user from LDAP, then that user is disabled in every single ldap integrated application. Best case, a person gets in trouble or fails an audit because users were still able to sign into an application that you believed them to be disabled in. Worse case a user believed to be disabled can still access sensitive information from outside the organization, and then uses that information in a way that hurts the organization. If rocket chat is going to be an internet facing “cloud” product…which allows collaborative communication and file sharing or potential sensitive information…than something like this must be addressed. At the very least as warning needs to be issued on the setup page when configuring LDAP.


Agreed on the warning in the LDAP config area. It looks like it is expected behavior at this point: https://github.com/RocketChat/Rocket.Chat/issues/9916