After banging my head on this recently, here are some things you may want to try:
Turn off the local firewall on the machine, turn off anything like SE Linux, try telneting (or ping or whatever connection test you like) to your AD servers from the openfire server. If you are running an AD cluster with one shared domain name (for example adservers.companynamehere.com) make sure you run the tests multiple times to hit every server in the cluster.
You are right that openfire will not bark during the configuration testing. I can only speculate what it is testing because, well, I was getting impatient and I just wanted things to work. The main test that worked for me with the ldap settings though was adding myself and co-workers as admins for the build after defining my AD settings. That way it was using AD authentication to check if I was in active directory.
Also, as others stated before; there are some ways to build connection strings and filters. I used something like this for the base DN:
ou=(base_object_from_where_searches_take_place),dc=(site_name),dc=(com|net|what have you).
The LDAP admin DN follows this formula:
cn=(account_name_for_AD),OU=(path),OU=(to),dc=(account),dc=(name).
From there it is all in the filters. I had the team that manages AD help me with mine so the filters will vary with your environment but here is a great thread on how to build them out:
After you are able to populate those admin names, you may run into things like openfire taking a long time to build it’s AD cache, but that can be controlled by your filters so play with them a bit and don’t get too frustraited if they don’t always work after a server restart.
After the filters and such are in place, then I would recommend to build up your security again. You don’t know how many times I have had to scratch my head on a problem just to find out the root of the issue is SELinux is not set properly. It is much easier to isolate and fix those problems when you know your system security is not working against you as well.
Thanks.