Multiple ldapURL values in ldap.properties

[Daniel Fisher]

On Mon, Jun 20, 2022 at 2:55 PM Steven Teixeira <steixeira at csustan.edu>
wrote:

> We recently changed our idp.authn.LDAP.ldapURL value from a single DNS
> round robin entry to multiple servers, separated by space.  As below:
> idp.authn.LDAP.ldapURL = ldaps://server1.example.org ldaps://
> server2.example.org ldaps://server3.example.org ldaps://
> server4.example.org
>
>
>
> idp.attribute.resolver.LDAP.ldapURL is set as below:
> idp.attribute.resolver.LDAP.ldapURL = %{idp.authn.LDAP.ldapURL}
>
> During testing of this change, the failover behavior was as expected.
> Authentication was immediate when server1 was up.  After powering down
> server1, authentication took 3 seconds longer(the timeout value).  After
> powering down server2, with server 1 still powered off, authentication took
> 6 seconds longer(3 seconds per server).  This continued through server 4.
> So we believed this to be working.  However, last week, it became clear
> that authentication was happening primarily on server4, the last entry in
> the space delimited list.  Further, when server4 was unreachable, the IdP
> didn’t even try to authenticate against any of the other LDAP servers
> listed.
>
>
>
> The lines for idp.authn.LDAP.connectionStrategy and
> idp.attribute.resolver.LDAP.connectionStrategy are as follows:
> #idp.authn.LDAP.connectionStrategy = ACTIVE_PASSIVE
>
> idp.attribute.resolver.LDAP.connectionStrategy =
> %{idp.authn.LDAP.connectionStrategy:ACTIVE_PASSIVE}
>
>
>
> So, our impression is that ACTIVE_PASSIVE is the current setting since it
> should be the default value.  Has anyone else run into behavior like this,
> or did I just miss something obvious?
>

What version of the IDP are you running? There was a bug that caused that
behavior if no connectionStrategy was configured. Explicitly setting
`idp.authn.LDAP.connectionStrategy` or running the latest version of the
IDP should fix this issue.

--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220621/83f2db53/attachment.htm>