The Great Open Source Debate with Elastic, Gluu and GitHub 🎤 Oct 26

Upcoming changes to identity management integrations

“LDAP_User_Search_Filter” is essential for our installations.
We have >100.000 users in our LDAP with many different tenants.
Some of them need the search filter to only allow users which did an explicit opt-in to

If we loose this feature in CE is not a affordable product any more for us.

4 Likes it would be helpful if the original post stated what you are clarifying. The original post reads:

Our team has recently completed a refactoring of all identity management integrations including LDAP features, SAML integration and advanced Oauth capabilities. In our September 27th release, these features will be added to the Rocket.Chat enterprise edition, while a limited version of LDAP integration features, together with social login options, will remain available for use and extension in the community edition.

What you are saying is that SAML, Oauth, etc will continue to work, but the original post does not read that way.

Also, I just updated to 3.18.1 and your banner contradicts what you are saying:

I’d love to, but unfortunately I’ll be not back home from the office at this time.

I hope a lot others stand my point.

Our goal is to enable Rocket.Chat users to have a choice between extending basic LDAP

Please, please, please leave the filter and sync.
(If possible, please keep all of them.)
That’s what “basic LDAP integration” is all about!

1 Like

Unfortunately, if you strip out features like:

  • LDAP-Sync
  • Mapping of LDAP-group to rooms
  • Mapping of LDAP-group to roles

I have to migrate my 4 schools with around 1.000 users per school to an other solution.

There simply is no way that this schools can pay anything near your expectations, in fact the “IT” budgets are nearly empty at the middle of the year.

I could try to “sell” you the idea that it would be better to let this features in and gain araound 4.000 people that know your product and eventually one or more of the students become a decision maker in a comany and that influence helps to sell your product in the end…

I have to admit and agree with others it’s not a good feeling to see a company strips out features from a CE version “only” to put them behind a paywall.

And over all responsible minds in the city hovers an offer from Microsoft ~0.75 € per student per year for Teams and Office on top. The scools that want open source solutions have more and more problems to avoid this ****…

1 Like

That also means in the future if they want more money again they will move more features to the paid version. There is no reason they will stop if they are successful this time.

2 Likes Thank you for the clarification.
I’ll be as constructive as possible.
However, I have read this chart and the obvious conclusion is that custom oauth providers are not supported while the built-in ones are.
Probably a more accurate description is required.

Second point, “Custom OAuth Role Mapping” support is removed but the description talks about role mapping base on user group. This means that role mapping base on the role claim still works?
Again, this is very confusing.

We are all admins, not marketing people. We can understand the nuance.

I completely understand the need to make money out of the product. But these method is a bit rough. Having specific feature for the paying customers is a good method. Providing support is another one. Changing the feature set to try to force migrating to a paying plan is also a solution.
You have the right to do it. It’s risky and not popular.

Finally, I am pretty sure to have read in the communication that new features will come to the CE first and then be moved to EE. This means that we can expect the same events for future features.
If it’s the case, don’t bother. Noone will use features that will be removed. Instead add them in the edition they belong to from the start and keep them there.
Can we have a clarification that?

Thanks for the feedback, we are working to improve those docs pages to be more clear.

There is only one role setting on Custom OAuth that is the role based on role claim. It will be an enterprise feature.

Thanks for your comprehension. We understand the risks and how unpopular this changes will be. Unfortunately, support plans or donations only don’t work, we tried as our very first business model 5 years ago. Please join our Open Call for Community tomorrow to know more about this topic.

No, that’s not true, please share with us if you find where this was posted.
The inverse path may happen, where we deliver features first to EE and make them CE later once we have other features to support the sales. The movement we are doing here is an exception that we don’t want to do again in the future, it’s the first time we are moving a CE feature to EE during these 6 years of our existence and those features were already present in the product before we had our very first EE version, so those never had the possibility to be EE features before the implementation.

@cb3instatic thanks for your feedback, we are working to improve the original post and the doc pages to make it clear for everyone.

Just reenforcing that all the login methods mentioned will continue to be and work in the community version with basic functionalities. Advanced functionalities of each of them, as automatic syncs, mappings, custom fields, etc, are the affected ones.

Hi @amatorphasma, thanks for your feedback.

Please check our concession program, there you will see benefits for no-profit, educational and FOSS communities.

Get in contact for more information, we have discounts of above 50% for education and we do not charge for students! If your schools are non-profit you can apply for a free license as well.

@photoninger thanks for your feedback. 100.000 users is a huge user base, are you a non-profit, community, or education institute? If so please check our concession program for big discounts.

We are promoting discounts to clients who were already using those features in the community version earlier or have contributed to our code. Please reach out to our sales team to request a quotation.

@mstafurik thanks for your feedback. Could you explain how those changes will affect your installation so we can try to find a solution or clarify any information here?

To compete in the market improving features and create new ones with quality, always keeping most of them free on community version, require us to grow our engineering, quality, UI/UX, product, data, and other teams. As we find the right features to be on EE we can deliver more features to CE while the right clients are paying for the solution and the community being able to use it for free when it’s necessary.

To support non-profit, FOSS communities, education and others we have a concession program, if you fit on any of those criteria talk to us and we will be happy to support you.

Please join the Open Call for Community for more information.

So you have more than 200 and need to allow only those 200? How much more users do you have in your LDAP?

Are you a non-profit, educational or FOSS organization?

@rodrigo.nascimento I think you are missing the point for these people having >100k users or >200 users and needing the ldap search filter. Whether it’s because they have a multi-tenant AD (multiple organizations authenticating in one AD) or have more users than what they want to allow to sync with RC because of perhaps misc/test accounts, this is a security issue. Having extra user accounts that may or may not be used by a real person or not, may not need or should have access into RC. Every ldap enabled app I have ever used has had a search filter, as I would not have used it otherwise. By making this one specific feature (ldap search filter) available in the enterprise edition only, you are effectively reducing the security of the community edition.


I work as a network and computers systems administrator in one of the departments of public university (this is a throwaway account, as I’m not authorized to represent my employer) - we use Rocket.Chat CE for some non-classroom projects. As we receive public funds, in most cases we are not allowed to “go and buy whatever you want”. Depending on cost, we may be required to go through tender calling procedure. As you may guess, this takes time. Even buying a cheap wireless router took two months… With less than month advance notice, there’s not much I can do (short of leaving Rocket.Chat out-of-date, probably firewalled from the Internet…).

Buying software is difficult. I am not allowed to say “I want to buy Rocket.Chat EE for X users”, I have to describe features I need (and this means that the best bid may be for a competitor product, not Rocket.Chat). Many times there were no bids for our tender call, because nobody in our country was a reseller of software we needed and our order was too small for any other intermediary to bother. In the end, after several failed tender calls, we are allowed to buy software in a “usual” way - but this takes a looooong time…

And one more thing - each time I have to explain why my purchase is necessary. It may be difficult to justify buying Rocket.Chat licenses when Microsoft gave us MS Teams for free… (“I don’t like Teams” is not an acceptable explanation.)

With regard to changes, I find it strange that you consider LDAP filters an advanced feature. Different LDAP servers (especially home-made ones) may use completely different LDAP schemas and object classes. I’ve seen setup where users, groups and computers were all mixed in single OU and LDAP structure was flat (“filtering” using base DN was impossible). How will Rocket.Chat distinguish between user and non-user objects in such cases?

To be honest - I don’t really like Rocket.Chat, there were just no feasible alternatives back when we deployed it… Now - even if we decide to switch to some commercial solution (but that’s not my call) - we will reconsider other alternatives first (some of them were mentioned in this thread and they look nice).

1 Like

We can live with automatic background LDAP sync, group and user filter doesnt work very well at this moment, they are so broken so after few tries I stopped trying.
We have 400 users in LDAP, 100 are using rocket chat. We are profit organisation.

If you indeed remove LDAP background sync from free version, we will probably stick around without upgrading for while and then move to another maybe paid solution.

As other peole are saying, this is bad move. We may end up with paid solution but its not going to be rocket chat. You can try, its either going to get you profit or you destroy rocket chat.
Feature wise as it is, its not worth payment. You may get it there, but at this moment its more like beta version of software.

1 Like

I’d like to see some clarification on this.

I never thought basic user search would be removed. Just group features.

It would mean hackers can try and compromise your server via system accounts (but not admin as you are blocked by Rocket from that…)

I wouldn’t want people trying to login as apache, nginx, docker or root etc…

1 Like

We are education and we already talked to your sales people last year when push notifications moved to EE.
Even with your “big discount” we could not afford EE: Your price model counts every user in our LDAP and not the active users of


just another bad move by the RC. Specially taking away a feature that was already present in the CE…what’s to stop you to take more features away from the CE in the future. Looks we’ll have to look into alternatives. it’s a shame…one bad decision after another

1 Like

well. alright. reading through this was interesting. the essentials will keep working. the avatar sync will no longer work. thats enterprisey… but ok then. can live with that!

we use a custom oauth provider to authenticate users against invisionpowerboard. which works very good! we have written a tutorial for others about it, created a free board widget to show online users in the board. Took quiet the time to do all that. To have spent that time to get “enterprised”… I’m not yet mad as it seems ok, but if you move features around between editions please consider those things as well before you making such decisions.

There is no pricing plan for small self hosted communities with only some dozen users. How the chat software would cost 120 times more than the board software we use… well yes thats enterprise level.

And as a last side note: the last thing I want to do is “contact sales”. I don’t like contacting sales. I’m sure they are all nice and friendly people. but still: it is the last thing I’m going to do. If your pricing is SO flexible, that looks a bit funny too as it makes your pricing page look like a bold lie - or let’s say incomplete.