Regression: Legacy admin accounts cannot log in to Admin Console after upgrade to Openfire 5.1.0

Hello,

I believe I have found a regression introduced in Openfire 5.1.0.


Environment

  • Openfire 5.1.0

  • Debian 13.5

  • PostgreSQL 17.10

  • Java 25.0.3


Summary

After upgrading from Openfire 5.0.5 to 5.1.0, some existing administrator accounts can no longer log in to the Admin Console.

The login page shows:

Invalid username or password

However, credentials are correct and XMPP authentication works normally.


Affected vs working accounts

:cross_mark: Affected accounts (legacy admins)

  • Existed before upgrade from 5.0.5

  • Previously had administrator privileges

  • Cannot log in to Admin Console after upgrade

  • Still authenticate successfully via XMPP

  • Are listed in admin.authorizedJIDs

  • SCRAM credentials are valid

  • No user flags or bans present

  • Removing and re-adding admin privileges does NOT help


:white_check_mark: Working accounts

The following cases work correctly in 5.1.0:

  • Newly created users granted admin privileges after creation

  • Existing users that were NOT admins before, but later granted admin rights

  • These accounts can log in to Admin Console without issues


Reproduction / additional test case

One affected legacy admin account was:

  1. Unable to log in after upgrade to 5.1.0

  2. Deleted completely

  3. Recreated with the same username

  4. Granted admin privileges again

:right_arrow: After recreation, Admin Console login worked immediately.

This strongly suggests the issue is related to legacy user records rather than permissions.


Database checks

For affected users:

  • present in ofUser

  • listed in admin.authorizedJIDs

  • valid SCRAM fields (storedKey, serverKey, salt, iterations)

  • no entries in ofUserFlag

  • XMPP authentication succeeds


Audit log behavior

Before upgrade (5.0.5):

  • Successful Admin Console logins exist

After upgrade (5.1.0):

  • Only failed login attempts are recorded for affected accounts

Expected behavior

Administrator accounts that worked in Openfire 5.0.5 should continue to work after upgrading to 5.1.0.

Additionally, granting admin privileges to any user (old or new) should consistently allow Admin Console access.


Actual behavior

  • Legacy administrator accounts stop working after upgrade

  • Newly created admin accounts work correctly

  • Previously non-admin accounts promoted to admin also work correctly


Notes

This appears to be a regression affecting legacy administrator user records after upgrading to 5.1.0.

Happy to provide additional logs or database details if needed.

I am unable to reproduce. I have an admin account in 5.0.5, updated to 5.1.0 and it still continues to work. Please install 5.0.5 within a development environment and provide reproducing steps that create the issue once updated to 5.1.0

Important update

After additional testing, I discovered that the problem is not triggered by upgrading to Openfire 5.1.0 itself.

Openfire 5.1.0 works correctly until I perform the migration from legacy SHA1 key derivation to PBKDF2 that is recommended by the Admin Console security notice.

Once the migration completes:

legacy administrator accounts can no longer log in to the Admin Console;

newly created administrator accounts continue to work;

existing users that never had administrator privileges continue to work after being granted admin rights.

If the PBKDF2 migration is not performed, the issue does not occur.

same here, no admin-login possible after migration to pbkdf2, neither any client can connect to the openfire server via xmpp or sth.
shouldnt the migration assitant take care of being able to use the same accounts after migration?

Any update on this issue?

I suspect that the source of the issue is similar to that described in Admin GUI not starting after migration to PBKDF2. If that’s the case, then rolling back a previous database backup (from before the pbkdf2 migration) needs to happen to recover the encrypted data that is now undecipherable.

Openfire 5.1.1 adds hardening, to prevent this kind of thing happening, but it cannot recover an already broken system.