LDAP Url failover Issue with UnboundID / V4

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

LDAP Url failover Issue with UnboundID / V4

Paul King
Hi All,

We've got an issue that we've been trying to wrap our heads around, and we're wondering if anyone could shed any light.

Since switching to either v3 with UnboundID or v4 (fresh and upgraded instances tested), whenever the last LDAP server in the "idp.authn.LDAP.ldapURL" list is down it effectively breaks authentication. If the unavailable LDAP server is anywhere else in the list it works the same as in v3 pre-UnboundID - that is it just carries on without issue using the other available LDAP servers. The resolver still works regardless of where the unavailable LDAP server exists in the list as it did before switching to UnboundID.

So given an ldapURL like this:

idp.authn.LDAP.ldapURL = ldap://ldap1.example.local:389 ldap://ldap2.example.local:389 ldap://ldap3.example.local:389

 If ldap1.example.local:389 or ldap2.example.local:389 are down, authentication is resilient and fails over to the next LDAP server in the list as expected. However, if ldap3.example.local:389 is down, when a user attempts to enter their credentials it logs the following error and does not authenticate the user, regardless of whether the other specified servers are up:

2020-10-29 15:12:16,001 - DEBUG [net.shibboleth.idp.authn.impl.LDAPCredentialValidator:136] - Credential Validator ldap: Attempting to authenticate user userBlah
2020-10-29 15:12:16,002 - DEBUG [net.shibboleth.idp.authn.PooledTemplateSearchDnResolver:226] - resolve user=[org.ldaptive.auth.User@1186726382::identifier=userBlah, context=org.apache.velocity.VelocityContext@8cc392d]
2020-10-29 15:12:16,021 - DEBUG [org.ldaptive.provider.unboundid.UnboundIDConnectionFactory:90] - Error connecting to LDAP URL: ldap://ldap1.example.local:389 ldap://ldap2.example.local:389 ldap://ldap3.example.local:389
org.ldaptive.provider.ConnectionException: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server ldap3.example.local:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))')
    at org.ldaptive.provider.unboundid.UnboundIDConnectionFactory.createInternal(UnboundIDConnectionFactory.java:65)
Caused by: com.unboundid.ldap.sdk.LDAPException: An error occurred while attempting to connect to server ldap3.example.local:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
    at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:875)
Caused by: java.io.IOException: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb')
    at com.unboundid.ldap.sdk.LDAPConnectionInternals.<init>(LDAPConnectionInternals.java:185)
Caused by: com.unboundid.ldap.sdk.LDAPException: An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb
    at com.unboundid.ldap.sdk.ConnectThread.getConnectedSocket(ConnectThread.java:269)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
    at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
2020-10-29 15:12:16,021 - ERROR [org.ldaptive.pool.BlockingConnectionPool:457] - [org.ldaptive.pool.BlockingConnectionPool@1583488429::name=search-pool, poolConfig=[org.ldaptive.pool.PoolConfig@1021804183::minPoolSize=3, maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false, validatePeriodically=true, validatePeriod=PT5M, validateTimeout=PT5S], activator=null, passivator=null, validator=[org.ldaptive.pool.SearchValidator@1469339442::searchRequest=[org.ldaptive.SearchRequest@-715611116::baseDn=, searchFilter=[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*), parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=PT0S, sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED, searchEntryHandlers=null, searchReferenceHandlers=null, controls=null, referralHandler=null, intermediateResponseHandlers=null]] pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@1674108056::prunePeriod=PT5M, idleTime=PT10M], connectOnCreate=true, connectionFactory=[org.ldaptive.DefaultConnectionFactory@1202521034::provider=org.ldaptive.provider.unboundid.UnboundIDProvider@40167ad, config=[org.ldaptive.ConnectionConfig@414987420::ldapUrl=ldap://ldap1.example.local:389 ldap://ldap2.example.local:389 ldap://ldap3.example.local:389, connectTimeout=PT3S, responseTimeout=PT3S, sslConfig=[org.ldaptive.ssl.SslConfig@1312521522::credentialConfig=net.shibboleth.idp.authn.impl.X509ResourceCredentialConfig@ace827e, trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=false, useStartTLS=false, connectionInitializer=[org.ldaptive.BindConnectionInitializer@147880794::bindDn=[hidden email], bindSaslConfig=null, bindControls=null], connectionStrategy=org.ldaptive.DefaultConnectionStrategy@2b9d97b4]], initialized=true, availableCount=0, activeCount=0] unable to connect to the ldap
org.ldaptive.provider.ConnectionException: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server ldap3.example.local:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))')
    at org.ldaptive.provider.unboundid.UnboundIDConnectionFactory.createInternal(UnboundIDConnectionFactory.java:65)
Caused by: com.unboundid.ldap.sdk.LDAPException: An error occurred while attempting to connect to server ldap3.example.local:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
    at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:875)
Caused by: java.io.IOException: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb')
    at com.unboundid.ldap.sdk.LDAPConnectionInternals.<init>(LDAPConnectionInternals.java:185)
Caused by: com.unboundid.ldap.sdk.LDAPException: An error occurred while attempting to establish a connection to server ldap3.example.local:389:  ConnectException(Connection refused (Connection refused)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb
    at com.unboundid.ldap.sdk.ConnectThread.getConnectedSocket(ConnectThread.java:269)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
    at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
2020-10-29 15:12:16,022 - WARN [org.ldaptive.pool.BlockingConnectionPool:544] - unable to create active connection
2020-10-29 15:12:16,022 - ERROR [org.ldaptive.pool.BlockingConnectionPool:151] - Could not service check out request

Is this a known issue, configuration problem or a bug?

Many thanks in advance,

Kind regards,

Paul King

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Cantor, Scott E.
Don't know, but I always feel obligated to note that you no longer have to rely on this anyway. The IdP can chain native LDAP validators in V4 (vs. requiring JAAS to do it, which also worked in V3).

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Daniel Fisher-2
In reply to this post by Paul King
On Thu, Nov 5, 2020 at 8:49 AM Paul King <[hidden email]> wrote:
Hi All,

We've got an issue that we've been trying to wrap our heads around, and we're wondering if anyone could shed any light.

Since switching to either v3 with UnboundID or v4 (fresh and upgraded instances tested), whenever the last LDAP server in the "idp.authn.LDAP.ldapURL" list is down it effectively breaks authentication. If the unavailable LDAP server is anywhere else in the list it works the same as in v3 pre-UnboundID - that is it just carries on without issue using the other available LDAP servers. The resolver still works regardless of where the unavailable LDAP server exists in the list as it did before switching to UnboundID.


I think there is likely a bug here to fix. As Scott noted, there are better ways to handle this in v4.

--Daniel Fisher

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Jarno Huuskonen
Hi,

On Thu, 2020-11-05 at 16:28 -0500, Daniel Fisher wrote:

> On Thu, Nov 5, 2020 at 8:49 AM Paul King <[hidden email]> wrote:
> > Hi All,
> >
> > We've got an issue that we've been trying to wrap our heads around, and
> > we're wondering if anyone could shed any light.
> >
> > Since switching to either v3 with UnboundID or v4 (fresh and upgraded
> > instances tested), whenever the last LDAP server in the
> > "idp.authn.LDAP.ldapURL" list is down it effectively breaks
> > authentication. If the unavailable LDAP server is anywhere else in the
> > list it works the same as in v3 pre-UnboundID - that is it just carries
> > on without issue using the other available LDAP servers. The resolver
> > still works regardless of where the unavailable LDAP server exists in
> > the list as it did before switching to UnboundID.
> >
>
> I filed this issue to track:
> https://issues.shibboleth.net/jira/browse/IDP-1710

My experience with v3 + opendjk 11
and idp.ldaptive.provider=org.ldaptive.provider.unboundid.UnboundIDProvider
and
idp.authn.LDAP.ldapURL = ldaps://loc1-dc1.example.org:3269 ldaps://loc1-
dc2.example.org:3269 ldaps://loc2-dc1.example.org:3269

was that IdP only connected to the last (loc2-dc1) DC and didn't try to
connect to any of the other DC's (and no failover of anykind).
(I think with UnboundID failover worked with attribute resolver just not
authentication (this was a while ago so I might remember incorrectly)).

Using the default ldaptive provider (not UnboundID) authn failover works.

Does IdP expose ldaptive / unboundID connection strategy / failoverset
settings for authn ?

> I think there is likely a bug here to fix. As Scott noted, there are
> better ways to handle this in v4.

Does anyone have an example or link to docs for the V4 better way to handle
(ldap)failover for authentication ? (I tried searching V4 wiki for failover
and don't see anything obvious authentication related).
 
Is the better way for attribute resolution FailoverDataConnector ?

-Jarno

--
Jarno Huuskonen
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Cantor, Scott E.
On 11/6/20, 4:01 AM, "users on behalf of Jarno Huuskonen" <[hidden email] on behalf of [hidden email]> wrote:

>    Does anyone have an example or link to docs for the V4 better way to handle
>    (ldap)failover for authentication ?

https://wiki.shibboleth.net/confluence/display/IDP4/PasswordAuthnConfiguration

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Paul King
Hi Everyone,

Many thanks for your input in this. We'll certainly be keeping an eye out on bug tracker for this. In meantime I'll look into chaining LDAP validators natively!

Cheers,


Paul King

From: users <[hidden email]> on behalf of Cantor, Scott <[hidden email]>
Sent: 06 November 2020 14:04
To: Shib Users <[hidden email]>
Subject: Re: LDAP Url failover Issue with UnboundID / V4
 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Etienne Dysli Metref
In reply to this post by Jarno Huuskonen
On 06.11.20 10:01, Jarno Huuskonen wrote:

> My experience with v3 + opendjk 11
> and idp.ldaptive.provider=org.ldaptive.provider.unboundid.UnboundIDProvider
> and
> idp.authn.LDAP.ldapURL = ldaps://loc1-dc1.example.org:3269 ldaps://loc1-
> dc2.example.org:3269 ldaps://loc2-dc1.example.org:3269
>
> was that IdP only connected to the last (loc2-dc1) DC and didn't try
> to connect to any of the other DC's (and no failover of anykind). (I
> think with UnboundID failover worked with attribute resolver just
> not authentication (this was a while ago so I might remember
> incorrectly)).
>
> Using the default ldaptive provider (not UnboundID) authn failover
> works.

We've been hit by this on Java 8 as well when the latest JNDI bug forced
us to hastily switch to the UnboundID provider. The trouble is that the
IdPv3 leaves the ldaptive connection strategy to "default" [1] for LDAP
password authentication and does not expose controls to change this. On
the other hand, the code explicitly sets the connection strategy to
"active-passive" for LDAP attribute resolution.

As noted on [1], "default" strategy + non-JNDI provider = not really
well defined behaviour:

> Note that if multiple URLs are provided with a DEFAULT strategy to
> the JNDI provider then you will get the JNDI active/passive behavior.
> No other ldaptive provider currently supports multiple URLS in the
> DEFAULT strategy. If multiple URLs are supplied, those providers
> typically select the last URL in the list.
[1] https://www.ldaptive.org/v1/docs/guide/connections.html


> Does IdP expose ldaptive / unboundID connection strategy / failoverset
> settings for authn ?

AFAIK v3 doesn't. We're currently running with only one LDAP URL, until
I can hack enough Spring beans together to change the connection
strategy to active-passive for password authentication.

Cheers,
 Etienne

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

OpenPGP_0x6965D453D81531AD.asc (15K) Download Attachment
OpenPGP_signature (855 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Etienne Dysli Metref
On 09/11/2020 18.50, Etienne Dysli Metref wrote:
>> Does IdP expose ldaptive / unboundID connection strategy / failoverset
>> settings for authn ?
>
> AFAIK v3 doesn't. We're currently running with only one LDAP URL, until
> I can hack enough Spring beans together to change the connection
> strategy to active-passive for password authentication.

Here are my changes to conf/authn/ldap-authn-config.xml

+    <!-- Set the ConnectionStrategy of the UnboundID LDAP provider to
+         ACTIVE_PASSIVE, otherwise it uses the DEFAULT strategy whose
+         behaviour isn't defined with multiple URLs. This only affects
+         LDAP connections for password authentication, for the LDAP
+         DataConnector, the IdP already sets ACTIVE_PASSIVE as
+         ConnectionStrategy.
+
+         The UnboundID provider must be configured as the default one via
+         `idp.ldaptive.provider =
org.ldaptive.provider.unboundid.UnboundIDProvider`
+         in `ldap.properties`.
+
+         Every bean of class `org.ldaptive.DefaultConnectionFactory`
+         below must have its `provider` property set to reference the
+         `unboundIDProvider` bean for this to take effect. -->
+    <bean id="unboundIDProvider"
class="org.ldaptive.provider.unboundid.UnboundIDProvider">
+      <property name="providerConfig">
+        <bean
class="org.ldaptive.provider.unboundid.UnboundIDProviderConfig">
+          <property name="connectionStrategy">
+            <bean
class="org.ldaptive.provider.ConnectionStrategies.ActivePassiveConnectionStrategy"/>
+          </property>
+        </bean>
+      </property>
+    </bean>

-    <bean id="bindConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="bindConnectionConfig" />
+    <bean id="bindConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="bindConnectionConfig"
p:provider-ref="unboundIDProvider"/>

-    <bean id="anonSearchConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="anonSearchConnectionConfig" />
+    <bean id="anonSearchConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="anonSearchConnectionConfig"
p:provider-ref="unboundIDProvider"/>

-    <bean id="bindSearchConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="bindSearchConnectionConfig" />
+    <bean id="bindSearchConnectionFactory"
class="org.ldaptive.DefaultConnectionFactory"
p:connectionConfig-ref="bindSearchConnectionConfig"
p:provider-ref="unboundIDProvider"/>

I haven't thoroughly tested this yet so be careful, also this is only
valid for IdP version 3.4.7.




--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

OpenPGP_signature (855 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Cantor, Scott E.
FWIW, I think if you're stuck on V3, the most expedient thing is just to be using Java 11 to keep JNDI limping along.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LDAP Url failover Issue with UnboundID / V4

Jarno Huuskonen
In reply to this post by Etienne Dysli Metref
Hi,

On Mon, 2020-11-09 at 19:05 +0100, Etienne Dysli Metref wrote:
> On 09/11/2020 18.50, Etienne Dysli Metref wrote:
> > > Does IdP expose ldaptive / unboundID connection strategy / failoverset
> > > settings for authn ?
> >
> > AFAIK v3 doesn't. We're currently running with only one LDAP URL, until
> > I can hack enough Spring beans together to change the connection
> > strategy to active-passive for password authentication.

Thanks Etienne.
Have you looked if idp-4.0.1 exposes ACTIVE_PASSIVE ConnectionStrategy by
default ?

I think we'd like to use two pools for authentication: pool1 for local
servers(two) and pool2 for servers in remote data center and have
active_passive set for both pools(with fairly short timeouts) and try to use
local servers(pool1) first and if that fails then use pool2 (with chained
CredentialValidator).

Are chained CredentialValidator tried in sequence ?

-Jarno

> Here are my changes to conf/authn/ldap-authn-config.xml
...

--
Jarno Huuskonen

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]