[cas-user] SocketTimeout

[Perry Hoekstra]

I am working on getting CAS (3.5.1) to authenticate to an Active Directory server. When I attempt to authenticate (using the Login web page), I see the following in my cas.log file:

2013-01-17 06:57:45,961 ERROR [org.jasig.cas.authentication.AuthenticationManage
rImpl] - org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler threw error a
uthenticating [username: xxxxxxxx]
org.springframework.dao.DataAccessResourceFailureException: Failed to borrow DirContext from pool.; nested exception is org.springframework.ldap.CommunicationException: activedirectoryserver.foo.com:389; nested exception is javax.naming.CommunicationException: activedirectoryserver.foo.com:389 [Root exception is java.net.SocketTimeoutException: connect timed out]
at org.springframework.ldap.pool.factory.PoolingContextSource.getContext(PoolingContextSource.java:425)
at org.springframework.ldap.pool.factory.PoolingContextSource.getReadOnlyContext(PoolingContextSource.java:401)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:287)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:361)
at org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler.authenticateUsernamePasswordInternal(BindLdapAuthenticationHandler.java:89)
at org.jasig.cas.authentication.handler.support.AbstractUsernamePasswordAuthenticationHandler.doAuthentication(AbstractUsernamePasswordAuthenticationHandler.java:71)
at org.jasig.cas.authentication.handler.support.AbstractPreAndPostProcessingAuthenticationHandler.authenticate_aroundBody2(AbstractPreAndPostProcessingAuthenticationHandler.java:85)

...

I created a small Java/LDAP program that hits the Active Directory server and it executes fine so I know the Active Directory server is visible.

Because it is having problems getting a DirContext from the pool, my assumption is that it is either a bad property in the cas.properties file:

ldap.pool.minIdle=3
ldap.pool.maxIdle=5
ldap.pool.maxSize=10
ldap.pool.maxWait=10000
ldap.pool.evictionPeriod=600000
ldap.pool.idleTime=1200000

ldap.pool.testWhileIdle=true

ldap.pool.testOnBorrow=false

server.name=https://casserver.foo.com:8443
server.prefix=${server.name}/cas
cas.securityContext.serviceProperties.service=${server.prefix}/services/j_acegi_
cas_security_check

host.name=cas01

cas.securityContext.serviceProperties.adminRoles=ROLE_ADMIN
cas.securityContext.casProcessingFilterEntryPoint.loginUrl=${server.prefix}/login
cas.securityContext.ticketValidator.casServerUrlPrefix=${server.prefix}
cas.securityContext.casProxyTicketValidator.casValidate=${server.prefix}/proxyValidate

cas.securityContext.status.allowedSubnet=127.0.0.1

cas.themeResolver.defaultThemeName=cas-theme-default
cas.viewResolver.basename=default_views

database.hibernate.dialect=org.hibernate.dialect.OracleDialect


or a bad entry in the contextSource section of the deployerConfigContext.xml file:


<bean id="contextSource" class="org.springframework.ldap.core.support.LdapCo
ntextSource">
<property name="pooled" value="false" />
<property name="url" value="ldap://activedirectoryserver.foo.com" />
<property name="userDn" value="cn=adminuser,ou
=OUUnit,dc=domain,dc=com"/>
<property name="password" value="somepassword"/>

<property name="baseEnvironmentProperties">
<map>
<entry key="com.sun.jndi.ldap.connect.timeout" value="3000" />
<entry key="com.sun.jndi.ldap.read.timeout" value="3000" />
<entry key="java.naming.security.authentication" value="simple"
/>
</map>
</property>
</bean>

Thoughts on what entry I have wrong that I cannot get a pooled DirContext?
--
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> org.springframework.dao.DataAccessResourceFailureException: Failed to borrow DirContext from pool.; nested exception is org.springframework.ldap.CommunicationException: activedirectoryserver.foo.com:389; nested exception is javax.naming.CommunicationException: activedirectoryserver.foo.com:389 [Root exception is java.net.SocketTimeoutException: connect timed out]

Your directory is taking too long to negotiate the TCP handshake based
on your specified connection timeout value:

> <entry key="com.sun.jndi.ldap.connect.timeout" value="3000" />

Since this is a pooled connection, you could consider increasing the
timeout period since it would only affect provisioning new connections
in the pool (and not on ever LDAP operation). I would not recommend
increasing beyond 10s in production. It would be better to investigate
why your directory is taking so long to connect. If you find that
increasing the timeout to some outlandish value, say 60s, has no
effect, then it's likely a deeper issue (e.g. networking problem,
firewall, etc).

M

[Perry Hoekstra]

That was it, I even tried your suggestion of 60s and it still times out. Thoughts on how to diagnose the issue? I used JXplorer with the same authentication and my Java/LDAP program, both come back in about 2s. Would TRACE level on an entry in log4j give me the entry going to the Active Directory that I can forward to the AD admin?

Thanks,

Perry Hoekstra

[Marvin Addison]

> Thoughts on how to diagnose the issue?

I would recommend tcpdump on the CAS server to troubleshoot a purely
networking problem. If you see a successful three-way handshake, then
you should look at SSL/TLS issues by performing a Java SSL trace [1].
With one or both of those you should have some evidence to present to
your networking or AD admins.

M

[1] https://wiki.jasig.org/display/CASUM/SSL+Troubleshooting+and+Reference+Guide,
"When All Else Fails"

[Scott]

Your AD could be configured to only accept ldaps/SSL connections, which would be port 636.  Also, you might check the firewall policy on your AD server to make sure it would accept connections from your CAS server's IP.

On Thu, Jan 17, 2013 at 11:45 AM, Marvin Addison <marvin....@gmail.com> wrote:

> Thoughts on how to diagnose the issue?

I would recommend tcpdump on the CAS server to troubleshoot a purely
networking problem. If you see a successful three-way handshake, then
you should look at SSL/TLS issues by performing a Java SSL trace [1].
With one or both of those you should have some evidence to present to
your networking or AD admins.

M

[1] https://wiki.jasig.org/display/CASUM/SSL+Troubleshooting+and+Reference+Guide,
"When All Else Fails"

--
You are currently subscribed to cas-...@lists.jasig.org as: scot...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user