Using LDAP for Auth Only with Local User DB

I am trying out Openfire XMPP server for a department within a university. I want to use the U’s LDAP authentication, but I don’t have privledges to do any group lookup on the AD server. Also, I don’t want to allow all 1,000+ AD users. Here is how I did it, by accident really. If anyone knows a better way (likely through manually adding either LDAP or local Users in the DB after setup) please share it.

I should add that this means you must manually add allowed usernames, but they’ll use their AD password. I disabled automatic/self-registration via the client, so I don’t know if it is possible if a valid LDAP user tried.

  1. Install Openfire and do the initial setup using **local **AUTH (I also used internal DB)
  2. Login as admin and create username matching your LDAP uid and make it an admin (this is how we will login after we setup LDAP)
  3. Stop Openfire and edit conf/openfire.xml, change the setup tag from true to false.
  4. Start Openfire and you will be again greeted by the setup wizard. Setup the DB exactly the same, but this time choose LDAP auth.
  5. Setup LDAP auth and remember to make your uid an admin.
  6. Login to Openfire with your LDAP authentication.
  7. Under ‘Server Manager’ go to ‘System Properties’, edit provider.user.className from org.jivesoftware.openfire.ldap.LdapUserProvider to “org.jivesoftware.openfire.user.DefaultUserProvider”
  8. Also, change to “”
  9. Don’t logout or anything! On another computer/browser, check that you can login to the admin console still! If not, change the above values back to their original.
    Thoughts: If might be possible to skip the initial local auth setup and just add local users after changing “provider.user.className”

I stumbled upon this working after trying to do the reverse (turn local auth into LDAP auth by manually adding LDAP to the database).

Hope it helps someone!

1 Like

I don’t quite understand. You still need to add users manually after this? What happens if a user changes his AD password?

The password in the local database is not used since the authentication mechanism was changed to use LDAP. Essentially what is happening is the username is validated against the local database, but then the password it validated against AD. The usernames must exist in both AD and the local database.

User IDs not in the local database cannot login. User IDs that AD will not authenticate cannot login. To change their password, it must be changed in AD, the local password is not authenticated against.

Due to the last sentence, it might be wise to disable users changing passwords, since the locally stored password would never be used.

Interesting… workaround Probably this is not by design and wasn’t planned. Maybe this can be useful for someone. Thanks for sharing.

This is very helpful for us, but I am curious about the roster, if we use the local user from database, then if we use pidgin to log-in, can we still see all the user in our contacts?