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.
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
Wondering... could this be bug 9936?
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.