[Koha-bugs] [Bug 6823] ldap auth broken in 3.5.10 master

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Sep 1 17:44:37 CEST 2011


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6823

--- Comment #2 from Bryan Lakatos <bryan.lakatos at mvschool.com> 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!

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.


More information about the Koha-bugs mailing list