We are a company of over 250 users, and would like to upgrade Spark from version 2.5.8 to the latest of 2.6.3.
My issue is that from my testing I see that the saved password is not remembered between versions and that the parameter in the %appdata%\Spark.PROPERTIES file has changed from “password=” in 2.5.8 to something like “passwordRzFnFhsw83uJ6vIErtAm9OTr0GgQTKrA=” in 2.6.3. This new parameter looks to be specific to my user account because if I login with a different account and save the password, an additional “unique” parameter is created with the encrypted password. I assume this is necessary because of the new feature to save multiple accounts at the login screen of Spark… This is an issue for us because I would say 80% of the users don’t know what their own passwords are, so I can’t just simply upgrade and let them do the rest. I could export all the user account information from the Openfire server which includes the passwords in clear text and email it to them, but this would be time consuming and against our company’s password policy. Is there anyway to “upgrade” the parameter that contains their saved password so they do not have to do anything “special” at their end?
Well, that’s a tough one. There is no option to migrate the passwords.
There is a community plugin for OF that provides a password reset self service. It assumes flawless entries of the mail accuonts for the users in OF. But it really saves my day (I have >10.000 users).
Three months ago i did an upgrade from 2.6.0 to 2.6.3 on our network using a AutoIT script passed trough AD. And i don’t remember running into any issue with passwords, and likewise most of our users don’t know their own password on Spark.
Hmm. It’s not possible to tie Spark logins through AD in your organization, is it? I find it makes life easier since they have fewer passwords to remember.
Yes you can. You have to set Openfire to get the users from AD.
Thanks for all the comments and suggestions! We have opted for the Openfire Password Reset plugin (http://community.igniterealtime.org/docs/DOC-1240) that Walter suggested. This will allow users to reset their own passwords to a nicely scrambled password that the plugin generates for them. The only down downside is that the password reset interface is accessed on the Openfire admin port 9090.
To: M. Tejera, I believe password parameter in the %appdata%\Spark.PROPERTIES file was first changed in 2.6.0, so an upgrade to 2.6.3 would probably be simple.
To: Tomas and M. Tejera, I tested the AD integration with Openfire when I was first evaluating it, but was not please with the lack of flexibility it gave in the the Openfire Admin Console. It seemed like it imported too much stuff from AD, where I would have preferred to have chosen the users (based on an AD security group) who got imported from AD instead.
curtwilson, you can use filters in the AD integration to chose the users. For example this filter
(&(objectClass=user)(objectCategory=person)(memberOf=CN=Openfire Users,OU=Security Groups,DC=DOMAIN)))
Would only import users belonging to the Openfire Users security group located in the organization unit “Security Groups” situated on the domain controller “DOMAIN”.
It requires a bit of trial and error, but you can do a lot with the LDAP filters. Here’s a few examples.