Multiple ldapURL values in ldap.properties

Tue Jun 21 15:40:23 UTC 2022

We're still on v4.1.6, so I should upgrade and try again.  I should have mentioned initially that setting idp.authn.LDAP.connectionStrategy explicitly by uncommenting it doesn't work either.

Steven Teixeira

From: users <users-bounces at shibboleth.net> On Behalf Of Daniel Fisher via users
Sent: Tuesday, June 21, 2022 6:02 AM
To: Shib Users <users at shibboleth.net>
Cc: Daniel Fisher <dfisher at vt.edu>
Subject: Re: Multiple ldapURL values in ldap.properties

CAUTION: This message originated from outside of Stanislaus State. Do not click on links or open attachments unless you recognize the sender and are expecting the message.

On Mon, Jun 20, 2022 at 2:55 PM Steven Teixeira <steixeira at csustan.edu<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver1.example.org%2F&data=05%7C01%7Csteixeira%40csustan.edu%7C4ce16131215a4335a40a08da53865155%7Cbee5690713df4af2a4bfd7ef0debc01c%7C0%7C0%7C637914133619330704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rltQ4A4pPyiRm%2BfR4w3EU42GJlcKy9HVrprYxWJwxQ0%3D&reserved=0> ldaps://server2.example.org<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver2.example.org%2F&data=05%7C01%7Csteixeira%40csustan.edu%7C4ce16131215a4335a40a08da53865155%7Cbee5690713df4af2a4bfd7ef0debc01c%7C0%7C0%7C637914133619330704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vriRp3yG%2Fxkahgm7lWmWwrgxjk3YbqKM0oWJ2rWzIY4%3D&reserved=0> ldaps://server3.example.org<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver3.example.org%2F&data=05%7C01%7Csteixeira%40csustan.edu%7C4ce16131215a4335a40a08da53865155%7Cbee5690713df4af2a4bfd7ef0debc01c%7C0%7C0%7C637914133619330704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J%2B%2BbHubPCmJnAQEpyJ3dbpNZLoTLTX0NoxhUtdMRPCc%3D&reserved=0> ldaps://server4.example.org<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver4.example.org%2F&data=05%7C01%7Csteixeira%40csustan.edu%7C4ce16131215a4335a40a08da53865155%7Cbee5690713df4af2a4bfd7ef0debc01c%7C0%7C0%7C637914133619330704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xzRV0TGxJbQ3hAAajgDHgbOeK%2Byr9%2Bps6J7v6heNE94%3D&reserved=0>

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/653b0322/attachment.htm>