Bug 12831: Local Only logins with LDAP

Local only logins should continue to function when LDAP is enabled.
This was not the case after bug 8148 [LDAP Auth should FAIL when ldap
contains a NEW password].  For this case, we need to diferentiate
between local accounts and ldap accounts.  This is somewhat challenging
and thus this patch is only part of the story.

The other half can be achieved with bug 9165

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

diff --git a/C4/Auth_with_ldap.pm b/C4/Auth_with_ldap.pm
index b42506d..e781baf 100644 (file)
--- a/C4/Auth_with_ldap.pm
+++ b/C4/Auth_with_ldap.pm
@@ -145,8 +145,19 @@ sub checkpw_ldap {
         # Perform a LDAP bind for the given username using the matched DN
         my $res = $db->bind( $principal_name, password => $password );
         if ( $res->code ) {
-            warn "LDAP bind failed as kohauser $userid: " . description($res);
-            return -1;
+            if ( $ldap->{anonymous_bind} ) {
+                # With anonymous_bind approach we can be sure we have found the correct user
+                # and that any 'code' response indicates a 'bad' user (be that blocked, banned
+                # or password changed). We should not fall back to local accounts in this case.
+                warn "LDAP bind failed as kohauser $userid: " . description($res);
+                return -1;
+            } else {
+                # Without a anonymous_bind, we cannot be sure we are looking at a valid ldap user
+                # at all, and thus we should fall back to local logins to restore previous behaviour
+                # see bug 12831
+                warn "LDAP bind failed as kohauser $userid: " . description($res);
+                return 0;
+            }
         }
         if ( !defined($userldapentry)
             && ( $config{update} or $config{replicate} ) )