I’m running OpenFire 3.6.2 on Linux Redhat installed from the tar.gz file. We are using Windows ActiveDirectory (LDAP) as our authentication method and it has been working fine using my account (let’s say user1) for the admin account. Admin account here is the Adminstrator DN asked during the wizzard in LDAP setup 2nd screen.
My IT environment is beyond my control and they require us to change our password periodically. everytime I update password for user1, I need to reconfigure Openfire all over again. To remedy this problem, the IT person created a pseudo account with read-only access, this account is called openfire.admin (or CORP\openfire.admin).
I met nothing but problems when trying to setup Openfire with this pseudo account as Administrator DN. The first screen test button will return success but the subsequent screens will yield failure (user mapping screen and group mapping screen). It may have to do with the hierarchy of the user in LDAP
.
user1 and other users that needs account are in OU=Engineering, openfire.admin is located under OU=Service Account which is a child of OU=Engineering. If I use user1 account as Adminstrator DN, Openfire can find all the users, if I use openfire.admin, it throws me fits.
Any suggestion to fix this issue? Thanks in advance.
It should not matter where the account is located. Personally I keep my binding account in the default Users folder of AD. It may be an issue with the name of the account. THe period may be causing issues. Maybe changing it to OpenfireAdmin and moving it to the default users folder.
Thanks for the super quick reply. I think the period (.) in the username should not matter because all other users in our organization uses it (e.g. john.smith@company.com)
I will request IT to migrate the openfire.admin account upstream (up one level) to OU=Engineering
it shouldn’t matter. your base dn will dictate what the user can see though, put the least restrictive base dn in openfire.
in my AD, my openfire user is under Specialized Users, and all other normal users are under domain\department\various dept… and it works like a champ. my openfire user is also just a regular user with only domain users for its membership
are you adjusting your basedn when you change the user?
like for me, I use dc=my,dc=domain,dc=com as my base dn in openfire. thats the toplevel of my domain. If I do ou=it,ou=departments,dc=my,dc=domain,com then anything above that level will not be able to authenticate.
if thats not your problem then maybe it is the user.user that openfire is having a problem with. when troubleshooting ldap problems I always like to use a 3rd party app to run tests with. my favorite is http://download.softerra.com/files/ldapbrowser26.msi , just the browser if a free download. their other product is not free. I use that to test with, that way I am purely testing the ldap connection.
Hi, so I requested my IT guy to promote the openfire.admin account in AD up one level (to the same level as everybody else is) and reconfigure Openfire after testing the correct setting using an external LDAP browser.
To my surprise, this fixes the problem. Openfire detected all the users and groups. I passed the second and third configuration screen for LDAP and everything works perfectly. I didn’t change anything else in terms of settings (i.e. baseDN)