I’‘m attempting to upgrade to 3.0.1, and I’‘ve hit an ugly snag with LDAP authentication. I’‘ve put all my modified files (conf/, logs/, embedded-db/, resources/security/) into the new Wildfire directory, and done the switcheroo. Starting Wildfire is fine, and there don’'t appear to be any errors there. So - configuration appears to be exactly the same, nothing has changed with the LDAP server.
However, I get LDAP authentication errors in debug.log:
2006.07.16 22:07:26 Caught a naming exception when creating InitialContext javax.naming.AuthenticationException: LDAP: error code 49 - Invalid Credentials
Wildfire has a connection open to the LDAP server, and I can authenticate using the command line LDAP tools from the Wildfire host.
Anyone seen similar issues? Please tell me I’'m not hitting a bug in 3.0.1!
I’'m also seeing the same thing. 2.6.2 works fine with LDAP but 3.0.1 fails. Did anyone find a fix or workaround for this?
Also a problem in the current 3.1.0 alpha build. Has anyone tested it with OpenLDAP?
The only difference I can see in the requests to the LDAP server are the addition of quotes in the DN for the bind request (not for the initial seach request).
for Wildfire 2.6.2 (works): DN: uid=username,ou=Users,dc=foo,dc=com
for Wildfire 3.1.0 (fails); DN: uid=“username”,ou=“Users”,dc=foo,dc=com
I think this is due to the change made in 3.0.1 that Gato and I worked on to fix some things with presence and integration with Windows AD. Try setting the property ldap.wrapUserDN to false and see if that helps.
Message was edited by: Andy250
Thanks Andy - the property is actually ldap.encloseUserDN. I set it to false in the wildfire.xml and LDAP logins now work (on 3.1.0 alpha at least).
I’'ll test it out on 3.0.1 and see what happens.
Your reply was much appreciated. I want to use 3.0.1 to see if it fixes some of the presence issues that we are currently seeing with 2.6.2 when using shared rosters.
Authenticaion against OpenLDAP verified with 3.0.1
Unfortunately the problems with presence are still showing up - at least while using shared LDAP groups. I’'ve also tried 3.1.0a with the same result.
I’'ll run some tests using shared rosters without using LDAP groups to see what happens and report back.
I’‘ve tested both 3.0.1 and 3.1.0a using non-LDAP groups shared out to everyone’'s roster. Seems to be working fine.
So it looks like the LDAP shared groups is still broken after the fixes for shared rosters in 3.0.1
Rock on, that works! Thanks very much.