Bug 22738 - Software Error after LDAP Authentication
Summary: Software Error after LDAP Authentication
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: 18.11
Hardware: All Linux
: P1 - high normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-18 13:05 UTC by morsch
Modified: 2020-01-06 20:14 UTC (History)
6 users (show)

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


Attachments
Screenshot of mysql and koha admin for category code (49.42 KB, image/jpeg)
2019-04-23 13:22 UTC, morsch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description morsch 2019-04-18 13:05:16 UTC
I have running a koha 18.11 version on ubuntu 16.04.6 LTS. I would like to use our LDAP Server for authentication. It seems as if the authentication itself is working since i did a tcpdump on the LDAP Server and it returns success. 
When I try to log in with my LDAP UserID and Password koha gives me the following error:

{UNKNOWN}: DBIC result _type  isn't of the _type Category at /usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 130. at /usr/share/koha/lib/Koha/Patron.pm line 288

Any help is much appreciated.

Thank you all.
Comment 1 Katrin Fischer 2019-04-22 09:43:25 UTC
Hi, this might turn out to be a problem with your setup. We just fixed an LDAP that received quite a bit of testing, so I assume that LDAP should be working ok.
It might be work asking about your issue on the mailing list instead.

Some things that come to mind:
- Is the patron account you try to log in with already created in Koha?
- Are you adding patron accounts on first log in with LDAP?
- If that is the case, have you mapped categorycode? (patron category code needs to match exactly what was set up in Koha)
Comment 2 Martin Renvoize 2019-04-23 09:04:43 UTC
Indeed.. we need more to go on here I'm afraid.

It does look like a possible mapping issue to me.
Comment 3 morsch 2019-04-23 09:22:31 UTC
First, Thank you all for your response. 
 I checked nearly anything i guess. In the LDAP configuration i played with any setting i could do. Disabled replication, update, bind and/or mapping itself. But still the same issue. I found something in a forum that mapping needs to be enabled for each column/attribute of the borrowers table where NULL is not allowed. Even if i set those values to true the issue still exists. I also disabled the setting that a patron is allowed to change the password via opac, issue still exists. Like Katrin said, i have checked the category code and tried to send it as default value within the LDAP Config:

<categorycode is="employeeType"   >MA</categorycode>

The complete LDAP Config looks like this:

<useldapserver>1</useldapserver>
  <!-- LDAP SERVER (optional) -->
  <ldapserver id="xx.xx.org">
    <hostname>ldap://xx.xxx.80.5</hostname>
    <base>dc=xx,dc=org</base>
    <user>cn=admin,dc=xx,dc=org</user>             <!-- DN, if not anonymous -->
    <pass>xxxxxxxx</pass>          <!-- password, if not anonymous -->
    <replicate>0</replicate>       <!-- add new users from LDAP to Koha database -->
    <update>0</update>             <!-- update existing users in Koha database -->
    <auth_by_bind>0</auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory -->
    <anonymous_bind>0</anonymous_bind> <!-- set to 1 if users should be searched using an anonymous bind, even when auth_by_bind is on -->
    <update_password>0</update_password> <!-- set to 0 if you don't want LDAP                      passwords synced to the local database -->
    <mapping>                  <!-- match koha SQL field names to your LDAP 
                                record field names -->
      <firstname    is="givenname"      ></firstname>
      <surname      is="sn"             ></surname>
      <address      is="postaladdress"  >53113</address>
      <city         is="l"              >Bonn</city>
      <zipcode      is="postalcode"     >53113</zipcode>
      <branchcode   is=""               >BIB</branchcode>
      <userid       is="uid"            ></userid>
      <password     is="userpassword"   ></password>
      <cardnumber   is="employeeNumber" ></cardnumber>
      <email        is="mail"           ></email>
      <categorycode is="employeeType"   >MA</categorycode>
      <phone        is="telephonenumber"></phone>
      <dateenrolled is=""               >2019-04-17</dateenrolled>
      <dateexpiry   is=""               >4749-04-17</dateexpiry>
   </mapping>
  </ldapserver>

I nearly tried any combination of the mapping fields and also of the config parameter (0 or 1), but nothing worked for me. 

A question regarding sth Katrin asks, where do i check if i am adding a patron account on first log in with LDAP? 

Thanks again for all your help and responses.
Comment 4 Alex Arnaud 2019-04-23 09:49:59 UTC
(In reply to morsch from comment #3)
> 
> <categorycode is="employeeType"   >MA</categorycode>
> 
Be careful with that ^
It does not mean fallback on default MA if employeeType is not a valid category code.
It means fallback on default if employeeType is empty.

So, if employeeType contains a non-valid category, this could raise the error you put in your first comment.
Comment 5 morsch 2019-04-23 09:58:30 UTC
Ok, i see. But the field "employeeType" on LDAP Server contains the valid categorycode. Even if a user with with empty employeeType tries to log in the error appears.
Comment 6 Alex Arnaud 2019-04-23 12:03:48 UTC
(In reply to morsch from comment #5)
> Ok, i see. But the field "employeeType" on LDAP Server contains the valid
> categorycode. Even if a user with with empty employeeType tries to log in
> the error appears.

What happens if you remove the mapping with employeeType and just keep the default value:

<categorycode is="">MA</categorycode>

Supposing MA is also a valid category code
Comment 7 morsch 2019-04-23 13:22:35 UTC
Created attachment 88471 [details]
Screenshot of mysql and koha admin for category code

Yes, did that already. Issue still exists when doing that setting:

<categorycode is="">MA</categorycode>

Yes, "MA" is the categorycode as you can see in the attached picture. There you see table entry from mysql and settings from koha administration gui.
Comment 8 Katrin Fischer 2019-04-23 14:30:55 UTC
Not very likely, but something I have had problems with in the past: MySQL seems to ignore a whitespace at the end of values, while Perl does not. It happens easily, very hard to spot even when you have access to the data via SQL. Using LIKE or comparing the length helps to identify:
  SELECT * FROM Foo WHERE CHAR_LENGTH(field) != CHAR_LENGTH(TRIM(field))
Comment 9 morsch 2019-04-24 09:52:33 UTC
(In reply to Katrin Fischer from comment #8)
> Not very likely, but something I have had problems with in the past: MySQL
> seems to ignore a whitespace at the end of values, while Perl does not. It
> happens easily, very hard to spot even when you have access to the data via
> SQL. Using LIKE or comparing the length helps to identify:
>   SELECT * FROM Foo WHERE CHAR_LENGTH(field) != CHAR_LENGTH(TRIM(field))

What exactly do you mean? I am not sure where and what do check in detail... Thank you for your help!
Comment 10 Katrin Fischer 2019-04-24 10:33:36 UTC
If you had "MA " as your categorycode, Perl will not match that to "MA". It's not likely, but we have run into this. 
Try something like:

select * from categories where categorycode like "MA"

If you do 

select * from categories where categorycode = "MA" 

it will always be found, whitespace or not.
Comment 11 morsch 2019-04-24 10:47:01 UTC
(In reply to Katrin Fischer from comment #10)
> If you had "MA " as your categorycode, Perl will not match that to "MA".
> It's not likely, but we have run into this. 
> Try something like:
> 
> select * from categories where categorycode like "MA"
> 
> If you do 
> 
> select * from categories where categorycode = "MA" 
> 
> it will always be found, whitespace or not.

Ahh ok, thanks for that. I did that but sadly there is no whitespace in the category code... When running command ##select * from categories where categorycode = "MA"## the result is the category "MA"... 
Do you know how to disable that a user will be created when logging in via opac? Or will a patron be created by default? I thought if i disable the replicate setting in ldap koha-conf it wont...
Comment 12 Katrin Fischer 2019-04-24 10:52:45 UTC
(In reply to morsch from comment #11)
> (In reply to Katrin Fischer from comment #10)
> > If you had "MA " as your categorycode, Perl will not match that to "MA".
> > It's not likely, but we have run into this. 
> > Try something like:
> > 
> > select * from categories where categorycode like "MA"
> > 
> > If you do 
> > 
> > select * from categories where categorycode = "MA" 
> > 
> > it will always be found, whitespace or not.
> 
> Ahh ok, thanks for that. I did that but sadly there is no whitespace in the
> category code... When running command ##select * from categories where
> categorycode = "MA"## the result is the category "MA"... 
> Do you know how to disable that a user will be created when logging in via
> opac? Or will a patron be created by default? I thought if i disable the
> replicate setting in ldap koha-conf it wont...

Just to make sure (probably copy and paste error), but did you run the statement with like or =? The replicate setting in the koha-conf.xml should do that. I think there are 3: just auth, create on first login, update with every login. You might want to disable update too. There are also some notes on the manual: https://koha-community.org/manual/18.11/en/html/apis_protocols.html?highlight=ldap#ldap
Comment 13 morsch 2019-04-24 11:01:39 UTC
(In reply to Katrin Fischer from comment #12)
> (In reply to morsch from comment #11)
> > (In reply to Katrin Fischer from comment #10)
> > > If you had "MA " as your categorycode, Perl will not match that to "MA".
> > > It's not likely, but we have run into this. 
> > > Try something like:
> > > 
> > > select * from categories where categorycode like "MA"
> > > 
> > > If you do 
> > > 
> > > select * from categories where categorycode = "MA" 
> > > 
> > > it will always be found, whitespace or not.
> > 
> > Ahh ok, thanks for that. I did that but sadly there is no whitespace in the
> > category code... When running command ##select * from categories where
> > categorycode = "MA"## the result is the category "MA"... 
> > Do you know how to disable that a user will be created when logging in via
> > opac? Or will a patron be created by default? I thought if i disable the
> > replicate setting in ldap koha-conf it wont...
> 
> Just to make sure (probably copy and paste error), but did you run the
> statement with like or =? The replicate setting in the koha-conf.xml should
> do that. I think there are 3: just auth, create on first login, update with
> every login. You might want to disable update too. There are also some notes
> on the manual:
> https://koha-community.org/manual/18.11/en/html/apis_protocols.
> html?highlight=ldap#ldap

I run the = statement.
Ok, thats where i tried to configure it. Tried it without update, replicate and auth. But Problem sill appears. Thats so frustrating...
Comment 14 Katrin Fischer 2019-04-24 11:30:38 UTC
You need to run the 'like' statement :)
Comment 15 morsch 2019-04-24 11:48:21 UTC
(In reply to Katrin Fischer from comment #14)
> You need to run the 'like' statement :)

Ok, did that. It returns the category as well. That is correct isn't it?
Comment 16 Katrin Fischer 2019-04-24 12:41:02 UTC
Yes. Sadly, this was my last idea :(
Comment 17 morsch 2019-04-24 12:53:39 UTC
Anyways, thank you very much! Is there anybody else who can help me with this?
Comment 18 Liz Rea 2019-04-24 19:59:09 UTC
Can't replicate, suspect config, not a project blocker. Please, if you need more ideas, send your query to the Koha mailing list. 

Cheers,
Liz Rea
Comment 19 Katrin Fischer 2019-04-25 05:50:59 UTC
Hi, adding the mailing list CC won't help, especially not the koha-bugs one as this is for the bugzilla changes and only very few are subscribed there (not including the bugzilla user itself). The normal mailing lists has a much wider audience. I suggest sending all information to the koha-devel list:

http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

Someone might be able to spot the issue, that we haven't been able to figure out.

Severity has been downgraded because we can't reproduce the problem at the moment.
Comment 20 morsch 2019-04-25 06:11:03 UTC
Thank you very much. Hopefully one from the list could help me. Thanks for your help and patience Katrin
Comment 21 morsch 2019-04-26 08:18:06 UTC
I used to fix it by myself. For those of you who are interested in the working ldap config, here it is:

<!-- LDAP SERVER (optional) -->
<ldapserver id="ldap1.xxx.org">
<hostname>ldap://xx.xxx.80.5</hostname>
<base>dc=xx,dc=xx</base>
<user>cn=admin,dc=xx,dc=xx</user>
<pass>xxxxxxxxx</pass>
<replicate>1</replicate>
<update>1</update>
<auth_by_bind>0</auth_by_bind>
<anonymous_bind>0</anonymous_bind>
<principal_name>uid=%s,dc=xx,dc=xx</principal_name>
<update_password>1</update_password> 
<mapping>
      <firstname    is="giveNname"      ></firstname>
      <surname      is="sn"             ></surname>
      <address      is="postalAddress"  ></address>
      <city         is="l"              >Bonn</city>
      <zipcode      is="postalCode"     ></zipcode>
      <branchcode   is="branch"         >BIB</branchcode>
      <userid       is="uid"            ></userid>
      <password     is="userPassword"   ></password>
      <email        is="mail"           ></email>
      <categorycode is="employeeType"   >MA</categorycode>
      <phone        is="telephoneNumber"></phone>
</mapping>
</ldapserver>

Keep in mind to replace all individual settings, like IP, categorycode etc. It seems the problem was the former missing "principal_name" setting. Furthermore you need to check the case sensitivity of the mapping attributes from ldap. You need to type "giveNname" instead of "givenname".
Comment 22 Katrin Fischer 2019-04-26 08:37:33 UTC
Thx a lot for sharing the fix!