powered by Jive Software

Openfire 4.4.0 suddenly unable to connect to Active Directory

Good afternoon,

Our Openfire server has been plugging along swimmingly for months now. Yesterday afternoon, it started telling everyone “invalid username or password”, and no one has been able to log in since.

Of course, I was unable to log into the admin console, so I got in using a onetimetoken. As far as I can tell, everything is fine. Our SSL certificate is up to date, we’re on the lastest version of Openfire, and the logs are reporting that people are failing authenticating, but I can’t find any error messages anywhere that tell me why people can’t authenticate.

Looking on the auth logs on our domain controller, I don’t see my Openfire user even trying to authenticate against Active Directory, or that the Openfire server is trying to connect at all.

I can telnet to port 389 on the domain controller from the Openfire server, and it connects just fine. Also my Base DN and Administrative DN are correct, and I’ve verified that the Active Directory account that Openfire uses is not locked.

Here is a sanitized snippet from the debug log, of what it looks like every time someone tries to log in:

2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Trying to find a user's DN based on their username. sAMAccountName: <someuser>, Base DN: DC=<domainname>,DC=<suffix>...
2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Creating a DirContext in LdapManager.getContext()...
2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: connection pooling was requested but has been disabled because of StartTLS.
2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Created hashtable with context values, attempting to create context...
2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: ... StartTlsRequest
2019.07.17 15:30:04 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Exception thrown when searching for userDN based on username '<someuser>'
javax.naming.ServiceUnavailableException: [LDAP: error code 52 - 00000000: LdapErr: DSID-0C091293, comment: Error initializing SSL/TLS, data 0, v3839]

There is a bit there about SSL/TLS failing, but I can’t find any more details about that.

This is on a Linux server running Debian Stretch, fully up to date.

I’ve been messing with this since about 8:30 this morning, and I’ve got nowhere with it.

Any ideas what to try next?

Also, I did change true to false, in openfire.xml, and went through the initial setup procedure again. When I get to the LDAP portion and hit the test button, I get this:

 [LDAP: error code 52 - 00000000: LdapErr: DSID-0C091293, comment: Error initializing SSL/TLS, data 0, v3839]

So it’s something to do with SSL/TLS, but I don’t know where to look to pursue that.

when you set up the LDAP portion, for host, be sure you are using the CN that is being presented by the cert. not the ip. it may be the FQDN of your dc or the netbios name.

Thanks for the response, unfortunately the behavior is the same.

This morning I restored the Openfire server VM from a June backup, which is also an earlier version of Openfire, but the problem is still there, which makes think that the issue is on the AD side. No updates have been applied to that server since the 10th, and no other configuration changes have been made, so why this didn’t pop up until the 16th is a little perplexing.

This is an AD problem, not an Openfire problem.

We’re getting lots of Event ID 36886 on the DC. Information about that event is here.

Basically, we have no root CA on our system, so AD is not accepting SSL LDAP connections. The only solution is to install a root CA and regenerate SSL certs, which isn’t something we want to mess with presently.

Since this data is only being transmitted inside our network, and the passwords being sent are hashed anyway, I’ve simply disabled ldap.startTlsEnabled in Openfire for now, and we’ll address this in a few weeks when we have less on our plate.

Again though, why this issue suddenly popped up two days ago, when the system has been functioning fine for months as-is, is a bit of a head scratcher.

instead of using startTLS, you could try connecting to port 636 and using ldap(s). this gives you the beneficent of connection pooling as well…

I’ll check that out, perhaps tonight after hours. Thanks again for your responses!