Upgrade from Openfire 3.6.2 to 3.6.3 breaks ldap AD integration?

We have been unsuccessful at upgrading a working Openfire 3.6.2-1 server with known-good LDAP MS AD integration to Openfire 3.6.3-1 without breaking the LDAP integration.

Scenario

Openfire 3.6.2-1 is installed on a CentOS x86_64 system running MySQL. Users are authenticated via LDAP integration with MS Active Directory.

When the system is upgraded via in-place upgrade to Openfire 3.6.2-1 all of the configuration information is preserved but the LDAP integration breaks. The “in-place upgrade” was performed using “rpm -U openfire-3.6.3-1.i386.rpm.” When this failed, we also tried a fresh install of 3.6.3-1 from scratch. The results were identical: at “Step 1 of 3” it passed the test of connecting the LDAP server but at “Step 2 of 3” it failed to find any users in the directory.

What do I mean by “the LDAP integration breaks?”

Immediately after the upgrade, it is no longer possible to access the admin console except by changing true to false in /opt/openfire/conf/openfire.xml.

After changing true to false, we access the admin console and go to edit the LDAP settings.

One effect of making this change (toggling the value of the setup boolean) is apparently to reset the authentication mechanism to the default and put the admin user back into the setup dialog process. That setup process includes the “Profile Settings” screens.

Page 1 of Profile Settings: "Directory Server (LDAP)" is selected.

At “Step 1 of 3: Connection Settings” we make sure that the server type, host, port, base DN, administrator DN and passowrd are correct.

The “test settings” button returns “Status: Success!: A connection was successfully established to the LDAP server using the settings above.” (see attached file “connection_settings1.jpg”

As “Step 2 of 3: User Mapping” we make sure that the Username field, user filter, and vCard settings are correct.Here, though, when we click on the “test settings” button it reports “Status: Error. No users were found using the specified configuration. Try changing the base DN, the user filter, or username field” (see attached file “user-mapping.jpg”). We tried making any sensible changes, but the original values were correct and are known to work with 3.6.2-1, and none of the different values we tried helped.

For the known good settings at “Step 2 of 3” under Openfire 3.6.2-1, see attached file “362-good.jpg.”

For the settings at “Step 2 of 3” under Openfire 3.6.3-1, see attached file 363-bad.jpg."

As you can see, they are identical.

The settings on the page labeled “Step 1 of 3” are also identical between our Openfire 3.6.2-1 configuration (which works) and our Openfire 3.6.3-1 configuration (which fails to find users in the directory).

We also tried installing Openfire 3.6.3-1 from scratch. And we tried setting up a new Openfire 3.6.2-1 server. So far Openfire 3.6.3-1 consistently fails to find any users in the Active Directory and Openfire 3.6.2-1 consistently succeeds at retrieving users at random from the directory at “Step 2 of 3.”

We must be missing something. I’ve been over this again and again, and I enlisted the assistance of the team here that supports our Active Directory. They inspected all of our settings and concur that it should be working as configured under Openfire 3.6.3-1.But it isn’t.

What are we missing?

Thank you for any assitance you can provide.




No help here. Just chiming in to say thanks for posting. I was about to upgrade tomorrow during maint. window.

I use AD LDAP authentication and have had several issues regarding AD configuration, default values not posting, and undocumented property configuation location. I will watch this closely prior to upgrade.

Thanks again for your post.

please post your baseDN.

The base DN we are using (with both Openfire 3.6.2-1 and 3.6.3-1) is:

dc=darksideproductions;dc=net

As I mentioned, in the course of troubleshooting this we engaged the assistance of the team that supports our Active Directory. They suggested also trying this base DN:

ou=personnel;dc=darksideproductions;dc=net

We verified using the Active Directory browser that “ou=personnel” corresponds to a valid AD node.

They explained that while both base DNs should work, the former also includes entities that don’t correspond to actual user accounts (entries for exchange, for instance).

We tested the “ou=personnel;dc=darksideproductions;dc=net” base DN with 3.6.2-1 and found that this base DN performed exactly as they predicted, i.e. during the random user retrieval test it retrieved only actual users instead of also including technical accounts.

In our efforts to try to get 3.6.3-1 to successfully retrieve users from Active Directory, we first tried the “dc=darksideproductions;dc=net” base DN, then tried the “ou=personnel;dc=darksideproductions;dc=net” base DN. Currently we have it set back to the “dc=darksideproductions;dc=net” base DN.

try replacing the semicolons with commas

Thanks, Todd, for the suggestion.

Replaced the semicolons with commas in the base DN.

No change in the results. The “test settings” button at Step 1 of 3 still reports

Test: Connection Settings
Status: Success!
A connection was successfully established to the LDAP server using the settings above. Close this test panel and continue to the next step.

And the “test settings” button at Step 2 of 3 still reports:

Test: User Mapping
A random profile is selected for you to review. Bold fields with no value mean that an error may have been found. To view another profile click ‘Next random profile’. When you are finished close this window.

Status: Error
No users were found using the specified configuration. Try changing the base DN, user filter or username field.

please post screenshots of each screen with out test dialogs blocking the view.

Attached to the original posting is a file named connection_settings1.JPG and a file named user-mapping.JPG.

The former is a screenshot of the results of the Step 1 of 3 “test settings” button. The latter is a screenshot of the results of the Step 2 of 3 “test settings” button.

with out the tests blocking the view. those tests are the results of bad settings. we need to see the settings.

We also tried replacing the Openfire 3.6.3-1 /conf/openfire.xml file with our original (working) /conf/openfire.xml file from Openfire 3.6.2-1 and then restarting the openfire daemon.

The results were the same as when we did the in-place upgrade (with rpm -U). That is to say that we immediately lost the ability to authenticate and had to change the tag in openfire.xml to toggle the system back into setup mode in order to gain access to the admin console pages, and from there we had results identical to all of our previous results: at Step 1 of 3 the settings test passes and at Step 2 of 3 the settings test fails (it fails to retrieve users from Active Directory).

Attached to the original post there is a file named 362-good.JPG and a file named 363-bad.JPG.

The former is a screenshot of all of the settings at Step 2 of 3 (user settings) from Openfire 3.6.2-1, in which the LDAP/AD integration works fine. The latter is a screenshot of all of the settings at Step 2 of 3 (user settings) from Openfire 3.6.3-1, in which the LDAP/AD integration isn’t working.

I didn’t originally post screenshots of the settings that appear on Step 1 of 3. I’ll attach them now.

Our matrix of tests included both semicolons and commas as delimiters, both our AD admin user and our LDAP admin user.

connectionAsemi_admin.jpg – Openfire 3.6.3-1 showing base DN with semicolons and AD admin user.

connectionBcomma_admin.jpg - Openfire 3.6.3-1 showing base DN with commas and AD admin user

connectionCsemi_ldapuser.jpg - Openfire 3.6.3-1 showing base DN with semocolons and LDAP admin user

connectionDcomma_ldapuser.jpg - Openfire 3.6.3-1 showing base DN with commas and LDAP admin user

The screenshot connectionCsemi_ldapuser.jpg was taken with Openfire 3.6.3-1 but these are the identical settings we used with Openfire 3.6.2-1, which worked. Instead of attaching a screenshot of the same screen from Openfire 3.6.2-1, I’m attaching a copy of the original openfire.xml that we used with 3.6.2-1 (with the password removed, of course).





openfire_xml.txt (4970 Bytes)

Make sure you use commas

Make sure the AdminDN is one of the accepted formats (win2kdomain\username, username@domain.com, cn=username,ou=…)

Make sure your host is a fully qualified domain name for a server (server.domain.com)

Make sure the adminDN has rights to read LDAP

New screenshot communicationE.jpg

Make sure you use commas

… check

Make sure the AdminDN is one of the accepted formats (win2kdomain\username, username@domain.com, cn=username,ou=…)

The admin DN is in the form win2kdomain\username

Make sure your host is a fully qualified domain name for a server (server.domain.com)

… check

Make sure the adminDN has rights to read LDAP

… check

Tested … this time it passed.
Tried non-fully-quallified domain named and it failed.

Changing the hostname to a fully-qualified name resolved the problem.

Many thanks, Todd, for such prompt and professional assistance.

I just want to say that I had this exact problem and your post was able to help me as well.

Many thanks.

Stupid commas