Hi. I have about 2000 users and I want to split them to different servers.
I used search filter :(&(objectCategory=Person)(sAMAccountName=*)(memberOf:1.2.840.113556.1.4.1941:=
And it works for logging in.
But Rocketchat imported all users from the base OU and I can not limit it by group.
I deactivated thouse users that I do not want to see at this server’s catalog.
But every time I press resync button some users come back activated.
It looks like the first (alphabetically) 100-200 users always get activated during resync.
Try using User Search Filter (example for Active Directory): (&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=<some users group>,OU=<your OU>,DC=company,DC=com)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Last filter (!(userAccountControl:1.2.840.113556.1.4.803:=2)) means “exclude disabled users from AD”. You can remove it if you want disabled users to appear and authenticate in Rocket.Chat, too.
The problem is that users deactivated in RC are activated during sync. In some random amount.
And I doubt that your filter can limit import from AD. Looks like this filter works only during login form.
For me, this filter works on login and sync. I just implemented it a week ago.
Firstly I had similar issue with a bunch of users and PCs, appearing in RC after sync import.
Then I created a AD group with needed users in it, and applied a filter in RC.
Users from LDAP je activated/deactivated in accordance to membership in this group and applied filter.
Eg. when I changed User Search Filter and excluded disabled users from AD, then RC disabled users in RC, too.
That was my case at least…
Looks like we are talking about different things. I don’t mean that RC imported computer objects.
There are users in the BaseOU that I do not want to see in user catalog.
Please go to your RC Administration page and look at users. Can you see there users that are not in LDAP group you set in filter?
What status do they have? Try to set deactivated and resync LDAP.
If I deactivate LDAP user in RC, and run Sync (with Background Sync Update Existing Users turned on), then this exact user is activated again after synchronization.
And vice versa. If an LDAP user does not correspond to LDAP filters any more, it gets deactivated in RC.
Do you understand that active/deactivated differs from “can not login”?
What do you mean as “deactivated”? The status in RC admin console changes to “deactivated” or he just can not login anymore?
The status in RC admin console changes to “deactivated”.
Look, as I explained, my experience with RC ver. 3.2.2 and LDAP (AD) is as follows, according to User Search Filter outcome:
If RC existing user (previously derived from LDAP) is included within correspond filter criteria, user is activated in RC. If a user is for some reason deactivated in RC, then it is changed to activated again after LDAP Sync.
Otherwise, existing LDAP user gets deactivated in RC. Meaning, if a user is activated in RC, and a user is not derived according to existing LDAP User Filter, yhis user is deactivated in RC.
I run 3.2.2 too but users are activated regardless their membership on resync.
May be I should turn on “Sync LDAP Groups” and put some magic in undocumented “User Group Filter”.
RC has just another weird way to setup LDAP. Every developer reinvents this wheel…
Glad to know it’s not my misconfiguration.
Users are activated after any sync. Not only background. Press manual resync and here they are.
The amount of activated users looks random and maybe it depends on User Search LDAP filter complexity.
I did not tested a lot but after I shortened it to just membership I got only 12 activated while complex filters resulted in 100-200.
And it works like this:
I deactivate users with API script. And the next resync activates some users. Following resync do nothing untill I use deactivation script again.
May be it is about some API bug.
You are right. I did some additional tests.
If a user is deactivated in RC, then it is activated again after Sync. Even though LDAP/AD query does not include this “deactivated” user any more (Eg. user is deactivated or removed from LDAP).
So, we have a bug here, apparently…