Confirmed in 2.9. Problem likely in earlier versions and probably also in later versions up through 2.12 and master branch.
When using the auth_proxy module with both the native authenticator and the LDAP authenticator, native authentication fails if the LDAP server can not be reached.
In our consortium, all of our libraries but one authenticate with the native authenticator. For the one other library, we proxy their login requests to their LDAP server. In our opensrf.xml we have the native authenticator enabled with the default configuration. The only other configured autheticator is the configuration for the client library LDAP server which has the appropriate <org_units> section to limit it to their org unit.
Recently the LDAP server could not be reached due to an outage at the library that we proxy LDAP logins for. This caused a failure in our Evergreen system where many people could not log in that were not associated with the LDAP library.
After looking at the code I suspected that what may be happening is that at least some logins come through without an org unit set. When that happens it will try all the authenticators no matter what. I thought through the flow of how that information comes in to the auth_proxy module and came up with the following very simple fix:
--- AuthProxy.pm 2017-09-06 09:20:56.401002057 -0400
+++ AuthProxy.pm.ldap_unavail_fix 2017-09-06 09:22:03.258049213 -0400
@@ -217,7 +217,7 @@
if ($authenticator->login_types and $args->{'type'}) {
next unless grep(/^(all|$args->{'type'})$/, @{$authenticator->{'login_types'}});
}
- if ($authenticator->org_units and $args->{'org'}) {
+ if ($authenticator->org_units) {
next unless grep(/^(all|$args->{'org'})$/, @{$authenticator->{'org_units'}});
}
That is based on the master branch. Applying that patch to our system fixes the problem. I am not sure if that is the best way to fix it or not though.
Confirmed in Evergreen 2.12.8
Likely also affects later releases including 3.0 and master branch.
After upgrading to 2.12 last weekend, we retested this bug. Without the patch, adding a null route for the LDAP server IP address so it can not be reached reproduces the bug where no one can log in, even local users. Remove the null route to the LDAP server and all logins work again.
With the patch, local users can log in even with the null route to the LDAP server in place.