Summary: | SIP Authentication broken when LDAP Auth Enabled | ||
---|---|---|---|
Product: | Koha | Reporter: | Bernard Shiundu <shiundu> |
Component: | Authentication | Assignee: | Colin Campbell <colin.campbell> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | brendan, colin.campbell, dpavlin, f.demians, fridolin.somers, julian.maurice, kyle, ztajoli |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 16492, 16610 | ||
Attachments: |
Potential patch
Bug 14507 Use checkpw to check password in Patron Info Bug 14507 Use checkpw to check password in Patron Info Bug 14507 [QA Followup] - Restore comment, tidy sub |
Description
Bernard Shiundu
2015-07-08 17:49:31 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? (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 Created attachment 41379 [details] [review] Potential patch This patch changes the Auth routine to one that takes account of authentication sources other than simple pw in the database. I have only tested this in the context of a password authenticating database NB the patron information request/response pair's function is not primarily authentication and supplying a password is optional, the sip process returns a password OK for an empty password field, this is done because some clients have traditionally sent an empty field rather than skipping it completely Please test if this enables authentication using LDAP Created attachment 48045 [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. 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> Created attachment 48230 [details] [review] Bug 14507 [QA Followup] - Restore comment, tidy sub Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Pushed to Master - Should be in the May 2016 Release. Thanks Patches pushed to 3.22.x, will be in 3.22.4 This patch has been pushed to 3.20.x, will be in 3.20.9. |