LDAP Url failover Issue with UnboundID / V4
jarno.huuskonen at uef.fi
Fri Nov 6 09:01:04 UTC 2020
On Thu, 2020-11-05 at 16:28 -0500, Daniel Fisher wrote:
> On Thu, Nov 5, 2020 at 8:49 AM Paul King <pking at overtsoftware.com> 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:
My experience with v3 + opendjk 11
idp.authn.LDAP.ldapURL = ldaps://loc1-dc1.example.org:3269 ldaps://loc1-
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 ?
More information about the users