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.
> On Feb 24, 2017, at 3:59 PM, Tom Poage <[email protected]> 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.
>
>
>> On Feb 13, 2017, at 2:11 AM, Ben Howell-Thomas
>> <[email protected]> wrote:
>>
>> 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 :
>> • Before a bind attempt, a SearchValidator checks the connection is
>> still valid
>> • To make the bind attempt, org.ldaptive.provider.jndi.JndiConnection
>> sets the principal and credentials on the connection's environment variable
>> • This connection is then returned to the pool, still containing the
>> principal and credentials from the previous attempt.
>> • 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
>> • 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.
>>
>> --
>> - 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 [email protected].
>> 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 [email protected].
> 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.
--
- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/0B015CD4-0BCE-413E-9EBF-E45E12D28DF7%40ucdavis.edu.
