powered by Jive Software

Openfire 4.2.1 a Active Directory 2008R2: First login fail, second login succeed

Good afternoon,
Using in preproduction environnement:
OpenFire 4.2.1 (JRE Embedded) - Windows Server 2008 R2 / amd64, linked with Active Directory on a Win 2016 box (no SSO).

I’ve noticed that when a client IM connects to my OpenFire server:

  • The first attempt to log on the openfire box fails invariably, with message “Not Authorized” on the client
  • Re connect after few seconds succeed. Just click on the “Activate” button (Pidgin) or to reconnect (Spark) log on successfully the IM client.
    (tried both Pidgin 2.12.0 and spark_2_8_3, git the same errors)

I’ve set the “ldap.connectionPoolEnabled” to “false”, with no change to result.
The only related error in OpenFire errorlog "org.jivesoftware.openfire.ldap.LdapGroupProvider - Could not find user in LDAP “username”.
On the client side, the debug show “failure xmlns=“urn:ietf:params:xml:ns:xmpp-sasl” not-authorized/ /failure” - case of Pidgin -
My LDAP configuration points to a specific domain controller (by IP) and not to a domain name.

All suggestions are welcome!

do you have more than 1000 objects in your AD? if so, are you using the search filter to list only the users? Also, you could add the system property call ldap.pagedResultsSize with a value of 1000

Thanks Speedy,
Yes I have 1739 objects in AD database. This count all kind of objects, not users only. Users type only counts less than 1000.
I’ve set up the system property ldap.pagedResultsSize set at 1000, but the issue persists.
I’ve noticed that logging into the web console is affected too with the same issue.
It seems to be a Openfire and AD communication issue. May be a first method fails and then fallback to secondary methods of authentication?
Digging in it, i’ve set the prperties sasl.mechs.00001 and sasl.mechs.00002 to PLAIN, but don’t resolve.
Any idea?

im out of ideas. did you restart openfire after adding the system property? you may want to run wireshark on your openfire server to see if anything out of the ordinary shows up.

Yes, i think i must make some deep packet analysis and also at AD level and I will be back.


A few clarification points with connecting Openfire to AD (from my experience):
When installing Openfire via its wizard:

• When in the ‘Server Settings’ page, within the ‘XMPP Domain Name’ setting, use the FQDN and not the short NetBIOS name. This will assist when chatting between different chat servers.

• When in the ‘Database Settings’ page, within the ‘Database URL’ settings, enter:
o For AD joined chat server:


o For standalone, non-AD joined chat server:

• When in the ‘Profile Settings: User Mapping’, change the ‘UserName Field’ from ‘uid’ to ‘sAMAccountName’, as the AD user object doesn’t contain a ‘uid’ attribute.

• The older version of Openfire that I’m using by default only looks for all AD User and Group objects within the default ‘Users’ Container (not OU) and computers objects within the ‘Computers’ Container (not OU). So as a test, when in the ‘Profile Settings: Connection Settings’ page, try temporarily changing the ‘Based DN’ to this ‘Users’ Container and move a test chat user from its original custom OU up into the ‘Users’ Container. It should find it there -> However, no AD in the world leaves their user objects there, as you can’t apply Group Policies to them. So to get Openfire to look for my AD Chat User, Group & Computer objects within my custom created OU’s, during the installation wizard, I had to perform a forward and backward web browse page process, where I had to keep changing the ‘Based DN’ path save it, browse forward, perform the operation, then browse back again and change the ‘Based DN’ to the next required OU path, save it and move forward again -> Yes, a very ugly work-around for an product that is not fully AD aware.

I hope that works for you,


1 Like