Password changes ignored by CAS

11 messages

Password changes ignored by CAS

Reply Threaded

Hi,
We're using CAS to provide SSO for JBoss Portal using OpenDS as the LDAP.

I've setup CAS to use OpenDS for authentication as shown below:

<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list>
<value>ldap://hostname:port</value>
</list>
</property>
<property name="userDn" value="user"/>
<property name="password" value="password"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>

<property name="authenticationHandlers">
...
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler">
<property name="filter" value="cn=%u" />
<property name="searchBase" value="dc=xx,dc=com" />
<property name="contextSource" ref="contextSource" />
</bean>
...
</property>

I am able to authenticate using the users in the ldap at the CAS login page, but I'm getting some strange behavior with passwords.

If I change a password for a user I am able to authenticate through the CAS login page with EITHER the old or new password. When using an ldap browser the old password immediately does not work. I can wipe the cookies/session and the old password still works through the CAS login. The only way I can force the old password to stop working through the CAS login is by restarting the ldap server.

Admittedly I am new to CAS, so I'm probably missing something key here. But I'm assuming that changes to the ldap tree should take effect pretty quickly on the CAS side.

Another strange (and possibly related) issue is that the CAS login says my 'admin' user is invalid even though I verified the 'admin' user exists and works through my ldap browser. All other users are able to be authenticated at the CAS login just fine.

Any help would be appreciated. Please let me know if I need to post more information. Thanks.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Scott Battaglia-2

Re: Password changes ignored by CAS

Reply Threaded

Did you try disabling pooling and see if that clears up your password issue?

Cheers,
Scott

On Sun, Jun 28, 2009 at 6:54 PM, Chris Kantzer <[hidden email]> wrote:

Hi,
We're using CAS to provide SSO for JBoss Portal using OpenDS as the LDAP.

I've setup CAS to use OpenDS for authentication as shown below:

<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list>
<value>ldap://hostname:port</value>
</list>
</property>
<property name="userDn" value="user"/>
<property name="password" value="password"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>

<property name="authenticationHandlers">
...
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler">
<property name="filter" value="cn=%u" />
<property name="searchBase" value="dc=xx,dc=com" />
<property name="contextSource" ref="contextSource" />
</bean>
...
</property>

I am able to authenticate using the users in the ldap at the CAS login page, but I'm getting some strange behavior with passwords.

If I change a password for a user I am able to authenticate through the CAS login page with EITHER the old or new password. When using an ldap browser the old password immediately does not work. I can wipe the cookies/session and the old password still works through the CAS login. The only way I can force the old password to stop working through the CAS login is by restarting the ldap server.

Admittedly I am new to CAS, so I'm probably missing something key here. But I'm assuming that changes to the ldap tree should take effect pretty quickly on the CAS side.

Another strange (and possibly related) issue is that the CAS login says my 'admin' user is invalid even though I verified the 'admin' user exists and works through my ldap browser. All other users are able to be authenticated at the CAS login just fine.

Any help would be appreciated. Please let me know if I need to post more information. Thanks.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

ckantzer

RE: Password changes ignored by CAS

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Removed <property name="pooled" value="true"/>

Now only the new passwords work, thanks.

Now I’d like to know why it worked and why you’d want pooling to ever be set?

Also, any idea why it doesn’t like my admin user?

From: Scott Battaglia [mailto:[hidden email]]
Sent: Sunday, June 28, 2009 9:55 PM
To: [hidden email]
Subject: Re: [cas-user] Password changes ignored by CAS

Did you try disabling pooling and see if that clears up your password issue?

Cheers,
Scott

On Sun, Jun 28, 2009 at 6:54 PM, Chris Kantzer <[hidden email]> wrote:

-- 

You are currently subscribed to [hidden email] as: [hidden email]

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

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Marvin Addison

Re: Password changes ignored by CAS

Reply Threaded

> Now I’d like to know why it worked and why you’d want pooling to ever be
> set?

This sort of pooling can be described as JNDI context pooling. The
"pooled" property sets the "com.sun.jndi.ldap.connect.pool" system
property to true; see
http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html for
more information. This is a very convenient way to perform LDAP
pooling and is suitable for the case where one is using the same
principal to perform operations.

In the case of BindLdapAuthenticationHandler, you're using the admin
user to perform the initial search for the DN of the authenticating
user, then switching to the DN/password of the authenticating user for
the following bind operation to verify credentials. You would _never_
want JNDI context pooling in that case because there is the
possibility for escalation of privileges under certain circumstances.

That said, you almost certainly want LDAP pooling for a production
deployment. Spring provides an object-based pooling strategy as of
1.3.0, PoolingContextSource, and you would want to use that for
pooling LDAP connections in CAS. We have tested this pretty
thoroughly in our dev and pre-production environments and are very
happy with it.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

ckantzer

RE: Password changes ignored by CAS

Reply Threaded

So in my case the pooled connection that used the old password was valid
and used again? Is the real reason the previous password worked is
because the application failed to close the context when I logged out?

So connection pooling is good to have for production, but I shouldn't
use pooling if I use BindLdapAuthenticationHandler? So are you saying
that BindLdapAuthenticationHandler should not be used for production?

I'm using BindLdapAuthenticationHandler because the users are spread out
over multiple trees in the ldap. Is there a way to use
FastBindLdapAuthenticationHandler but look in multiple trees?

Thanks for the quick response.

-----Original Message-----
From: Marvin Addison [mailto:[hidden email]]
Sent: Monday, June 29, 2009 8:58 AM
To: [hidden email]
Subject: Re: [cas-user] Password changes ignored by CAS

> Now I'd like to know why it worked and why you'd want pooling to ever
be
> set?

This sort of pooling can be described as JNDI context pooling. The
"pooled" property sets the "com.sun.jndi.ldap.connect.pool" system
property to true; see
http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html for
more information. This is a very convenient way to perform LDAP
pooling and is suitable for the case where one is using the same
principal to perform operations.

In the case of BindLdapAuthenticationHandler, you're using the admin
user to perform the initial search for the DN of the authenticating
user, then switching to the DN/password of the authenticating user for
the following bind operation to verify credentials. You would _never_
want JNDI context pooling in that case because there is the
possibility for escalation of privileges under certain circumstances.

That said, you almost certainly want LDAP pooling for a production
deployment. Spring provides an object-based pooling strategy as of
1.3.0, PoolingContextSource, and you would want to use that for
pooling LDAP connections in CAS. We have tested this pretty
thoroughly in our dev and pre-production environments and are very
happy with it.

M

--
You are currently subscribed to [hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Marvin Addison

Re: Password changes ignored by CAS

Reply Threaded

> So in my case the pooled connection that used the old password was valid
> and used again?

It's clearly related to the caching of something in the context. I
know virtually nothing about OpenDS, so I can't begin to speculate on
a more specific cause.

> Is the real reason the previous password worked is
> because the application failed to close the context when I logged out?

No. The lifecycle of LDAP contexts is completely independent of
login/logout regardless of pooling. I believe pooled JNDI contexts
don't have a termination period, but I'm not certain.

> So connection pooling is good to have for production, but I shouldn't
> use pooling if I use BindLdapAuthenticationHandler?

I'm saying you should not use JNDI context pooling via pooled="true",
which is not suitable for an authentication handler where principal
changes between a superuser and an ordinary one.

I have to retract my suggestion to use PoolingContextSource for
authentication. That is not suited, either, for switching principals
since it does not provide an interface for modifying the principal
after checking out from the pool. We use a separate
PoolingContextSource to pull additional attributes about the user from
LDAP after authentication. For authentication we use a non-pooled
LdapContextSource.

> I'm using BindLdapAuthenticationHandler because the users are spread out
> over multiple trees in the ldap.

You are using the correct handler, then.

> Is there a way to use FastBindLdapAuthenticationHandler but look in multiple trees?

The only use case for fast bind is when the DN of a user can be
directly constructed from the username, which wouldn't be possible if
you have users in multiple branches.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

ckantzer

RE: Password changes ignored by CAS

Reply Threaded

Thanks for the quick response Marvin. You've been a huge help.

Are there constraints or filters that would prevent an 'admin' user from being authenticated on the CAS side? It's odd since the user works fine when logging in directly to the app without going through CAS.

-----Original Message-----
From: Marvin Addison [mailto:[hidden email]]
Sent: Monday, June 29, 2009 9:50 AM
To: [hidden email]
Subject: Re: [cas-user] Password changes ignored by CAS

> So in my case the pooled connection that used the old password was valid
> and used again?

It's clearly related to the caching of something in the context. I
know virtually nothing about OpenDS, so I can't begin to speculate on
a more specific cause.

> Is the real reason the previous password worked is
> because the application failed to close the context when I logged out?

No. The lifecycle of LDAP contexts is completely independent of
login/logout regardless of pooling. I believe pooled JNDI contexts
don't have a termination period, but I'm not certain.

> So connection pooling is good to have for production, but I shouldn't
> use pooling if I use BindLdapAuthenticationHandler?

I'm saying you should not use JNDI context pooling via pooled="true",
which is not suitable for an authentication handler where principal
changes between a superuser and an ordinary one.

I have to retract my suggestion to use PoolingContextSource for
authentication. That is not suited, either, for switching principals
since it does not provide an interface for modifying the principal
after checking out from the pool. We use a separate
PoolingContextSource to pull additional attributes about the user from
LDAP after authentication. For authentication we use a non-pooled
LdapContextSource.

> I'm using BindLdapAuthenticationHandler because the users are spread out
> over multiple trees in the ldap.

You are using the correct handler, then.

> Is there a way to use FastBindLdapAuthenticationHandler but look in multiple trees?

The only use case for fast bind is when the DN of a user can be
directly constructed from the username, which wouldn't be possible if
you have users in multiple branches.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

ckantzer

RE: Password changes ignored by CAS

Reply Threaded

In reply to this post by Marvin Addison

It is not the principal to establish the initial LDAP connection.

By 'admin' user I mean just the default admin user that is created for
jboss portal. It is just another user called 'admin' and has admin
privileges. Obviously this user would go away in prod, but I'm curious
why this user is being singled out. The fact that it has a username and
password of 'admin' (dev environment only) and fails is suspicious when
all the regular users (ckantzer) authenticate just fine.

-----Original Message-----
From: Marvin Addison [mailto:[hidden email]]
Sent: Monday, June 29, 2009 12:47 PM
To: [hidden email]
Subject: Re: [cas-user] Password changes ignored by CAS

> Are there constraints or filters that would prevent an 'admin' user
from being authenticated on the CAS side?

I took "admin user" to mean the principal you used to establish your
initial LDAP connection, e.g. the value of userDN in the following XML
snippet you shared previously:

<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list>
<value>ldap://hostname:port</value>
</list>
</property>
<property name="userDn" value="user"/>
<property name="password" value="password"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>

I get the impression that you actually mean "admin user" in a
different sense. Can you clarify?

M

--
You are currently subscribed to [hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Marvin Addison

Re: Password changes ignored by CAS

Reply Threaded

In reply to this post by ckantzer

> Are there constraints or filters that would prevent an 'admin' user from being authenticated on the CAS side?

I took "admin user" to mean the principal you used to establish your
initial LDAP connection, e.g. the value of userDN in the following XML
snippet you shared previously:

<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list>
<value>ldap://hostname:port</value>
</list>
</property>
<property name="userDn" value="user"/>
<property name="password" value="password"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>

I get the impression that you actually mean "admin user" in a
different sense. Can you clarify?

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

ckantzer

RE: Password changes ignored by CAS

Reply Threaded

In reply to this post by ckantzer

So after deleting the 'admin' user from ldap and recreating I still get:

2009-07-09 15:44:27,488 INFO
[org.jasig.cas.authentication.AuthenticationManagerImpl] -
<AuthenticationHandler:
org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler failed to
authenticate the user which provided the following credentials:
[username: admin]>

All other users work great as does the rest of the CAS server. This is
the last piece of the puzzle that would be nice to put into place.

Does anyone else have an 'admin' user that can login successfully
through CAS that uses ldap?

-----Original Message-----
From: Chris Kantzer [mailto:[hidden email]]
Sent: Monday, June 29, 2009 11:46 AM
To: [hidden email]
Subject: RE: [cas-user] Password changes ignored by CAS

It is not the principal to establish the initial LDAP connection.

By 'admin' user I mean just the default admin user that is created for
jboss portal. It is just another user called 'admin' and has admin
privileges. Obviously this user would go away in prod, but I'm curious
why this user is being singled out. The fact that it has a username and
password of 'admin' (dev environment only) and fails is suspicious when
all the regular users (ckantzer) authenticate just fine.

-----Original Message-----
From: Marvin Addison [mailto:[hidden email]]
Sent: Monday, June 29, 2009 12:47 PM
To: [hidden email]
Subject: Re: [cas-user] Password changes ignored by CAS

> Are there constraints or filters that would prevent an 'admin' user
from being authenticated on the CAS side?

I took "admin user" to mean the principal you used to establish your
initial LDAP connection, e.g. the value of userDN in the following XML
snippet you shared previously:

<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list>
<value>ldap://hostname:port</value>
</list>
</property>
<property name="userDn" value="user"/>
<property name="password" value="password"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>

I get the impression that you actually mean "admin user" in a
different sense. Can you clarify?

M

--
You are currently subscribed to [hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Marvin Addison

Re: Password changes ignored by CAS

Reply Threaded

> 2009-07-09 15:44:27,488 INFO
> [org.jasig.cas.authentication.AuthenticationManagerImpl] -
> <AuthenticationHandler:
> org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler failed to
> authenticate the user which provided the following credentials:
> [username: admin]>

Your LDAP/OpenDS logs should have more to say on the exact cause of
the failed authentication attempt. If you have an LDAP error code in
the logs for the bind attempt that corresponds to the error above,
that would go a long way to explaining the root cause.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user