I have just a few questions that perhaps someone can help me with. I’ve been attempting to find some pros and cons for specific configurations of OpenFire, and have not been very fruitful in my endeavors. I’m just looking for some general information.
Firstly, we were thinking about rolling out OpenFire and having it work with Active Directory instead of using the default internal user database. What are some pros and cons of integrating with AD? The only thing I could really find as far as a concern goes would be scalability.
The other question my team and I were curious about would be the pros and cons of using an external database instead of the internal one. Currently at the moment we are running SQL Express.
If anyone else is currently using OpenFire, I’d love to hear how you have it set up.
IMHO using AD is great as it lets you manage roster groups and users from a single source. You users can use their AD accounts which makes like easy for them (one less password). AD will also let you configure SSO if you want. CONS: Sometimes you have to do some roster group cleanup manually in the database. Oenfire will pass the credentials in clear-text (unless you setup sso/kerberos), so connecting to AD via SSL is a MUST.
I prefer using SQL Express mainly because I’m familiar with it and its easy for me to make changes to the DB should I need to.
I have been running Openfire server for ~200 users for 10 years. I tried to look into AD integration at some point, but it seemed complicated and i have seen many forums posts with various problems with AD groups not populating, problems after changing passwords, etc. If you are in a big company and automatic provisioning is a thing, then sure. Using AD user for everything possible is less administrating of accounts. But it wasn’t a big deal in my book to login to another system and create an account. We were using Save password option, so users didn’t even know their Spark passwords.
I was also using embedded database. It was just simpler and less resources/servers/licenses required. And i think, if you are going with standalone DB, then it should be on a separate server for improved performance, backups, security, etc. Yes, embedded DB is not so flexible for editing, as it is just a huge txt file. But i never needed to edit it (no AD integration well). It was easy to backup everything as i would just backup whole Openfire folder.
Just to give you some background about my situation. At the company I am working at we are currently testing/deploying Openfire. I am more or less leading the project (doing the research, testing, working with other members of the team to fix issues etc.) When it is fully deployed we will have over 3000 users on it.
Here is what I have found with AD integration, if you have your AD and group/user filters setup right, you will barely have to touch it once everything is done.
Yes it is a couple extra steps, and there is the occasional issue with a corrupted AD account that isn’t being picked up (just recreate it). But with the size of the company I work for, not having to do those couple extra steps each time you have a new user or someone leaves is vital. Also keep in mind, it is one less password for the users to forget.
There are 2 cons to AD integration:
Setting it up (the inital steps, and having the groups the way you want them in AD)
If the account that connects Openfire and LDAP is moved or if Openfire cannot contact LDAP, then Openfire stops being usable. Unfortunately there is no way to create an Openfire only account if you configure it with AD. You would have to run through the setup again (there maybe a file somewhere that you can alter to avoid this, but I don’t know where that is).
For the external vs internal database:
You will get better performance with external but it is also more complicated to setup, and you usually can’t use the latest database without issues (we are using MySQL 5 because of issues).
I recall seeing on a forum somewhere that internal has a limit of 500 users.
Summary:
I totally recommend AD integration. You can get by without it if you don’t have that many users and a low turn-over rate.
If you have less than 500 users, and performance isn’t a huge concern, maybe consider an internal database. From my experience, to get the external database aspect just right, it needs a bit of tinkering.
I haven’t heard about such limit for the embedded database. Also, @Yeatts are you using the latest Openfire version in your deployment? Database connector has been updated recently, so i would hope it works better with newest versions. Of course, this is just a connector. As a side effect older versions of MySQL won’t work now (older than 5.5). Well, one can still replace the connector with older version and get it working.
@wroot We are using the latest Openfire version and a new MySQL connector (which one? Not entirely sure, just not the default one).
Our issue was doing an SSL connection between Openfire and the database. We had trouble finding out how to do that, and the older version of MySQL doesn’t care as much about not having SSL (didn’t constantly spew out errors). After trial and error we got it working, don’t really want to test the waters now with it.
Also the limit for the embedded database could be 10 or so years old. So that information could be irrelevant by now or it could have been someone throwing out a number. They could have been saying pass 500 users you shouldn’t use it. I have gone through so many forum pages I honestly can’t remember where I read it.
