powered by Jive Software

New OpenFire AD Installation Problems

I’m trying to get OpenFire up and running, and have run into a few difficulties, primarily with AD integration.

I installed, and started going through the wizard. I get to the AD portion, and have trouble. I tried a few different settings and finally got through, but then when asked to log in, none of the usernames and passwords I put in worked. So I changed the flag to false, went back in and tried again…and again…and again. It keeps doing that. I have an integrated database, and it’s almost like it’s not being saved.

The next problem is the user filters, group filters, etc. our AD structure is a little odd, so I could use a little guidance on getting that set up as well. When setting up the LDAP query, I pointed it to a service account in the Users folder at the bottom. When I got to the User mapping section, I tried to point it to the top level Users folder, but it doesn’t find any users. Can it not look in the OUs below?

For some reason, I can’t attach a screenshot of my AD, but here’s a basic structure:


  • OU
  • Security Groups
  • Users
  • Accounting
  • Accounting UserA
  • Accounting UserB
  • Customer Service
  • Customer Service UserA
  • Customer Service UserB
  • Corporate
  • Corporate UserA
  • Corporate UserB
  • Warehouse
  • Warehouse UserA
  • Warehouse UserB
  • IT
  • IT Department UserA
  • IT Department UserB
  • Users
  • Service Admin AccountA
  • Domain Admin AccountA


I went to a VM that my supervisor had build a couple of months ago to do some testing with this, and I copied his openfire.xml file and pasted it into my VM. So, I was able to get the server running, log into the admin console, etc. Here’s where it stands:

I can add users to a security group we have called ‘openfire users’. What I’m finding is that only some of the users actually populate the users list in Openfire. Weird. I’ve taken four users, all from the same OU (Customer Service) and added them to the ‘Openfire Users’ security group. Only two of them populate. I compared the users’ group memberships, and can find no differences. It looks like either a user filter of some kind, or a group filter of some kind is being applied. I tried to manually add users via the admin console, but it says that it can’t be done, since it’s linked to AD.

I tried nesting groups under the openfire users group, but that didn’t seem to work. I want to be able to, once I can actually get the users added, add them to groups that will segregate the chats by department, unless this is something that I have to do via chat rooms and groups within the server.


  • OU

  • Security Groups



-Openfire Users



  • Users

  • Accounting

  • Accounting UserA

  • Accounting UserB

Another Update:

I did a full reinstall, using settings I found using a bunch of google searches, and was able to get my AD groups mapped (all 220 of them), but it’s still not pulling in all the user accounts. I added all 90 of them, but only 29 are showing up in the users list, and I can’t find a pattern as to why some are added, but not others.


So, I was able to get what I believe to be the correct settings, but still have issues. I wanted to be able to break out the access to departments, so I have my security groups set up like this:


  • Openfire Users (86 members)

  • ITChat (8 members)

  • CustSvcChat (14 members)

Here are my user and group mappings:


((objectCategory=Group)(memberOf=CN=Openfire Users,OU=Security Groups,OU=xxx,DC=xxx,DC=com))

This successfully brings up the 2 security groups I’ve created (ITChat and CustSvcChat), which are members of a primary group called Openfire Users. CustSvcChat only contains 4 members, and ITChat only contains 6.


((objectCategory=person)(memberOf=CN=Openfire Users,OU=Security Groups,OU=xxx,DC=xxx,DC=com))

So, when I bring up the list of users in the Openfire Admin console, it brings up only 30, out of a total number of 86 users (all members of the Openfire Users group). Again, I can find no pattern of who’s being added and who’s not.

Here ya go. I wrote this up a while ago. This will point you in the right direction. Let me know if you have any questions.


I used the settings that you posted, and I still get the same thing. Both groups show up in the groups list, but only 4 members in one and 6 in the other when they should have 14 and 8, respectively. The total number of users listed in the users list is only 31 out of a total of 86 from the AD group ‘OpenFire Access Group’.



is your basedn set to the root of your domain?

yes, “DC=gvc, dc=com”

and your main group container is a DOMAIN LOCAL group right?

It wasn’t, so I created a new DOMAIN LOCAL group called ‘OpenFire Users’, and two DOMAIN LOCAL groups called IM_IT and IM_CustSvc. I cleared the cache, restarted the service, and have 28 total users listed, and the 2 groups, which only contain 4 users and 6 users, respectively.

only the one group needs to be a domain local group…the rest are global…or thats how I have it in my configuration.

I tried it both ways. It didn’t seem to make a difference.

the account you are using for ldap lookups…is it a regular user account? if so, what happens if you temp elevate it to a domain admin?

I’ve even added all of my users to the top level group, but only the 28 show up.

Well son of a B. That was it. During my troubleshooting, I tried a different account, and the one I tried was a domain user. I promoted it, and now it sees all the users, both groups, and all the members of those groups! Thanks for your help!


you probably don’t want to have your ldap lookup account being a domain admin. Now that you know its a permissions issue you can correct it. Do this, identify a user that was NOT showing up. its likely the security object for the user is not set to inherit permissions.

I looked at two, one that was visible and one that was not. They were both set to inherit permissions. I demoted the LDAP lookup account back to standard user, and the users dropped back to 28. I checked the security for that account, and it was not set to inherit. I tried setting that, but it made no difference.