http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6979
Mike Gabriel <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mike.gabriel@das-netzwerkte | |am.de --- Comment #4 from Mike Gabriel <[email protected]> --- Hi, (In reply to Jonathan Druart from comment #3) > Is it still valid or can be closed? cc Martin I have recently been contracting for making KOHA LDAP authentication against a Debian Edu (aka Skolelinux) main server work. The customer also finances upstream communication and asked me to do my best to get whatever solution I come up with into upstream KOHA. After auditing the Auth_with_LDAP.pm code, I come to these conclusions: 1. The customer runs a Koha 3.08.01.002 [1]. In the meantime, Koha 3.20.something is out. However, the Auth_with_LDAP.pm file in latest HEAD (master branch) is still at version 3.07.00.049 [2]. Also the Auth_with_LDAP.pm code looks far more advanced than the Auth_with_LDAP.pm code on latest HEAD. Is is possible that some branch merging did not happen for the Auth_with_LDAP.pm file? It feels like this requires some portion of investigation. Thanks. [1]http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Auth_with_ldap.pm;h=fab6e44fafd6bb4cde5c1cd3e66655be0989338e;hb=e7c7f7af023172aea3fb02e4c1fa356c99f69fec [2] http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Auth_with_ldap.pm;h=58484a2ba700b0d469cbaf14f1b56083e01ebbf1;hb=6f81f8a0e2309447acc6e5bb74f444102d8adf56 2. KOHA LDAP Auth seems to be working fine for AD authentication using userPrincipal attribute description and a valid password. The default AD setup always allows user binding to their own account's DN. So that should work out well. 3. Authentication against openLDAP with clear text passwords stored in LDAP should also work fine as long as an administrative DN object is used for binding (e.g. cn=admin of objectClass simpleSecurityObject or such). However, storing clear text passwords in an LDAP tree is really really old school and should neither happen nor be expected anymore. On most setups, using $db->compare() will be unusable as passwords in most recent openLDAP setups are stored in a hashed way (and have been salted before hashing). 4. In KOHA, it even seems to be an option to use anonymous bind and $db->compare() for LDAP authentication. This should not be allowed at all, as it requires (a) an anonymous bind LDAP configuration that reveals the userPassword field (to everyone!!!) and requires the value in the userPassword attribute description to be stored in clear text. Nothing people really want... The approach for my customer (and also my proposal for getting the above sorted out in KOHA, if devs here agree) is this: o drop anonymous bind + userPassword LDAP CompareRequest completely o keep admin-bind + userPassword LDAP CompareRequest o keep AD authentication as is o try an auth for a specific user against LDAP using the user's DN (as proposed by a patch similar to the patch provided by Robert Fox) o make the openLDAP user-login-via-test-authbind method configurable via koha-conf.xml Any feedback on this is highly welcome. I am also open to discuss a different approach (as long as it works against openLDAP deployed in Debian Edu / Skolelinux setups). Greets, Mike PS: I am also a Debian Developer, being interested in getting KOHA into Debian in the long run... -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
