Does anyone have detailed instructions for enabling and configuring Koha 3 with LDAP for authentication? This would be one of the major reasons for us moving to Koha from our current ILS. The man page for the LDAP plugin indicates that LDAP must supply *ALL* required fields for patron records. Our I.T. has advised us of the following for our LDAP server: It can be used for authentication only. It will not return data for fields. It will not allow anonymous binds. It will not return a password for Koha to compare. Koha must supply the password or the hash to LDAP. Given these constraints, how do we configure Koha to use LDAP? Paul
"Landers, Paul" <paul.landers@ttuhsc.edu> wrote:
Does anyone have detailed instructions for enabling and configuring Koha 3 with LDAP for authentication? This would be one of the major reasons for us moving to Koha from our current ILS. The man page for the LDAP plugin indicates that LDAP must supply *ALL* required fields for patron records. Our I.T. has advised us of the following for our LDAP server:
It can be used for authentication only. It will not return data for fields.
It will not allow anonymous binds.
It will not return a password for Koha to compare. Koha must supply the password or the hash to LDAP.
Given these constraints, how do we configure Koha to use LDAP?
Slap your I.T. until they provide a useful LDAP service? Seriously - I think you need to either:- 1. run your own LDAP server that proxies out to your I.T.'s LDAP server for authentication - see http://www.openldap.org/software/man.cgi?query=slapd-meta&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release for one way to do that; OR 2. you need to customise koha to create an C4::Auth_with_ldap_and_kohadb module that mixes C4::Auth and C4::Auth_with_ldap methods as needed. Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain. Hope that helps, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
MJ Ray a écrit :
"Landers, Paul" <paul.landers@ttuhsc.edu> wrote:
Does anyone have detailed instructions for enabling and configuring Koha 3 with LDAP for authentication? This would be one of the major reasons for us moving to Koha from our current ILS. The man page for the LDAP plugin indicates that LDAP must supply *ALL* required fields for patron records. Our I.T. has advised us of the following for our LDAP server:
It can be used for authentication only. It will not return data for fields.
It will not allow anonymous binds.
It will not return a password for Koha to compare. Koha must supply the password or the hash to LDAP.
Given these constraints, how do we configure Koha to use LDAP?
Slap your I.T. until they provide a useful LDAP service?
Seriously - I think you need to either:-
1. run your own LDAP server that proxies out to your I.T.'s LDAP server for authentication - see http://www.openldap.org/software/man.cgi?query=slapd-meta&sektion=5&apropos=0&manpath=OpenLDAP+2.4-Release for one way to do that; OR
2. you need to customise koha to create an C4::Auth_with_ldap_and_kohadb module that mixes C4::Auth and C4::Auth_with_ldap methods as needed.
Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain.
Hope that helps,
I know that edirectory will not pass passwords or passwords hash for authentication, the only way i know to go around this is to do what they call the "rebind" technique. first you search for you user, then you try to bind an ldap session as the user you want to test. Once this is done, you can also validate the the user in LDAP is also in the apropriate group. If we go with koha i will have to modify the ldap auth module so it works with the rebind. I hope this can help :) later Charles
Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain.
I'm not (yet) familiar with koha3. Normal koha 2 ldap interface was to retrieve the actual password from ldap, and compare it with the password to user supplied. (which is a strange and incompatible way to verify a password) Fortunately it was not difficult to change this behaviour to something else: Attempt to bind to the ldap server with the username/password to user provided. If the binds succeeds, the password is correct. If the bind fails, there could be all sorts of problems: wrong password, ldap server down, network problems, whatever, but result: NO acces. See this page I created: http://wiki.koha.org/doku.php?id=ldap&s=ldap But I agree: you do need (at least some of) the various fields.
Mourik, I have a Koha 3.0 test server upgraded from an original 3.0 RC1 installation. Our I.T. systems group successfully modified /etc/ koha/koha-conf.xml and Auth_with_ldap.pm to integrate with our LDAP. After upgrading from RC1 to 3.0 I noticed that our modified koha-conf.xml and Auth_with_ldap.pm were renamed and replaced with new files. However, LDAP authentication continues to work properly despite our customizations no longer existing! What would account for this unexpected success? Paul Landers I.T. Section Manager TTUHSC Preston Smith Library paul.landers@ttuhsc.edu 806.743.2220 On May 29, 2008, at 2:03 AM, mourik jan c heupink wrote:
Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain.
I'm not (yet) familiar with koha3. Normal koha 2 ldap interface was to retrieve the actual password from ldap, and compare it with the password to user supplied. (which is a strange and incompatible way to verify a password)
Fortunately it was not difficult to change this behaviour to something else: Attempt to bind to the ldap server with the username/password to user provided.
If the binds succeeds, the password is correct. If the bind fails, there could be all sorts of problems: wrong password, ldap server down, network problems, whatever, but result: NO acces.
See this page I created: http://wiki.koha.org/doku.php?id=ldap&s=ldap
But I agree: you do need (at least some of) the various fields. _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
The (unmodified) LDAP code can be configured to copy account information into Koha at authentication. This might account for what you see. Try changing a password in the LDAP and then logging in to Koha w/ that new password. If you don't get in anymore, then you aren't currently using LDAP, but you still might have old info on anybody that logged in. --Joe On Fri, Aug 22, 2008 at 5:41 PM, Paul Landers <paul.landers@ttuhsc.edu>wrote:
Mourik, I have a Koha 3.0 test server upgraded from an original 3.0 RC1 installation. Our I.T. systems group successfully modified /etc/ koha/koha-conf.xml and Auth_with_ldap.pm to integrate with our LDAP. After upgrading from RC1 to 3.0 I noticed that our modified koha-conf.xml and Auth_with_ldap.pm were renamed and replaced with new files. However, LDAP authentication continues to work properly despite our customizations no longer existing! What would account for this unexpected success?
Paul Landers I.T. Section Manager TTUHSC Preston Smith Library paul.landers@ttuhsc.edu 806.743.2220
On May 29, 2008, at 2:03 AM, mourik jan c heupink wrote:
Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain.
I'm not (yet) familiar with koha3. Normal koha 2 ldap interface was to retrieve the actual password from ldap, and compare it with the password to user supplied. (which is a strange and incompatible way to verify a password)
Fortunately it was not difficult to change this behaviour to something else: Attempt to bind to the ldap server with the username/password to user provided.
If the binds succeeds, the password is correct. If the bind fails, there could be all sorts of problems: wrong password, ldap server down, network problems, whatever, but result: NO acces.
See this page I created: http://wiki.koha.org/doku.php?id=ldap&s=ldap
But I agree: you do need (at least some of) the various fields. _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
You were correct. Thank you. Our Systems folks originally did the mod in Auth_with_ldap.pm in the pre-RC1 release to address the bind vs. auth question, however I now read that 3.0 (final release) handles this automatically (http://wiki.koha.org/doku.php?id=en:development:ldap )? Unfortunately our Systems folks are too busy to assist us again after the upgrade. Does anyone else have some LDAP experience and could help us mod/reconfigure? In testing our LDAP from luma and phpldapadmin, successful binds can occur only if the scope is set to subtree. If only the base is specified we get bind failures. Paul On Aug 22, 2008, at 5:07 PM, Joe Atzberger wrote:
The (unmodified) LDAP code can be configured to copy account information into Koha at authentication. This might account for what you see. Try changing a password in the LDAP and then logging in to Koha w/ that new password. If you don't get in anymore, then you aren't currently using LDAP, but you still might have old info on anybody that logged in.
--Joe
On Fri, Aug 22, 2008 at 5:41 PM, Paul Landers <paul.landers@ttuhsc.edu> wrote: Mourik, I have a Koha 3.0 test server upgraded from an original 3.0 RC1 installation. Our I.T. systems group successfully modified / etc/ koha/koha-conf.xml and Auth_with_ldap.pm to integrate with our LDAP. After upgrading from RC1 to 3.0 I noticed that our modified koha-conf.xml and Auth_with_ldap.pm were renamed and replaced with new files. However, LDAP authentication continues to work properly despite our customizations no longer existing! What would account for this unexpected success?
Paul Landers I.T. Section Manager TTUHSC Preston Smith Library paul.landers@ttuhsc.edu 806.743.2220
On May 29, 2008, at 2:03 AM, mourik jan c heupink wrote:
Not returning a password probably isn't a problem. If I'm reading the C4::Auth_with_ldap code right, Koha sends the password to the LDAP and doesn't do anonymous binds. It's the lack of field data that's a pain.
I'm not (yet) familiar with koha3. Normal koha 2 ldap interface was to retrieve the actual password from ldap, and compare it with the password to user supplied. (which is a strange and incompatible way to verify a password)
Fortunately it was not difficult to change this behaviour to something else: Attempt to bind to the ldap server with the username/ password to user provided.
If the binds succeeds, the password is correct. If the bind fails, there could be all sorts of problems: wrong password, ldap server down, network problems, whatever, but result: NO acces.
See this page I created: http://wiki.koha.org/doku.php? id=ldap&s=ldap
But I agree: you do need (at least some of) the various fields. _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Sat, May 24, 2008 at 9:20 PM, Landers, Paul <paul.landers@ttuhsc.edu> wrote:
Does anyone have detailed instructions for enabling and configuring Koha 3 with LDAP for authentication? This would be one of the major reasons for us moving to Koha from our current ILS. The man page for the LDAP plugin indicates that LDAP must supply *ALL* required fields for patron records. Our I.T. has advised us of the following for our LDAP server:
It can be used for authentication only. It will not return data for fields.
It will not allow anonymous binds.
It will not return a password for Koha to compare. Koha must supply the password or the hash to LDAP.
Given these constraints, how do we configure Koha to use LDAP?
Note that some patches were recently submitted to improve the configuration of LDAP, please update from Git and read perldoc C4/Auth_with_ldap.pm to see how to configure it. And thanks to Joe Atzberger for his work on this. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
participants (7)
-
Charles Lacroix -
Joe Atzberger -
Joshua Ferraro -
Landers, Paul -
MJ Ray -
mourik jan c heupink -
Paul Landers