http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P2 Change sponsored?|Sponsored |Seeking developer -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Dobrica Pavlinusic <dpavlin@rot13.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #2 from Dobrica Pavlinusic <dpavlin@rot13.org> --- In our case, we are seeing invalid DN as error message when connecting to OpenLDAP with local accounts (this makes sense, but we also have a little bit of magic in front of our LDAP to transfer logins in form of joe.doe@ffzg.hr to cn=joe.doe,dn=ffzg,dn=hr, so I'm not sure that this is only error on which we want to fallback to local auth. Unfortunately, I can't connect to OpenLDAP directly (since bind needs this cn=,dn=,dn= syntax) and don't have Active directory to test against that (but I suspect that AD users are not using auth_by_bind - again I might be wrong). -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #31275|0 |1 is obsolete| | --- Comment #3 from Chris Cormack <chris@bigballofwax.co.nz> --- Created attachment 31619 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31619&action=edit Bug 12831 - local only logins should work with LDAP This fixes regression introducted in Bug 8148. If ldap is enabled, and using auth_by_bind, one will not be able to login using any local accounts which do not appear in the ldap directory. This is problematic because a number of koha system accounts are unlikely to have a parallel in the active directory.. for instance SIP Service User accounts. Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Seems to work as advertised, there may be other error codes we need to trap, but this is a good start -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #4 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Hmm.. I'm still not really sure if a return code of 34 (LDAP_INVALID_DN_SYNTAX (34)) is all we should be looking for here. For example, what about: LDAP_NO_SUCH_OBJECT (32) Or, should we be catching LDAP_INVALID_CREDENTIALS (49) for an expired password only? Dobrica, do you have any comment? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Do either of your fancy doing that followup, then I can proceed further with QA? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Dobrica Pavlinusic <dpavlin@rot13.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #8 from Dobrica Pavlinusic <dpavlin@rot13.org> --- Upon further investigation, I decided to obsolete my patch because I suspect that if fixes problem only for our particular installation instead of providing general solution to problem. Let me explain... Problem comes from the fact that in LDAP bind we can't distinguish between users which doesn't exist in LDAP and invalid passwords. Both of those return LDAP_INVALID_CREDENTIALS (in our installation we have a bit of LDAP software in between which creates invalid DN for users which are not in LDAP, but that is not generally applicable). This means that we have to know (somehow) weather users should use LDAP passwords or not. Currently we don't have that information. One possibility is to do LDAP search (anonymous or via some account) and if user does exist in LDAP force him to provide proper LDAP password. However, this might not be practical because it creates additional load on LDAP server on one hand, and on another anonymous searches might be disabled (that's probably why we are using auth_by_bind in the first place) or there might not be special user which can search whole LDAP (or library might not have permissions to add such user which is our case). Another possibility is to track locally in Koha if users should use LDAP or local passwords. This might be implemented simply by invalidating local password (with word LDAP for example :-) which would prevent local fallback from working if user is logged in using LDAP. I'm biased towards second solution but I would love to hear some feedback about it before producing code. However, in any case we don't have clear migration path for existing installations because they do have local LDAP passwords in database (like we do). After first LDAP login users will have local password invalidated, but users which never login with correct LDAP password (or who are already disabled) we still be able to login using cached password. To be quite honest, I did use that side-effect of old code which allowed our patrons to login while LDAP wasn't available, so it might even make sense to have that behavior again (as LDAP configuration option perhaps). But if that is the case, we again don't have ability to expire users just in LDAP and expect them to be disabled in Koha also. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #10 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Unfortunately I don't think there's going to be a 'quick fix' here. As Dobrica says, I believe his fix doesn't really catch the general case and as such we could be chasing our tails for a while. That said, it's probably better than nothing to start with. Our LDAP implementation relies heavily on 'quirks' all over the place and isn't really a very thorough implementation at all. The more I look at it, the more questions I ask about it. I'd love to get a some feedback from the community as to how people are configuring the module and expecting it to behave. Then we'de have a better idea of what features are 'broken', what features are in fact bugs, and where people are using bugs as features to get around our bad implementation. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we can't leave that it is currently - we need local logins or we will break people's LDAP setups on update :( -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #13 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I think we can all agree with that sentiment Larry ;). The problem is how to achieve it in a secure way; any chance you could share a few examples of how your ldap customers are set up, and what response you get from the ldap server given an incorrect username:password combination vs's the response for a user not in the ldap directory? That would really help move things along on this bug. I think what we really want to achieve is a failure for bad username:password combination only.. and allow local fallback for users that are plain missing from the ldap directory. Does everyone agree that's what we need? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #15 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think it's possible to just delete it or set it to a special thing that indicates "no password" as you can generate borrowers with no password in the GUI. Then it would also be easy to see, who has logged in over LDAP. A pref restoring the old (and maybe bad behaviour) if anything else fails would maybe be an option too. Generally having a pref could make sense. We also don't have staff users in LDAP but only in Koha, as we keep the normal accounts and staff accounts separate or at least encourage to do that. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #18 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- My attached patch 'should' fix this for the case where a library is using auth_by_bind and not anonymous_bind. Reading the code, I believe this was the only case that needed fixing in this way. To re-introduce the functionality of bug 8148 fully however, we should also take a careful look at bug 9165 as suggested by cait, as with some minor adjustments with would allow for the functionality we're looking for for all three major LDAP configurations. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=9165 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice@biblibre.com --- Comment #21 from Julian Maurice <julian.maurice@biblibre.com> --- Here's the test plan I followed: 1. Create a LDAP user (uid=julian, userpassword=foobar) 2. Create a Koha user (userid=julian, password=julian) 3. Create another Koha (local) user (userid=123, password=123) 3. Enable LDAP in $KOHA_CONF with auth_by_bind = 1, and anonymous_bind = 0 4. Update source code to current master 5. Login with julian/foobar => success => OK 6. Login with julian/julian => failure => OK 7. Login with 123/123 => failure => NOT OK 8. Set anonymous_bind = 1 in $KOHA_CONF 9. Login with julian/foobar => success => OK 10. Login with julian/julian => failure => OK 10. Login with 123/123 => success => OK 11. So, here I can confirm the problem for local login when auth_by_bind = 1 and anonymous_bind = 1, let's apply the patch... 12. Apply the patch 13. Reset anonymous_bind to 0 14. Login with julian/foobar => success => OK 15. Login with julian/julian => success => ?? 16. Login with 123/123 => success => OK 17. Set anonymous_bind to 1 18. Login with julian/foobar => success => OK 19. Login with julian/julian => failure => OK 20. Login with 123/123 => success => OK So the patch fixes the problem, but allows LDAP users to login with their LDAP password and their local password. But this should be fixed by bug 9165, so I will QA this patch. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 --- Comment #24 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 34002 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=34002&action=edit Bug 12831: (RM followup) regression test checkpw_ldap should return 0 if it is not an anonymous bind, and authentication fails. This is better explained on the bug comments. This is just a regression test for the revised functionality. To test: - Run $ prove t/db_dependent/Auth_with_ldap.t => FAIL: it fails because C4::Auth_with_ldap doesn't match the expected behaviour - Apply the bugfix from Martin - Run $ prove t/db_dependent/Auth_with_ldap.t => SUCCESS: tests now pass. Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #26 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Patches pushed to master. Thanks Martin! -- You are receiving this mail because: You are watching all bug changes.