powered by Jive Software

"Unique" LDAP authentication failure with 3.8.x

This is more for posterity, so someone else might have an easier go of it in the future. We’d been running 3.7.1 with the bundled jvm and a local database on Windows Server 2008R2 for quite some time after an unsuccessful upgrade to 3.8.0 shortly after its release (none of the configuration settings seemed to stick). Figured that with 3.8.2 being out it was probably time to upgrade, so plunged in last week, and all was well until the server was restarted over the weekend. Came in Monday and couldn’t log into Spark, nor could I use my credentials to log into the Web Console. Logging in was failing almost instantaneously with the error:

“javax.naming.CommunicationException: myserversip:port [Root exception is java.net.ConnectException: Connection refused: connect]”

Tried going through setup again with no change, tried a clean install with no change, verified LDAP services were running on the DC and were connectable from the server with Spark using Microsoft’s LDAP tools, restarted AD services on the DC for good measure and re-verified the connection, and was quickly running out of ideas when I finally lit upon the solution.

Here’s where the “Unique” comes in, as hopefully no one else has a configuration this silly. The net admin who originally set up the AD network here chose the root domain to be .com, and then never bothered to buy that domain, and at this point the domain is owned by someone else (as an aside, I’m not the net admin, I’m just a roadway design engineer with a flair for IT). So I don’t know if it was a change in Openfire itself, or the underlying JVM (or perhaps something completely unrelated), but as our base AD domain is a publically owned domain not owned by us (and not, say .local), Openfire was trying to resolve LDAP against it and failing. The quick and dirty hack to get everything back in business was putting an entry in the hosts file on the Spark server for .com (where as the longer term fix is talking with our current net admin and getting them to rebuild the AD forest). Hopefully this helps someone in the future.