[BUG?] ldap over ssl breaks on 2.1.4

Unable to log in via the admin consol, or as a user to the jabber service. Below is the only error I’'ve been able to glean from my logs

-jason

2005.06.03 09:35:25 Caught a naming exception when creating InitialContext

javax.naming.CommunicationException: servername.com:636 [Root exception is java.net.SocketException: Unconnected

sockets not implemented]

at com.sun.jndi.ldap.Connection.(Connection.java:194)

at com.sun.jndi.ldap.LdapClient.(LdapClient.java:118)

at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1578)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2596)

Environment:: Redhat Workstation 3.0 w/ myql 4.1 as the database. Java 1.5.0-2 and 1.5.0-3.

Config ::

servername.com

636

uid

cn

mail

ou=people,dc=domain,dc=com

true

true

Jason,

Is your LDAP server really at “servername.com”? You need to use the correct server name to make LDAP work. Is your baseDN configured correctly as well? You might want to talk to your LDAP administrator to get the right values.

Regards,

Matt

Is your LDAP server really at “servername.com”?

You need to use the correct server name to make LDAP

work. Is your baseDN configured correctly as well?

You might want to talk to your LDAP administrator to

get the right values.

Sorry… I just have a habit of obfuscating internal server names and our ldap structure when posting to a forum

And, the real config works perfectly well under 2.1.3. The config also works if I switch to non-ssl on port 389. I also double as the ldap administrator.

-jason

Jason,

Ok, makes sense and thanks for clarifying. So first question – do non-SSL connections work under 2.1.4? Which LDAP server are you using?

Thanks,

Matt

yes, if I configure ldap to use port 389 w/o ssl… it works fine under 2.1.4

I’'m using openldap 2.2.26

Here are the changes that were made in the LDAP code between 2.1.3 and 2.1.4:

  1. Added following code:

// Specify timeout to be 10 seconds

env.put(“com.sun.jndi.ldap.connect.timeout”, “10000”);

  1. ldap.ldapDebugEnabled is now ldap.degugEnabled

Number 2 can’‘t be the cause of this issue, could #1? Is there more to the stack trace than what you originally pasted? I’'d like to see exactly where the error happens.

Regards,

Matt

2005.06.03 09:35:25 Caught a naming exception when creating InitialContext

javax.naming.CommunicationException: servername.com:636 [Root exception is java.net.SocketException: Unconnected

sockets not implemented]

at com.sun.jndi.ldap.Connection.(Connection.java:194)

at com.sun.jndi.ldap.LdapClient.(LdapClient.java:118)

at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1578)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2596)

at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:283)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)

at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)

at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)

at javax.naming.InitialContext.init(InitialContext.java:223)

at javax.naming.InitialContext.(InitialContext.java:197)

at javax.naming.directory.InitialDirContext.(InitialDirContext.java:82)

at org.jivesoftware.messenger.ldap.LdapManager.checkAuthentication(LdapManager.jav a:278)

at org.jivesoftware.messenger.ldap.LdapAuthProvider.authenticate(LdapAuthProvider. java:91)

at org.jivesoftware.messenger.auth.AuthFactory.authenticate(AuthFactory.java:97)

at org.jivesoftware.messenger.handler.IQAuthHandler.login(IQAuthHandler.java:221)

at org.jivesoftware.messenger.handler.IQAuthHandler.handleIQ(IQAuthHandler.java:14 1)

at org.jivesoftware.messenger.handler.IQHandler.process(IQHandler.java:48)

at org.jivesoftware.messenger.IQRouter.handle(IQRouter.java:202)

at org.jivesoftware.messenger.IQRouter.route(IQRouter.java:73)

at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:65)

at org.jivesoftware.messenger.net.SocketReadThread.readStream(SocketReadThread.jav a:285)

at org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:105)

Caused by: java.net.SocketException: Unconnected sockets not implemented

at javax.net.SocketFactory.createSocket(SocketFactory.java:97)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.sun.jndi.ldap.Connection.createSocket(Connection.java:285)

at com.sun.jndi.ldap.Connection.(Connection.java:181)

… 24 more

I just upgraded to 2.1.4 a few minutes ago and caught the exact same problem.

I also seem to have this same problem. My LDAP server is using Active Directory on a windows 2000 machine. I have an exact copy of my jive config file from 2.1.3 and i can’'t seem to log in on the 636 port but the 389 port works great

Same problem here. How about someone who has it working give us the details of their configuration?

And I was going to demo this to the CIO tomorrow. Sigh.

In case it’'s relevant, my setup is OpenLDAP 2.2.13 on RHEL3.

So, my theory at this point is that the timeout code busts SSL support. I don’‘t have access to a test environment at the moment, but I built a new JAR file that disables the timeouts when using SSL (attached to this message). Just replace your existing JAR with this one in the lib directory of your Jive Messenger 2.1.4 install. If this fix works, we’'ll make a 2.1.5 release with just this fix tomorrow. Please let me know how it goes.

Thanks,

Matt

UPDATE: Ack, the attachment didn’‘t work. I’'ll post another message with a link in a second.

Ok, the download is at

http://www.jivesoftware.org/messenger/messenger.jar

If the file downloads as a “.zip”, be sure to rename it to “.jar”.

-Matt

That fixed it for me. Thanks! Good luck trying to figure out why…

I’‘m happy to do regression testing in the future. I’'m talking to novell ldap in production, and can of course run an openldap server too.

works for me as well.

Worked for me too… thanks

Thanks everyone for testing! We’'ll get this fix officially into a 2.1.5 release in the next couple of days. I want to see if we can get the GAIM ssl bug fixed at the same time…

Regards,

Matt

getting both of these would officially make you my hero… particularly if the gaim fix also fixes trillian