Bug 14507 - SIP Authentication broken when LDAP Auth Enabled
Summary: SIP Authentication broken when LDAP Auth Enabled
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Colin Campbell
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 16492 16610
  Show dependency treegraph
 
Reported: 2015-07-08 17:49 UTC by Bernard Shiundu
Modified: 2017-12-07 22:18 UTC (History)
9 users (show)

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


Attachments
Potential patch (2.46 KB, patch)
2015-08-05 12:18 UTC, Colin Campbell
Details | Diff | Splinter Review
Bug 14507 Use checkpw to check password in Patron Info (2.61 KB, patch)
2016-02-14 20:32 UTC, Liz Rea
Details | Diff | Splinter Review
Bug 14507 Use checkpw to check password in Patron Info (2.67 KB, patch)
2016-02-19 12:52 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 14507 [QA Followup] - Restore comment, tidy sub (1.15 KB, patch)
2016-02-19 12:52 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard Shiundu 2015-07-08 17:49:31 UTC
SIP Authentication is broken when LDAP Auth Enabled. With ldap enabled, testing via telnet using 9300CNkohasipuserid|COkohasipuserpwd|CPmybranch| returns 941 but sip.err shows:

LDAP bind failed as kohauser kohasipuser: LDAP error #49: LDAP_INVALID_CREDENTIALS
# The wrong password was supplied or the SASL credentials could not be processed

When ldap auth is disabled in koha-xml.conf everything works as advertised.

When kohasipuser is added to ldap the above error in sip.err goes away but Koha users still cannot login via SIP.
Comment 1 Colin Campbell 2015-07-30 15:03:07 UTC
Can you document the messages and responses. The initial error suggests that the login is failing especially as sip.err is closed as soon at login succeeds.

Not sure what is involved ehen you say "Koha users cannot login via SIP" what request are you sending and what response are you receiving?
Comment 2 Bernard Shiundu 2015-08-04 13:18:30 UTC
(In reply to Colin Campbell from comment #1)
> Can you document the messages and responses. The initial error suggests that
> the login is failing especially as sip.err is closed as soon at login
> succeeds.

Took a further look on syslog and the outputs below:
=============
Scenario A: LDAP Enabled:
=============
koha_sip[29552]: Configuration::find_service: Trying 9001/tcp
koha_sip[29552]: raw_transport: uname/inst: 'term1/SUL'
koha_sip[29552]: read_SIP_packet, INPUT MSG: '9300CNterm1|COterm1|CPSUL|AY1AZF5DE'
koha_sip[29552]: INPUT MSG: '9300CNterm1|COterm1|CPSUL|AY1AZF5DE'
koha_sip[29552]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '9300CNterm...', '93'): seq.no '1', protocol 2
koha_sip[29552]: Sip::MsgType::_initialize('Login', '00CNterm1|COterm1|CPSUL|', 'A1A1', '2', ...)
koha_sip[29552]: Successful login/auth for 'term1' of 'SUL'
koha_sip[29552]: login_core: $VAR1 = 'ILS';
koha_sip[29552]: new ILS 'SUL'
koha_sip[29552]: OUTPUT MSG: '941AY1AZFDFC'
koha_sip[29552]: read_SIP_packet, INPUT MSG: '9900302.00AY2AZFCA4'
koha_sip[29552]: INPUT MSG: '9900302.00AY2AZFCA4'
koha_sip[29552]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '9900302.00...', '99'): seq.no '2', protocol 2
koha_sip[29552]: Sip::MsgType::_initialize('SC Status', '00302.00', 'CA3A4', '8', ...)
koha_sip[29552]: OUTPUT MSG: '98YYYYNN10000520150804    1304072.00AOSUL|BXYYYYYYYYYYYNYYYY|AY2AZEE64'
koha_sip[29552]: read_SIP_packet, INPUT MSG: '6300120150804    130404          AOSUL|AAkohauser|AC|ADldappwd|AY3AZED0C'
koha_sip[29552]: INPUT MSG: '6300120150804    130404          AOSUL|AAkohauser|AC|ADldappwd|AY3AZED0C'
koha_sip[29552]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '6300120150...', '63'): seq.no '3', protocol 2
koha_sip[29552]: Sip::MsgType::_initialize('Patron Info', '00120150804    130404          AOSUL|AAkohauser|AC|ADldappwd|', 'A3A18A10','31', ...)
koha_sip[29552]: new ILS::Patron(kohauser): found patron '00783'
koha_sip[29552]: patron_status_string: 00783 charge_ok: 1
koha_sip[29552]: OUTPUT MSG: '64              00120150804    130407000000080008000000000000AOSUL|AA00783|AEBernard Shiundu Simwenyi|BLY|CQN|CC5001|BDP O Box 41539 Mombasa 80100|BEkohauser@my.email|BF0721 230520|PCAC|PIY|AFGreetings from Koha. |AY3AZC03E'
koha_sip[29552]: read_SIP_packet, INPUT MSG: ''
koha_sip[29552]: read_SIP_packet input empty (), end of input.
koha_sip[29552]: raw_transport: shutting down

================
Scenario B: LDAP Disabled
================
koha_sip[29264]: Configuration::find_service: Trying 9001/tcp
koha_sip[29264]: raw_transport: timeout is 60
koha_sip[29264]: read_SIP_packet, INPUT MSG: '9300CNterm1|COterm1|CPSUL|AY1AZF5DE'
koha_sip[29264]: INPUT MSG: '9300CNterm1|COterm1|CPSUL|AY1AZF5DE'
koha_sip[29264]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '9300CNterm...', '93'): seq.no '1', protocol 2
koha_sip[29264]: Sip::MsgType::_initialize('Login', '00CNterm1|COterm1|CPSUL|', 'A1A1', '2', ...)
koha_sip[29264]: Successful login/auth for 'term1' of 'SUL'
koha_sip[29264]: login_core: $VAR1 = 'ILS';
koha_sip[29264]: new ILS 'SUL'
koha_sip[29264]: OUTPUT MSG: '941AY1AZFDFC'
koha_sip[29264]: raw_transport: uname/inst: 'term1/SUL'
koha_sip[29264]: read_SIP_packet, INPUT MSG: '9900302.00AY2AZFCA4'
koha_sip[29264]: INPUT MSG: '9900302.00AY2AZFCA4'
koha_sip[29264]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '9900302.00...', '99'): seq.no '2', protocol 2
koha_sip[29264]: Sip::MsgType::_initialize('SC Status', '00302.00', 'CA3A4', '8', ...)
koha_sip[29264]: OUTPUT MSG: '98YYYYNN10000520150804    1257372.00AOSUL|BXYYYYYYYYYYYNYYYY|AY2AZEE5A'
koha_sip[29264]: read_SIP_packet, INPUT MSG: '6300120150804    125734          AOSUL|AAkohauser|AC|ADkohapwd|AY3AZEDC8'
koha_sip[29264]: INPUT MSG: '6300120150804    125734          AOSUL|AAkohauser|AC|ADkohapwd|AY3AZEDC8'
koha_sip[29264]: Sip::MsgType::new('C4::SIP::Sip::MsgType', '6300120150...', '63'): seq.no '3', protocol 2
koha_sip[29264]: Sip::MsgType::_initialize('Patron Info', '00120150804    125734          AOSUL|AAkohauser|AC|ADkohapwd|', 'A3A18A10','31', ...)
koha_sip[29264]: new ILS::Patron(kohauser): found patron '00783'
koha_sip[29264]: patron_status_string: 00783 charge_ok: 1
koha_sip[29264]: OUTPUT MSG: '64              00120150804    125737000000080008000000000000AOSUL|AA00783|AEBernard Shiundu Simwenyi|BLY|CQY|CC5001|BDP O Box 41539 Mombasa 80100|BEkohauser@my.email|BF0721 230520|PCAC|PIY|AFGreetings from Koha. |AY3AZC029'
koha_sip[29264]: read_SIP_packet, INPUT MSG: ''
koha_sip[29264]: read_SIP_packet input empty (), end of input.
koha_sip[29264]: raw_transport: shutting down
> 
> Not sure what is involved ehen you say "Koha users cannot login via SIP"

Just to clarify further - I run a mixed mode outfit. Currently University Employees use ldap credentials to login to the opac while Students login to the opac using koha database credentials. However from a SIP client - only users with koha database credentials can login. My thinking was that authentication from a SIP client should mirror authentication via the OPAC (i.e hierarchical)

> what request are you sending and what response are you receiving?

I guess those are all in the syslog outputs above
Comment 3 Katrin Fischer 2015-08-04 22:49:37 UTC
Wondering... could this be bug 9936?
Comment 4 Colin Campbell 2015-08-05 12:18:44 UTC Comment hidden (obsolete)
Comment 5 Liz Rea 2016-02-14 20:32:09 UTC Comment hidden (obsolete)
Comment 6 Kyle M Hall 2016-02-19 12:52:03 UTC
Created attachment 48229 [details] [review]
Bug 14507 Use checkpw to check password in Patron Info

Some devices are using patron information responses to validate
patron passwords to govern access to facilities as we
were using C4::Auth::checkpw_hash this only worked in a db password
context not other authentication routines.
The C4::Auth routines are not very consistent and there isnt a dropin
replacement for checkpw_hash this calls checkpw instead.
In a password only environment this behaves as the old version did
returning field CQ as Y if a valid password or no password is passed in
the patron info request and N if an incorrect password is supplied
It should also test against the appropriate authentication sources if
othere autrhentication schemes are in use

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Tested this with a client who reports that this enables SIP authentication to work correctly with their LDAP server.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 7 Kyle M Hall 2016-02-19 12:52:13 UTC
Created attachment 48230 [details] [review]
Bug 14507 [QA Followup] - Restore comment, tidy sub

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 8 Brendan Gallagher 2016-02-24 00:12:11 UTC
Pushed to Master - Should be in the May 2016 Release.   Thanks
Comment 9 Julian Maurice 2016-02-26 13:00:00 UTC
Patches pushed to 3.22.x, will be in 3.22.4
Comment 10 Frédéric Demians 2016-03-01 16:52:28 UTC
This patch has been pushed to 3.20.x, will be in 3.20.9.