Bug 6823 - ldap auth broken in 3.5.10 master
Summary: ldap auth broken in 3.5.10 master
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All All
: P5 - low blocker (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-31 02:02 UTC by Bryan Lakatos
Modified: 2019-06-27 09:24 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bryan Lakatos 2011-08-31 02:02:11 UTC
using ldap auth with master (3.5.10) gives the following error on login:

Undefined subroutine &C4::Auth::checkpw_ldap called at /home/koha/kohaclone/C4/Auth.pm line 1426, <DATA> line 275.

Turning off ldap auth (via koha-conf.xml) allows logins to complete successfully.
Comment 1 Bryan Lakatos 2011-08-31 04:49:17 UTC
Disregard - the bug turned out to be a bizarre scenario on the ldap end.
Comment 2 Bryan Lakatos 2011-09-01 15:44:37 UTC
For those interested in the details: Our LDAP server is a Novell eDirectory server, which used to provide the eDirectory username (which we map to userid in Koha) when queried for the "cn" field. Apparently, sometime this summer (probably when that server was updated) it stopped doing that. 

The fix was to change the mapping in koha-conf.xml to the LDAP standard "uid" instead of the eDirectory "cn" which we had been using. 

The problem was tough to track down mainly because of two things:

1. No one here knew about eDir's switch from "cn" to "uid" for LDAP queries, and

2. When queries for "cn" failed there was no error message generated. There just wasn't a reply. 

The symptom we were seeing was that Koha accounts that hadn't had staff client permissions set before the eDir update weren't having new permissions honored during the login process, thus they got a "you do not have permission" style error. Oddly, Koha accounts that DID previously have permissions set were responsive to any changes to those permissions, even removal and re-addition of the perms. 

Our theory on the symptom was that, since Koha had already seen the accounts with perms set before the eDir update as valid, when the LDAP query for authentication to the staff client failed to return a positive ID on the user, Koha fell back to its internal account auth (we duplicate our LDAP accounts onto Koha) and the user was logged in without issue (and, as mentioned above, without error). Koha accounts who were receiving post-LDAP-update permissions grantings for the first time we suffering from LDAP failure and had no valid internal account (with permissions) already in Koha. Thus, when the "cn" LDAP query for these accounts failed, Koha could not fall back to its internal auth. This process in Koha is probably correctly designed for security, but without errors given from the LDAP side, the subsequent login/permissions failures were very hard to troubleshoot. 

Hope this helps!
Comment 3 Bryan Lakatos 2011-09-01 15:47:16 UTC
As an addition to number 1 in my previous comment, I should mention that I have found no docs indicating an eDirectory-LDAP switch from "cn" to "uid" - I just know that it used to work to query "cn" and now it works to query "uid."