Hi all,
I know there are numerous similar threads and I’ve looked through a few and found nothing that seems to help me, so forgive me if this is repeated elsewhere and I just gave up too soon.
I have OpenFire installed and working with Spark clients across a Windows 2003 domain with XP clients (and staff love it! There is probably no going back now ). I have integrated OpenFire with AD (we are a school so I have limited the user integration within the staff/admin OU to exclude the students from the system - for obvious reasons).
The initial integration seemed to go fine and everyone who has tried can log in and chat away. However, whenever something subsequently changes in the AD it does not seem to update the OpenFire database - the main thing being passwords. When a user’s password expires (GPO settings) and they change it they can not log into Spark with the new password but must use the old one. Also, user details (first name, surname, display name) are not updated when they are changed.
Any ideas?
Many thanks,
Steve
In an LDAP sync with AD the passwords are not stored in Openfire. Authentication is being done against your AD server. THis sounds more like the users are saving their login settings locally in spark. As for the other info syncing it will do it eventually. It is different to each system by LDAP sync will occur.
“This sounds more like the users are saving their login settings locally in spark.”
That’s possible, is there an easy way to clear this Spark “cache”?
It sounds like Spark gives your users an error message. I’d suggest you tell your users: When this error message comes up, type your new AD password into Spark.
Spark is “remembering” the password and sending it to the server every time. (That’s a little clearer than calling it “caching.”) You could ask users to clear the Save Password box in Spark, which would prevent it from saving the password altogether.
If your users are logging into their Windows workstations with the same ID as Spark, you could set Spark to use SSO. This effectively resolved the issue for us.
I’ve had a play and it is not every user - my test account successfully changed the network password and the Spark/Openfire passwords changed to suit. And that was with save password ticked (the first time, the remembered password failed, so I had to put in the new one, which worked - that’s exactly as I would expect it to work).
There are, however, one or two users who have changed their password and must continue to use their old password to log into Spark but their new one to log into windows. I can’t see how this is an issue with Spark (and not OpenFire) as the login would surely fail if the password - whatever it is - did not match the password the OpenFire Server has for them (from AD). And I tried SSO for them and it gave an error.
It is possibly/probably a network issue, but nothing else is causing a problem for these users and I am at a loss as to how to help them (and struggling to imagine what sort of network issue would cause this specific and peculiar problem).
There should be no reason they should be able to login with their old passwords. Openfire does not store LDAP user passwords. Additionally just turning on the sso options in spark does not work. there are lots of server side and client side modifications that need to be done to use SSO.
SSO is setup and works for me, just not for these particular users. I have not showed users how to use SSO because originally it wasn’t set up. I may, or may not get them to start using SSO - but that won’t help these users anyway.
No, there is no (apparent) reason why they should be able to log on with old passwords (only) - which is why I started this thread, because that’s what it’s apparently doing.
How many DCs are in your domain? Iff users are getting in with old passwords, it indicates that either their passwords haven’t really changed in AD, or there are replication issues between domain controllers.
Look at the pwdLastSet value for the affected users across all your DCs. If the values don’t match, you’ve got a replication issue.
Second, have one of the users experiencing the issue attempt and LDAP bind (using a tool like LDP) to the DC that Openfire points to fur authentication. It would be extremely surprising if they can bind to that DC using a different password than what Openfire accepts.
Last, if you suspect there are replication issues in your AD, use replmon to check each connection.
a) We have only one DC (don’t ask!)
b) LDAP authentication is otherwise working as all users must authenticate with the proxy server to access the Internet which is done transparently and without any issues at all (trust me I know the nano-second there are Internet problems ;)).
c) Users (affected users) are definitely logging into Windows with the new updated password but Spark/Openfire will only accept the old one.
uninstall spark, delete the spark profile folder from their windows profile. clear the server caches. reinstall. try again.