Openfire Spark login failure - domain controller change
On trying to add a new OpenFire instance today it was found that the admin login to the web page for the OpenFire instances and the Spark client logins were failing. (Essentially each instance is a separate install of Openfire on the same server but in different directories - we do this to segregate the chat groups from one another.)
Review of the logs indicate it was still trying to use the original Windows Domain Controller for LDAP/AD user/password lookups that we'd originally used in setup of the earlier instances. Lets call that ourdc01.
On checking for this issue online I found mention of a script under embedded-db that doesn't exist in our environment and also recommendation to simply edit the entry in the database itself (after shutting down the instance). I didn't really want to muck with the database.
The way I came up with that worked was to simply add the old DC server's name, ourdc01, to /etc/hosts but give it the NEW DC server's IP so it will resolve the new DC server using the old name.
Once that was done I simply logged into the Admin Web page for each of the instances I went to Server-->Server Settings-->Profile Settings and changed ourdc01 to ourdc03, the name of the newer domain controller, in the first screen. I left port as 389 as well as other information. On clicking Test it worked. On clicking Save and Continue it went to next page. I had to paste in the info for DN from first page into line on second page because it just had DC by default with no values. I clicked Test there and it worked but I then had to repaste the DC info as it cleared the field. I then clicked on Save and Continue.
In 3rd (final) screen I changed nothing - just clicked on the Test to make sure it worked then clicked on the Save and Continue.
Doing the above also changes the domain controller in Server-->Server Manager-->System Properties. However changing in System Properties does NOT change it in the above so it is best to simply do the above to change it in both locations.
Once done with the foregoing I removed the entry from /etc/hosts as it would now use the correct name for the new DC which it is getting from DNS.
After that login via the Spark client also worked.
Review of the logs indicate it was still trying to use the original Windows Domain Controller for LDAP/AD user/password lookups that we'd originally used in setup of the earlier instances. Lets call that ourdc01.
On checking for this issue online I found mention of a script under embedded-db that doesn't exist in our environment and also recommendation to simply edit the entry in the database itself (after shutting down the instance). I didn't really want to muck with the database.
The way I came up with that worked was to simply add the old DC server's name, ourdc01, to /etc/hosts but give it the NEW DC server's IP so it will resolve the new DC server using the old name.
Once that was done I simply logged into the Admin Web page for each of the instances I went to Server-->Server Settings-->Profile Settings and changed ourdc01 to ourdc03, the name of the newer domain controller, in the first screen. I left port as 389 as well as other information. On clicking Test it worked. On clicking Save and Continue it went to next page. I had to paste in the info for DN from first page into line on second page because it just had DC by default with no values. I clicked Test there and it worked but I then had to repaste the DC info as it cleared the field. I then clicked on Save and Continue.
In 3rd (final) screen I changed nothing - just clicked on the Test to make sure it worked then clicked on the Save and Continue.
Doing the above also changes the domain controller in Server-->Server Manager-->System Properties. However changing in System Properties does NOT change it in the above so it is best to simply do the above to change it in both locations.
Once done with the foregoing I removed the entry from /etc/hosts as it would now use the correct name for the new DC which it is getting from DNS.
After that login via the Spark client also worked.
Total Comments 0