Bug 6823

Summary:	ldap auth broken in 3.5.10 master
Product:	Koha	Reporter:	Bryan Lakatos <bryan.lakatos>
Component:	Authentication	Assignee:	Galen Charlton <gmcharlt>
Status:	CLOSED INVALID	QA Contact:	Bugs List <koha-bugs>
Severity:	blocker
Priority:	P5 - low	CC:	bryan.lakatos, dpavlin
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

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."