LDAP BindPassivator needed for pooled DirectBind connections where LDAP denies anonymous search

[Ben Howell-Thomas]

Hi,

I think I may have found an issue but per guidelines posting here first.

When CAS is configured to authenticate with LDAP using Direct Bind and LDAP is locked down to not allow anonymous binds/searches or for users to see anything other than their own entry, then we get unexpected failures trying to log in.

For wrong passwords or locked accounts, every second attempt [with a given Ldap connection from the pool] would fail.  Actually, it would also fail for a valid account with the correct password if it was on the same connection as a failed login attempt, and the regular connection validator would similarly fail.

What's happening in Ldaptive is as follows :

1. Before a bind attempt, a SearchValidator checks the connection is still valid
   
2. To make the bind attempt, org.ldaptive.provider.jndi.JndiConnection sets the principal and credentials on the connection's environment variable
   
3. This connection is then returned to the pool, still containing the principal and credentials from the previous attempt.
   
4. Before the next login/bind attempt using that connection, SearchValidator tries to validate the connection again but fails, because it's no longer trying with the configured cas.properties cas.authn.ldap.bindDn property but with whatever user DN was used in the previous step
   
5. Since the SearchValidator fails, the connection is closed and an exception is returned, so CAS denies access by default (even if we should show the Account Locked page).
   

I asked the Ldaptive mailing list about this which put me on to the org.ldaptive.pool.BindPassivator class which reconnects to LDAP with the configured DN and credentials, effectively resetting the connection to what it should be after each bind request.  That way the connection is returned to the pool ready to be used again.

Adding the following to our version of LdapAuthenticationConfiguration.getDirectBindAuthenticator() implemented a BindPassivator to restore expected behaviour :

/*
 * Binding (which we do both when validating connections and authenticating users) using pooled connections is "tricky"
 * according to the Ldaptive mailing list.  The connection must be returned to the pool ready for the next connection 
 * to use (ie not binded as the previous user). Set a BindPassivator to clean the connection when it's returned to the pool.
 */

ConnectionPool cp = pooledBindAuthenticationHandler.getConnectionFactory().getConnectionPool();
BindRequest br = new BindRequest(l.getBindDn(), new Credential(l.getBindCredential()));
cp.setPassivator(new BindPassivator(br));

Another workaround of course would be to change the LDAP configuration.

thanks,

Ben 

# ps some relevant LDAP settings for reference

cas.authn.ldap[0].type=DIRECT

cas.authn.ldap[0].useSsl=false

cas.authn.ldap[0].useStartTls=false

cas.authn.ldap[0].connectTimeout=5000

cas.authn.ldap[0].subtreeSearch=false

cas.authn.ldap[0].bindDn=uid=cas,ou=Administrators,dc=domain,dc=com

cas.authn.ldap[0].bindCredential=password

cas.authn.ldap[0].minPoolSize=3

cas.authn.ldap[0].maxPoolSize=10

cas.authn.ldap[0].validateOnCheckout=true

cas.authn.ldap[0].validatePeriodically=true

cas.authn.ldap[0].validatePeriod=600

cas.authn.ldap[0].failFast=true

cas.authn.ldap[0].idleTime=500

cas.authn.ldap[0].prunePeriod=600

cas.authn.ldap[0].blockWaitTime=5000

This email is sent on behalf of Northgate Public Services (UK) Limited and its associated companies including Rave Technologies (India) Pvt Limited (together "Northgate Public Services") and is strictly confidential and intended solely for the addressee(s). 

If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully;  (ii) contact Northgate Public Services immediately on +44(0)1908 264500 quoting the name of the sender and the addressee then delete it from your system.

Northgate Public Services has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted.  You should scan attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales under number 00968498 with a registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 4NN.  Rave Technologies (India) Pvt Limited, registered in India under number 117068 with a registered address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 400001.

[Tom Poage]

This issue looks to have just bit us with 4.2.x, as well.

A network configuration error led to losing two of our four CAS servers at a busy time of day. Some fraction of the users needed to re-login, so there was a natural increase in LDAP pool connections. Every time the validator ran, each connection in the pool failed validation, forcing the creation of a new set of connections. We didn't notice this behavior earlier but, now that we look at it, it's been there all along.

Tom.

> --
> - CAS gitter chatroom: https://gitter.im/apereo/cas
> - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
> - CAS documentation website: https://apereo.github.io/cas
> - CAS project website: https://github.com/apereo/cas
> ---
> You received this message because you are subscribed to the Google Groups "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAD0p8psvuk%2Br_kUnBhM4MP9sK8%2Bm80VFGF5sqRNbzxYUn0Az1A%40mail.gmail.com.

[Ben Howell-Thomas]

Thanks for confirming I'm not the only one who had that issue.

I hadn't got around to raising an issue so I thought I was going crazy when I saw this in the CAS docs :

# cas.authn.ldap[0].poolPassivator=NONE|CLOSE|BIND

but it looks like Misagh's added it, presumably to 5.1 RC2.  Ah yes, I think I've connected the dots, the release announcement has :

• Removed the need to re-create LDAP connection pools during LDAP authentication for entry resolution, etc.

That'll be it - Thanks Misagh :)

Ben

On 24 February 2017 at 23:59, Tom Poage <tfp...@ucdavis.edu> wrote:

This issue looks to have just bit us with 4.2.x, as well.

A network configuration error led to losing two of our four CAS servers at a busy time of day. Some fraction of the users needed to re-login, so there was a natural increase in LDAP pool connections. Every time the validator ran, each connection in the pool failed validation, forcing the creation of a new set of connections. We didn't notice this behavior earlier but, now that we look at it, it's been there all along.

Tom.

> To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscribe@apereo.org.

> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAD0p8psvuk%2Br_kUnBhM4MP9sK8%2Bm80VFGF5sqRNbzxYUn0Az1A%40mail.gmail.com.

--
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscribe@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/9BE363E2-1316-406C-A3EB-D97AA60A3247%40ucdavis.edu.

[Misagh Moayyed]

No problem.

-- 
Misagh

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAD0p8psqbteJVN6Vw5jL6Gm5JG-Ahq%2BYy%2BmTt%2Bckv99m2nm5gw%40mail.gmail.com.

[Tom Poage]

Think we found a fix: adding a passivator to LDAP config in deployerConfigContext.xml. Thanks, Travis!


<bean id="abstractConnectionPool" abstract="true"
class="org.ldaptive.pool.BlockingConnectionPool"
init-method="initialize"
p:poolConfig-ref="ldapPoolConfig"
p:blockWaitTime="${ldap.pool.blockWaitTime}"
p:validator-ref="searchValidator"
p:pruneStrategy-ref="pruneStrategy"
p:passivator-ref="bindPassivator" />

<bean id="bindPassivator" class="org.ldaptive.pool.BindPassivator"
c:br-ref="bindRequest"/>

<bean id="bindRequest" class="org.ldaptive.BindRequest"
p:dn="${ldap.managerDn}">
<property name="credential">
<bean class="org.ldaptive.Credential"
c:password="${ldap.managerPassword}" />
</property>
</bean>

Note: we're not using <ldaptive:bind-search-authenticator>, as it's missing a few pieces necessary for connection pool config/validation.

Tom.

> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/9BE363E2-1316-406C-A3EB-D97AA60A3247%40ucdavis.edu.

[Jérôme Nenert]

Tom Poage <tfp...@ucdavis.edu> a écrit :

> This issue looks to have just bit us with 4.2.x, as well.
>
> A network configuration error led to losing two of our four CAS
> servers at a busy time of day. Some fraction of the users needed to
> re-login, so there was a natural increase in LDAP pool connections.
> Every time the validator ran, each connection in the pool failed
> validation, forcing the creation of a new set of connections. We
> didn't notice this behavior earlier but, now that we look at it,
> it's been there all along.

In your case, is it the loss of connection to your ldap servers that
made the pool failed ?

We experienced this issue on the 5.0.x never on the 4.0.x. It occurred
as a result of a restart of one ldap server from the pool.


Jerome

> https://groups.google.com/a/apereo.org/d/msgid/cas-user/9BE363E2-1316-406C-A3EB-D97AA60A3247%40ucdavis.edu.

[Jérôme Nenert]

Ben Howell-Thomas <ben.howe...@northgateps.com> a écrit :

> Thanks for confirming I'm not the only one who had that issue.
>
> I hadn't got around to raising an issue so I thought I was going crazy when
> I saw this in the CAS docs :
>
> # cas.authn.ldap[0].poolPassivator=NONE|CLOSE|BIND
>
>
> but it looks like Misagh's added it, presumably to 5.1 RC2. Ah yes, I
> think I've connected the dots, the release announcement has :
>
>

> - Removed the need to re-create LDAP connection pools during LDAP

> authentication for entry resolution, etc.
>
> That'll be it - Thanks Misagh :)

We are currently on the 5.0.x branch. It looks like it's mandatory to
migrate 5.1 RC2 to fix this issue ?

>> an email to cas-user+u...@apereo.org.

>> > To view this discussion on the web visit https://groups.google.com/a/
>> apereo.org/d/msgid/cas-user/CAD0p8psvuk%2Br_kUnBhM4MP9sK8%
>> 2Bm80VFGF5sqRNbzxYUn0Az1A%40mail.gmail.com.
>>

>> --
>> - CAS gitter chatroom: https://gitter.im/apereo/cas
>> - CAS mailing list guidelines: https://apereo.github.io/cas/
>> Mailing-Lists.html
>> - CAS documentation website: https://apereo.github.io/cas
>> - CAS project website: https://github.com/apereo/cas
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "CAS Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to cas-user+u...@apereo.org.

>> To view this discussion on the web visit https://groups.google.com/a/

>> apereo.org/d/msgid/cas-user/9BE363E2-1316-406C-A3EB-
>> D97AA60A3247%40ucdavis.edu.
>>
>
> --

> send an email to cas-user+u...@apereo.org.

> To view this discussion on the web visit

> https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAD0p8psqbteJVN6Vw5jL6Gm5JG-Ahq%2BYy%2BmTt%2Bckv99m2nm5gw%40mail.gmail.com.

[Ben Howell-Thomas]

We are currently on the 5.0.x branch. It looks like it's mandatory to migrate 5.1 RC2 to fix this issue ?

Or backport the fix yourself (starting from the config class for cas.authn.ldap[0].poolPassivator) or add my fix from the original email or change the LDAP config.  All of which is probably worse than upgrading ;)

Ben

On 15 March 2017 at 15:53, Jérôme Nenert <Jerome...@u-paris2.fr> wrote:

Ben Howell-Thomas <ben.howell-thomas@northgateps.com> a écrit :

---You received this message because you are subscribed to the Google Groups "CAS Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/20170315165350.Horde.VDzKC-q20etDC6rxCK6PjE2%40courriel.u-paris2.fr.

[Misagh Moayyed]

Or, you just follow this:

https://github.com/apereo/cas/issues/2443  

-- 
Misagh

From: Ben Howell-Thomas <ben.howe...@northgateps.com>
Reply: cas-...@apereo.org <cas-...@apereo.org>
Date: March 17, 2017 at 6:54:06 PM
To: cas-...@apereo.org <cas-...@apereo.org>
Subject:  Re: [cas-user] LDAP BindPassivator needed for pooled DirectBind connections where LDAP denies anonymous search

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAD0p8ptErWd_Rge8byxdoGV3PgRQC6d_he32nA3-T5S_TUkiCA%40mail.gmail.com.