A test environment made of 3 servers - an Active Directory server, an MS SQL server and an Openfire server.
All 3 boxes are accessed by Remote Desktop, using the AD Administrator password.
The Openfire instance is configured to us LDAP. The adminDN is that of the same user accessing the box - the Administrator account.
The Openfire authorizedJIDs is the same user again (v bad practice, but potentially not unique, and proved interesting for this test!)
When using Remote Desktop to access the Openfire server this morning, I had to change the AD Administrator's password due to password expiry.
I changed it, and connected via Remote Desktop again using the new password
I could no longer access Openfire Admin locally from the Openfire server
The ldap.adminPassword in SQL remained set to the old password for the AD user
Attempting to log in to Admin using either the old or new password resulted in failure
Correcting the ldap.adminPassword returned "normal behaviour" where correct passwords would authenticate and incorrect ones would not
Looking at LdapAuthProvider.java, the user is turned into a disguishedName before authentication, which requires AD search, which requires credentials
Unsure what to suggest as a fix. A warning about not having your AD user as your only admin authorised JID?
Windows Server 2016, Active Directory
I have no suggestions on how to fix this problem. Trying to prevent is sounds like a good course of action.
It's possible to configure Openfire in such a way that it takes users from more than one backend. This can be leveraged to obtain admin users from a local database, while getting all other users from LDAP/AD. I think even wrote a tutorial on doing this, which probably involved MappedUserProvider and/or HybridUserPovider.
We might want to consider to have such a setup be default, when a new server is set up with LDAP connectivity.
The quickest way to do work around this is to either revert the ldap password, regrain access to openfire, and change it within openfire first...then change it in ad/ldap. OR change the openfire.xml setup flag to false. This will re-run the setup wizard allowing you to update the password via the ldap setup screen.
I have tried both the mappeduserprovider and hybriduserprovider. Both will work with creating a local admin user, howerver with a few gotchas. Both are a little complicated to set up. the hyrbiduserprovider can not create the password via the gui,. Password has to be done directly to the database in plain text.. The mappedUserProvider works well, but is a bit more complicated to setup.
3rd option maybe to use gssapi and a service account. I tried this once a couple of years ago..., this worked, but is not simple, required a small code change, may have worked only accidentally! probably not the best option