powered by Jive Software

Openfire 3.8.2 Active Directory Problem

Beating a dead horse apparently, I’m having an issue configuring Openfire with Active Directory. None of the other threads has seemed to help with my difficulties. After installation, and during configuration, when I get to LDAP Connection Settings, I put in the applicable information and click ‘Test Settings’ and nothing happens. Nothing seems to get logged, and I see no connection attempts in out Active Directory server. (Settings are in the first attachment)

It almost seems like the request is not leaving the server that Openfire is installed on. I’m not sure how to trobleshoot this any further. I have tried changing the BaseDN, and the AdministratorDN, to no avail. Any help would be great. We really need ot get away from iChat.

I am assuming your DNS server specified on the openfire host can resolve that host?

Yes. Verified DNS. I also tried the configuration with the ip address of the Active Directory Server instead of the DNS Name.

Hmm, when I click ‘test’ on my AD-Working-server, nothing happens as well. Running 381 right now.

On thread on here said to just continue the configuration without the test, but when adding the administrator account at the very end, it fails. I’t almost like the LDAP functionality is missing. The Openfire.XML config file has no LDAP info in it either.

Yeah mine doesn’t either, it’s all in teh server properties.

I sent you a PM of my server settings, I can’t guarantee making the properties manually will do anything, but that’s taken from a live-working-AD integrated server.

hello, anyone could solve this problem? as they did? greetings.

Not yet. Still broken.

make your base dn the root of your ad domain.

dc=gstv,dc=local

then your admin account (account used for ldap lookups. this can actually be a non domain admin account)

account@gstv.local

the test function doesn’t wort in 3.8.x for some reason, but you’ll know it working when you can add a openfire admin account new the end of the set.

I’m having the same problem (Openfire 3.8.2) and have tried adding just the root of the domain and am still unable to add any admin accounts, or get any indication any ldap queries are happening.

hi , speedy is correct clicking on “testsettings” will not display any results in activedirectory setup . i tried dc=mydomain,dc=com and in user dn property DomainAdministrator@mydomain.com and its working fine .

askadmin.com

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.

I got my install working on server08r2 with openfire3.8.2 by doing the following:

  • stop all instances of openfire, including openfire service

  • uninstall openfire using uninstaller C:\Program Files (x86)\openfire\uninstall.exe

  • search registry for “openfire”

  • delete all keys and parent keys if it made sense

  • disabled windows firewall for domain profile

  • created a normal user in AD called “openfire admin” with a username “openfire” with a password that met password policies

  • added openfire user to Domain Admins

  • reinstalled openfire

  • host was dev08r2.domain.local

  • Base DN was dn=domain,dn=local

  • Administrator DN was openfire@domain.local

  • keep defaults on steps 2 and 3

I was able to add an administrator user account just fine.

I think the issue lies in the fact that once a setup fails, something in the registry might be borked. once i deleted all keys that contained openfire and re-installed, everything worked like a charm.

I know disabling the firewall and making the user a domain admin isn’t the best practice security-wise, but this is being implemented entirely in VMWare player host network with VM clients. I’m only do this to provide a proof of concept for the people with higher paygrades.

I have same problem, but I’m using CentOS 6.4 x64

Setup stops when i’m trying add administrators of server

I did all steps that u mentioned, but it didn’t help

Can anyone advise something?

Dmitry,

Here are a few ideas off the top of my head:

Check to see if you can send traffic (ping probably being your best bet) to your AD servers from the openfire host at the command line. If you can hit the AD host, the most likely problem is the AD filter that is in use is not working properly (try using the most generic one you can think of that will work).

Are there any errors from the setup screens or in the stderror.log or the error.log within the openfire directory when you are trying to add administrators?

Thanks.

I too was having this and it appears to be an issue with prototype.js (an included resource) not with openfire.

When I launched chromes web inspector it showed an error

**Uncaught TypeError: Cannot call method ‘get’ of null prototype.js:5557 **

this file is located in Openfire\plugins\admin\webapp\js\prototype.js

the prototype.js file is listed as Version: ‘1.7’,

On a whim I tried upgrading it to the latest (version 1.7.1), cleared my browser cache and it corrected the issue for me

1.7.1 can be found here

https://ajax.googleapis.com/ajax/libs/prototype/1.7.1.0/prototype.js

1 Like

Matzkejd,

Yes, I cansend traffic to my AD servers, i checked it with wireshark and saw successful replyies from AD

In hohup.log i have only this error wnen thying add administrator -

javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0

.]; remaining name ‘’

On setup screens i see this error:

No username was provided or the specified username was not found.

Choose one or more users from your LDAP directory to be administrators by entering their usernames.

You told something about AD filters, can you give me few examples?

Finally it got work.

Mistake was simple and foolish as usual.

For Base DN i used dn=domain, dn=loc

but when i checked again my AD using ADSIEDIT i realized that my Base DN is dc=domain,dc=loc

So now it seems work fine, tnx for reply guys )

This fixed my issue! Can this please be marked as the correct answer so that others may see?

2 Likes

Hi Everyone, I was looking for the answer for this issue.

Look what I’ve found : http://support.microsoft.com/kb/2545140

In my scenario, I’ve found that the Active Directory server requires signing by certain certificate.

this is the root cause for my AD authentication problem.

After I set the group policy as described in above link, my problems was solved.

Please have it a try, and let me know the result guys.

Cheers…