I’m assuming this is a bug in the LDAP connection setup?
I upgraded my 3.5.2 installation to 3.6.0 and noticed immediately that no one was able to login. I didn’t do a backup, but didn’t worry either since this is an AD based install I don’t loose almost anything really.
I then uninstall 3.6.0 and nuked the install folder so the install started fresh. I went through the setup and it passes the connection test on step 1 of LDAP configuration. I’m using the same Base DN and Administrator DN as on my old setup so it is the same. Once I get to step 2 and later it errors on on tests with no changes from the defaults (as I never needed to change them before).
I have another server setup with 3.5.2 on it and it works fine. So it seems the problem is limited to 3.6.0
Both the AD Domain Controller and the OpenFire IM server are running Windows Server 2008.
Upgrade from 3.5.2 to 3.5 with AD authentication worked fine for me. (I use the Debian package). The Problem that we have is that some users can’t Login, while others could.
That happens if such an User Log
2008.09.04 08:35:31 LdapManager: Created context values, attempting to create context…
2008.09.04 08:35:31 LdapManager: Caught a naming exception when creating InitialContext
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece]
I ran into the same issue with version 3.6.0a on Ubuntu Hardy Heron, with AD on Windows Server 2003. After reading another thread here http://www.igniterealtime.org/community/message/178102#178102, I tried putting all the values into quotation marks and it worked. So if you had dc=companyname,dc=com, now you need to use dc=“companyname”,dc=“com”, etc.
I had the same type of issue, but am using Windows 2k3 as the LDAP instead of 2k8.
I had pretty much copied and pasted the old DNs into the new setup. I started with my target BaseDN and removed ou’s until i only had dc’s. So Top Level worked which meant there was something wrong when seperateing the dc with the ou.
I noticed that in 3.5.2, my BaseDN was: ou=MyBusiness;dc=company,dc=internal
I decided that I would try a comma instead of the semi-colon in there, and Tada!
After I changed my BaseDN to the same thing but replaceing the semi-colon, with a comma. Test 2, and Test 3 Worked as expected.
Old Config: BaseDN= ‘ou=MyBusiness;dc=company,dc=internal’
New Config: BaseDN= ‘ou=MyBusiness,dc=company,dc=internal’
I am still having and issue loggin into the Admin Console after I restart the openfire service however, and this may be related.
Give it a shot, and like you said at this point you are not really loosing much data because it’s all in the LDAP anyway that is the way i approached this as well…