password cache?

[javier-35]

Hi guys,

We have been using CAS for a weeks and just noticed that if the user changes his password it's able to logging with the new and the old password till the tomcat instance where CAS is running is restarted.

I'm assuming that something is wrong in my settings, any ideas?

Thanks in advance, Javier.
--
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]

What are you using?  LDAP?

Cheers,
Scott

On Thu, Sep 17, 2009 at 11:09 AM, javier <[hidden email]> wrote:

Hi guys,

We have been using CAS for a weeks and just noticed that if the user changes his password it's able to logging with the new and the old password till the tomcat instance where CAS is running is restarted.

I'm assuming that something is wrong in my settings, any ideas?

Thanks in advance, Javier.
--
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

[javier-35]

Hi Scott,

We are using Active Directory and OpenLdap (depending on the type of user will be stored in the first or the second) and the issue happens in both of them.

Thanks, Javier.

_________________________________________
Javier Trapero.
Web Application Developer - Interactive Media Team
The Natural History Museum
Cromwell Road
South Kensington
London SW7 5BD
________________________________________
From: Scott Battaglia [mailto:[hidden email]]
Sent: 18 September 2009 04:38
To: [hidden email]
Subject: Re: [cas-user] password cache?

What are you using?  LDAP?

Cheers,
Scott

On Thu, Sep 17, 2009 at 11:09 AM, javier <[hidden email]> wrote:
Hi guys,

We have been using CAS for a weeks and just noticed that if the user changes his password it's able to logging with the new and the old password till the tomcat instance where CAS is running is restarted.

I'm assuming that something is wrong in my settings, any ideas?

Thanks in advance, Javier.
--
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

[Michael Ströder]

Scott Battaglia wrote:
>> On Thu, Sep 17, 2009 at 11:09 AM, javier <[hidden email]
>> <mailto:[hidden email]>> wrote:
>> We have been using CAS for a weeks and just noticed that if the user
>> changes his password it's able to logging with the new and the old
>> password till the tomcat instance where CAS is running is restarted.
>
> What are you using?  LDAP?

The question is whether the GAS ticket granting cookie was invalidated after
password change. If not, then yes, the CASTGC is just (re-)used to create
another service ticket.

Ciao, Michael.


--
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

[javier-35]

Hi Michael,

Our password reset process enforces the user to log off which deletes the granting cookie but a new one is generated when the user connects again with the old password.

I found that disabling the OpenLdap pool option on the deployerconfigcontext solves the problem:

        ...
        <bean id="OpenLdapContextSource" class="org.springframework.ldap.core.support.LdapContextSource">
                <property name="pooled" value="false"/>
        ...

Any ideas?

Cheers, Javier.


_________________________________________
Javier Trapero.
Web Application Developer - Interactive Media Team
The Natural History Museum
Cromwell Road
South Kensington
London SW7 5BD
-----Original Message-----
From: Michael Ströder [mailto:[hidden email]]
Sent: 18 September 2009 15:24
To: [hidden email]
Subject: Re: [cas-user] password cache?

Scott Battaglia wrote:
>> On Thu, Sep 17, 2009 at 11:09 AM, javier <[hidden email]
>> <mailto:[hidden email]>> wrote:
>> We have been using CAS for a weeks and just noticed that if the user
>> changes his password it's able to logging with the new and the old
>> password till the tomcat instance where CAS is running is restarted.
>
> What are you using?  LDAP?

The question is whether the GAS ticket granting cookie was invalidated after
password change. If not, then yes, the CASTGC is just (re-)used to create
another service ticket.

Ciao, Michael.


--
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]

> I found that disabling the OpenLdap pool option on the deployerconfigcontext solves the problem:
>
>        ...
>        <bean id="OpenLdapContextSource"                                                class="org.springframework.ldap.core.support.LdapContextSource">
>                <property name="pooled" value="false"/>
>        ...

You should _never_ use JNDI pooling, enabled by the pooled attribute,
for authentication.  That may cause the authenticated state of one
connection to be inherited by a subsequent connection for a different
user, thus allowing the former credentials to be used instead of the
current ones.  This would allow impersonation attacks.

Formerly, when we wrote the custom AuthenticatedLdapContextSource
subclass, we explicitly overwrote the pooled property value so this
wasn't possible.  Perhaps we need some big red letters somewhere in
our documentation that indicates _not_ to do this with the Spring
LdapContextSource class that we recommend using currently.

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

[Pat Hennessy-2]

Hello..  I was curious about the pooled attributes.  We've been using JAAS to Kerberos for our CAS server for years, but I was considering changing it to use LDAP against our Active Directory.  So, I followed the directions on the following page on the wiki and got it working..

http://www.ja-sig.org/wiki/display/CASUM/LDAP

I saw in one of the examples where the pooled flag was set when specifing multiple ldap servers, but not set when only one server was specified.  I copied the code below from the wiki page.  I'm basically doing the same thing.

<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">

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

		<list>
			<value>ldaps://ldap.rutgers.edu/</value>
			<value>ldaps://ldap2.rutgers.edu/</value>

		</list>
	</property>

One of the features we're looking for is the ability to failover to another ldap server.  Is the pooled attribute you mentioned earlier (JNDI pooling) the same as the one above?  Is that necessary to use multiple servers?  I'm not looking to introduce any type of impersonation attacks, but would like the CAS server to be highly available.

I'm not really a Java programmer and I'm just looking for some clarrification here.

Thanks,

Pat

On Fri, Sep 18, 2009 at 11:41 AM, Marvin Addison <[hidden email]> wrote:

> I found that disabling the OpenLdap pool option on the deployerconfigcontext solves the problem:
>
>        ...
>        <bean id="OpenLdapContextSource"                                                class="org.springframework.ldap.core.support.LdapContextSource">
>                <property name="pooled" value="false"/>
>        ...

You should _never_ use JNDI pooling, enabled by the pooled attribute,
for authentication.  That may cause the authenticated state of one
connection to be inherited by a subsequent connection for a different
user, thus allowing the former credentials to be used instead of the
current ones.  This would allow impersonation attacks.

Formerly, when we wrote the custom AuthenticatedLdapContextSource
subclass, we explicitly overwrote the pooled property value so this
wasn't possible.  Perhaps we need some big red letters somewhere in
our documentation that indicates _not_ to do this with the Spring
LdapContextSource class that we recommend using currently.

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]

> http://www.ja-sig.org/wiki/display/CASUM/LDAP

The documentation is wrong, then.  You should _never_ use any kind of
pooling for LDAP connections used for authentication.  See "When Not
to Use Pooling" at the bottom of
http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html for
an authoritative reference.  I will update the CASUM page with some
notes from this thread in the coming week.

> One of the features we're looking for is the ability to failover to another
> ldap server.

Our group has a great deal of LDAP experience, and Java/JNDI LDAP
experience in particular.  Daniel, our group leader, said that using
the failover capability in JNDI is not suitable for a high
availability setup.  JNDI will try every server listed in the
Context.PROVIDER_URL property, which is set by the urls property in
LdapContextSource, in a round-robin fashion with a wholly unsuitable
connection timeout by default.  If you _must_ use this capability, you
should definitely set the "com.sun.jndi.ldap.connect.timeout"
environment property to no more than 5s.  (Above reference discusses
this environment property in further detail.)  Again, we feel this
strategy is not suitable for HA; instead we recommend using some sort
of load balancing strategy that obfuscates the many LDAP providers
behind a single virtual name and which is responsible for health
checking and removing unavailable members from the pool.  This
strategy has worked remarkably well for our enterprise LDAP directory.

> Is the pooled attribute you mentioned earlier (JNDI pooling)
> the same as the one above?

Yes.  From the 3.0 spring-ldap AbstractContextSource class:

if (pooled) {
  baseEnv.put(SUN_LDAP_POOLING_FLAG, "true");
  log.debug("Using LDAP pooling.");
}

where SUN_LDAP_POOLING_FLAG = "com.sun.jndi.ldap.connect.pool".

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

[Pat Hennessy-2]

Thanks for the reply Marvin..

There was another recent thread I noticed regarding AD and LDAP auth (I'm still playing catch up).  The subject was "CAS and Active directory".  One of the posters there attached a sample deployerConfigContext where they specified multiple servers but not the pooled option.  Would the ldap library still attempt the other servers in a round robin fasion? 

As far as the timeouts go, I saw that on the wiki and set that as well.  I set it to 4 seconds for testing, but was going to try to lower it and see where/if it fails.  I think it would be good to look into some sort of load balancer for LDAP, but I'm not sure if that's something we can do anytime soon.  Below is the entire bean I have (without the pooling of course).

        <bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
                <property name="urls">
                        <list>
                                <value>ldap://server1/</value>
                                <value>ldap://server2/</value>
                        </list>
                </property>
                <property name="userDn" value="[hidden email]"/>
                <property name="password" value="testing"/>
                <property name="baseEnvironmentProperties">
                        <map>
                                <entry>
                                        <key>
                                                <value>java.naming.security.authentication</value>
                                        </key>
                                        <value>simple</value>
                                </entry>
                                <entry>
                                        <key>
                                                <value>com.sun.jndi.ldap.connect.timeout</value>
                                        </key>
                                        <value>4000</value>
                                </entry>
                                <entry>
                                        <key>
                                                <value>com.sun.jndi.ldap.read.timeout</value>
                                        </key>
                                        <value>4000</value>
                                </entry>
                        </map>
                </property>
        </bean>


Something else I should probably mention.  I found I got errors when using the full DN for the user.  When I used the AD style [hidden email], the errors went away.  I saw that on one of the spring forums.  I'm curious if it had to do with having some spaces in some of our OU names.  Although the search base having a space seems to work fine.  I've noticed other ldap apps we have can use either the DN or the [hidden email] syntax.

Pat

On Fri, Oct 9, 2009 at 11:09 AM, Marvin Addison <[hidden email]> wrote:

> http://www.ja-sig.org/wiki/display/CASUM/LDAP

The documentation is wrong, then.  You should _never_ use any kind of
pooling for LDAP connections used for authentication.  See "When Not
to Use Pooling" at the bottom of
http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html for
an authoritative reference.  I will update the CASUM page with some
notes from this thread in the coming week.

> One of the features we're looking for is the ability to failover to another
> ldap server.

Our group has a great deal of LDAP experience, and Java/JNDI LDAP
experience in particular.  Daniel, our group leader, said that using
the failover capability in JNDI is not suitable for a high
availability setup.  JNDI will try every server listed in the
Context.PROVIDER_URL property, which is set by the urls property in
LdapContextSource, in a round-robin fashion with a wholly unsuitable
connection timeout by default.  If you _must_ use this capability, you
should definitely set the "com.sun.jndi.ldap.connect.timeout"
environment property to no more than 5s.  (Above reference discusses
this environment property in further detail.)  Again, we feel this
strategy is not suitable for HA; instead we recommend using some sort
of load balancing strategy that obfuscates the many LDAP providers
behind a single virtual name and which is responsible for health
checking and removing unavailable members from the pool.  This
strategy has worked remarkably well for our enterprise LDAP directory.

> Is the pooled attribute you mentioned earlier (JNDI pooling)
> the same as the one above?

Yes.  From the 3.0 spring-ldap AbstractContextSource class:

if (pooled) {
 baseEnv.put(SUN_LDAP_POOLING_FLAG, "true");
 log.debug("Using LDAP pooling.");
}

where SUN_LDAP_POOLING_FLAG = "com.sun.jndi.ldap.connect.pool".

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]

> specified multiple servers but not the pooled option.  Would the ldap
> library still attempt the other servers in a round robin fasion?

Yes.  Specifying multiple URLs for the JNDI Context.PROVIDER_URL
property will cause each server to be contacted in round-robin fashion
regardless of the pooling property value.  Note this is behavior is
provided by the Sun JNDI implementation and would be available to
_any_ Java LDAP library that uses JNDI under the hood, which is all of
them as far as I know.

> Something else I should probably mention.  I found I got errors when using
> the full DN for the user.  When I used the AD style [hidden email], the
> errors went away.

I don't believe which LDAP authentication handler you're using, Bind
or FastBind.  Were these bind errors indicating failed auth attempts
you believe should have been successful?

> I'm curious if
> it had to do with having some spaces in some of our OU names.

I believe I've tested CAS LDAP handlers against AD with an OU
containing a space and it worked fine, so I would be surprised if
spaces are the cause of problems.  Without further information on your
AD topology, I couldn't even guess about other possible causes.

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

[Pat Hennessy-2]

Thanks for the info..  I'm going to mess around with my testing servers more next week.  I should have read the top of that page you linked to earlier.  It describes the pooling aspect.

Pat

On Fri, Oct 9, 2009 at 2:42 PM, Marvin Addison <[hidden email]> wrote:

> specified multiple servers but not the pooled option.  Would the ldap
> library still attempt the other servers in a round robin fasion?

Yes.  Specifying multiple URLs for the JNDI Context.PROVIDER_URL
property will cause each server to be contacted in round-robin fashion
regardless of the pooling property value.  Note this is behavior is
provided by the Sun JNDI implementation and would be available to
_any_ Java LDAP library that uses JNDI under the hood, which is all of
them as far as I know.

> Something else I should probably mention.  I found I got errors when using
> the full DN for the user.  When I used the AD style [hidden email], the
> errors went away.

I don't believe which LDAP authentication handler you're using, Bind
or FastBind.  Were these bind errors indicating failed auth attempts
you believe should have been successful?

> I'm curious if
> it had to do with having some spaces in some of our OU names.

I believe I've tested CAS LDAP handlers against AD with an OU
containing a space and it worked fine, so I would be surprised if
spaces are the cause of problems.  Without further information on your
AD topology, I couldn't even guess about other possible causes.

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