1 Reply Latest reply on Nov 18, 2006 6:41 PM by zzzz8

Hi,

When a user attempts to login using LdapExtLoginModule, I get the following error:

```2006-11-17 11:38:41,041 DEBUG [org.jboss.security.auth.spi.LdapExtLoginModule] Bad password for username=johndoe
javax.naming.CommunicationException: mycompany.com:636 [Root exception is java.net.SocketException: Default SSL context init failed: null]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:194)
at com.sun.jndi.ldap.LdapClient.<init>(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.<init>(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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:491)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:257)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol\$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
Caused by: java.net.SocketException: Default SSL context init failed: null
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:311)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:181)
... 43 more
2006-11-17 11:38:41,041 TRACE [org.jboss.security.plugins.JaasSecurityManager.MyCompanyLDAP] Login failure
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:491)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:257)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol\$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
Caused by: javax.naming.CommunicationException: mycompany.com:636 [Root exception is java.net.SocketException: Default SSL context init failed: null]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:194)
at com.sun.jndi.ldap.LdapClient.<init>(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.<init>(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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
... 27 more
Caused by: java.net.SocketException: Default SSL context init failed: null
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:311)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:181)
... 43 more```

Here's my configuration:

```<application-policy name="MyCompanyLDAP">
<authentication>
<!--
Some AD configurations may require searching against
the Global Catalog on port 3268 instead of the usual
port 389. This is most likely when the AD forest
includes multiple domains.
-->
<module-option name="java.naming.provider.url">ldaps://mycompany:636</module-option>
<module-option name="bindDN">domain\tester</module-option>
<module-option name="baseCtxDN">dc=mycompany,dc=com</module-option>
<module-option name="baseFilter">(sAMAccountName={0})</module-option>
<module-option name="rolesCtxDN">ou=accounts,dc=mycompany,dc=com</module-option>
<module-option name="roleFilter">(sAMAccountName={0})</module-option>
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">cn</module-option>
<module-option name="roleRecursion">-1</module-option>
<module-option name="searchScope">SUBTREE_SCOPE</module-option>
<module-option name="java.naming.security.protocol">ssl</module-option>
</authentication>
</application-policy>```

Another interesting thing is that if I remove the java.naming.security.protocol property (i.e. do not use SSL) in the configuration and change the provider URL to ldap://mycompany:389, then it works! Obviously, this begs the question - does my company support ldaps listening at port 636. And the logs don't indicate anything wrong with the trust store...

I found the problem - and it took quite a while to solve because the exception stack traces weren't very helpful...

It seems if one uses a JBoss URL or directory property in properties service (in this case, to specify the trust store) - and if the property contains spaces (e.g. C:\Program Files\JBoss4.0.5.GA), then the directory location will NOT be resolved correctly. I tested this on my Windows machine (Windows XP) and confirmed this problem.

For example, in my properties-service.xml file, the following doesn't work because the resolved path is c:\program files\jboss-4.0.5.GA\server\default\deploy\conf:

```<attribute name="Properties">
javax.net.ssl.trustStore=\${jboss.server.home.dir}/conf/my.truststore
javax.net.ssl.keyStore=.\${jboss.server.home.dir}/conf/my.keystore
</attribute>```

So one has to use a relative path in this case (which doesn't contain any spaces):

```<attribute name="Properties">
javax.net.ssl.trustStore=../server/default/conf/my.truststore