LDAP Url failover Issue with UnboundID / V4

Etienne Dysli Metref etienne.dysli-metref at switch.ch
Mon Nov 9 17:50:11 UTC 2020

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x6965D453D81531AD.asc
Type: application/pgp-keys
Size: 15086 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20201109/ad305824/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20201109/ad305824/attachment.sig>

More information about the users mailing list