For some ldap setups there is a different sequence for authentication that koha doesn't account for. The steps are: 1) Bind with a service account 2) Search for user entered 3) Bind as user if found
Created attachment 9233 [details] [review] Adds different authentication method for LDAP To test: 1) Add a bind_with_service xml entry to your ldap configuration and set it to 1. 2) Ensure that the service account is set up correctly 3) Connect to either the OPAC or Staff client (depending on your permissions) with your ldap creds If you successfully connect the code works.
Two quick questions: 1. Does check for anonymous really have any use in this case (since you have to have service user even for search). I'm worried that it might hide configuration errors and produce hard do debug problems. If not, I would rather return error if anonymous is set. 2. Should distinguishedName LDAP attribute as username be configurable? To be honest, I never saw usage of that attribute as login in the wild (yet, so this evidence is anecdotal, I know :-) but it nicely shows how different LDAP schemas are. Event to test it with my existing setup, I need to change source code... Comment to QA: patch is artificially large because of (much needed) code re-indent, code flow change itself is small and concise.
To answer your first question, yes that should probably be removed. Additionally, yes I think that LDAP auth configs should be user configurable. If you have any suggestions on where to configure it or how I'd love to hear them before I proceed. I'll fix the anon bit when I hear back on if you have any ideas on the config.
I was thinking about renaming bind_as_service and reusing it to specify LDAP attribute from which to get login like: <bind_to_get_login_from>distinguishedName</bind_to_get_login_from> I know it's a long name, but this way we have just one configuration option (which is good istead of having two of them which would have to be modified in pair). It also provides some sense what does it do without reading documentation. Variants include: bind_as_user_and_get_login_from, bind_as_service_and_get_login but both of those are not much better than one above. I'm welcoming suggestion for better and/or cleaner option name. What do you think?
Created attachment 12950 [details] [review] This patch aims to correct the LDAP bind authentication. Bug 1963 Problem with deleted biblio in a virtual shelf This bug reappear in HEAD/3.8. When trying to display a virtual shelf (list) containing a deleted biblio, this error message is displayed: Software error: Can't call method "field" on an undefined value at ....C4/Koha.pm line 1231. This fix modify SQL query retrieving biblios, just skipping records from virtual shelf table with no linked record in biblio table: LEFT JOIN replace with JOIN. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Created attachment 12955 [details] Bug 7379- Allow for new type of LDAP authentication This patch aims to solve the LDAP bind authentication method. Here are some considerations: - This is a standalone patch, so all the previous submitted ones are rendered obsolete; - LDAP bind authentication is now done in 3 steps: 1 - LDAP anonymous bind; 2 - LDAP search entry for the given username; 3 - LDAP bind with the DN of the found entry + the given password. - The process fails if none or more than 1 entries are found for the given username; - The <principal_name> setting in koha-conf.xml isn't used anymore; - The patch is backwards compatible, so users already using the previously implemented LDAP bind authentication should be able to use it the same.
Created attachment 14775 [details] [review] [SIGNED-OFF] Bug 7973- Allow for new type of LDAP authentication This patch aims to solve the LDAP bind authentication method. Here are some considerations: - This is a standalone patch, so all the previous submitted ones are rendered obsolete; - LDAP bind authentication is now done in 3 steps: 1 - LDAP anonymous bind; 2 - LDAP search entry for the given username; 3 - LDAP bind with the DN of the found entry + the given password. - The process fails if none or more than 1 entries are found for the given username; - The <principal_name> setting in koha-conf.xml isn't used anymore; - The patch is backwards compatible, so users already using the previously implemented LDAP bind authentication should be able to use it the same. http://bugs.koha-community.org/show_bug.cgi?id=7973 Signed-off-by: Vitor Fernandes
Dobrica, you made some comments, could you tell me what you think of this patch ?
Created attachment 16580 [details] [review] [SIGNED-OFF] Bug 7973 - Allow for new type of LDAP authentication This patch aims to solve the LDAP bind authentication method. Here are some considerations: - This is a standalone patch, so all the previous submitted ones are rendered obsolete; - LDAP bind authentication is now done in 3 steps: 1 - LDAP anonymous bind; 2 - LDAP search entry for the given username; 3 - LDAP bind with the DN of the found entry + the given password. - The process fails if none or more than 1 entries are found for the given username; - The <principal_name> setting in koha-conf.xml isn't used anymore; - The patch is backwards compatible, so users already using the previously implemented LDAP bind authentication should be able to use it the same. http://bugs.koha-community.org/show_bug.cgi?id=7973 Signed-off-by: Vitor Fernandes Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
This patch works well and provides simplification of our LDAP config which is always a good thing...
Sadly, as I wanted to pass QA on this if the test suite was ok... we have an error in the QA script: * C4/Auth_with_ldap.pm FAIL pod OK forbidden patterns OK valid FAIL "my" variable $res masks earlier declaration in same scope critic OK Someone willing to write a follow up?
Hi Katrin, unfortunately I won't be able to fix it any time soon, but just from a glance I'd say all it takes is to remove the "my" at line 122 since it masks earlier declaration at line 111. Best regards, Rolando
Created attachment 16686 [details] [review] Bug 7973 : Follow up to remove an extraneous my
Created attachment 16703 [details] [review] [PASSED QA] Bug 7973- Allow for new type of LDAP authentication This patch aims to solve the LDAP bind authentication method. Here are some considerations: - This is a standalone patch, so all the previous submitted ones are rendered obsolete; - LDAP bind authentication is now done in 3 steps: 1 - LDAP anonymous bind; 2 - LDAP search entry for the given username; 3 - LDAP bind with the DN of the found entry + the given password. - The process fails if none or more than 1 entries are found for the given username; - The <principal_name> setting in koha-conf.xml isn't used anymore; - The patch is backwards compatible, so users already using the previously implemented LDAP bind authentication should be able to use it the same. http://bugs.koha-community.org/show_bug.cgi?id=7973 Signed-off-by: Vitor Fernandes Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Passes all tests and QA script and has 2 solid sign offs.
I think Rolando Isidoro also needs to be added as a new committer if this gets pushed :)
Created attachment 16704 [details] [review] [PASSED QA] Bug 7973 : Follow up to remove an extraneous my Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Fixes problem found by QA scripts.
This patch has been pushed to master.
I believe this change has broken ldap for me. I'm new to this so please correct me if I'm wrong. As stated the new way to authenticate in Koha 4.12 seems to work like this: 1 - LDAP anonymous bind; 2 - LDAP search entry for the given username; 3 - LDAP bind with the DN of the found entry + the given password. In my case with Active Directory it's possible to bind anonymously but the anon user is not allowed to search. So I get something this in step 2. (sAMAccountName=dburke) gets 0 hits, I reverted the patch and it works again. I also had to remove a return 0; on line 130 of Auth_with_ldap.pm. Not sure what this is about. I suspect this would break a good number of ldap set ups. I know Zentyal 3.0's openldap schema follows the same behavior of not allowing anon users to search.
(In reply to comment #18) > I believe this change has broken ldap for me. I'm new to this so please > correct me if I'm wrong. > > As stated the new way to authenticate in Koha 4.12 seems to work like this: > 1 - LDAP anonymous bind; > 2 - LDAP search entry for the given username; > 3 - LDAP bind with the DN of the found entry + the given password. > 3.12 right? > In my case with Active Directory it's possible to bind anonymously but the > anon user is not allowed to search. So I get something this in step 2. > > (sAMAccountName=dburke) gets 0 hits, > > I reverted the patch and it works again. I also had to remove a return 0; on > line 130 of Auth_with_ldap.pm. Not sure what this is about. > > I suspect this would break a good number of ldap set ups. I know Zentyal > 3.0's openldap schema follows the same behavior of not allowing anon users > to search. That sounds like a real valid issue, could you please open a new bug. With this bug report (id mark it critical maybe even blocker) And as much information as you can. My suggestion for a patch to fix it, would be to make the new behaviour configurable in the koha-conf.xml so that it can be turned on for those who want it. Off for those like yourself that it breaks. It would be even more awesome if you could that patch, I would buy you a beverage of your choice at Kohacon
(In reply to comment #18) > I suspect this would break a good number of ldap set ups. I know Zentyal > 3.0's openldap schema follows the same behavior of not allowing anon users > to search. And as part of exploring the option space and helping make sure that everybody ends up happy, does anybody know of specific (preferably FL/OSS) LDAP servers that by default *do* allow anon users to seearch?
We are using OpenLDAP (from Debian packages), but it depends on specific LDAP configuration and not on particular server. I'm not LDAP admin here, but I can ask for configuration settings if that's helpful. We have configuration which allows anonymous searching and returns *some* fields from LDAP but after auth if returns all user attributes (it's EduRoam configuration which is quite common in Europe). I tested this patch with auth by bind (which we use) so I feel somewhat guilty if we broke AD along the way.
Dobrica, it's been sometime since I wrote the patch, but if I recall it correctly I didn't overwrite the old method for LDAP auth that worked for you. Have you tried setting ´auth_by_bind´ to 0 in your koha-conf.xml? Let me know if it works for your that way.
I did mean 3.12. I know from experience that Zentyal changed this from version 2.2 > 3.0. They used to allow anon searching. It broke quite a few things for me. In any case it seems reasonable not to allow anon users to see what users exist in LDAP. I'd be happy to test anything with my AD server. Thanks for being so responsive to the issue.
David, can you please post your ldap config from koha-conf.xml? From looking at a code I agree with Rolando that setting auth_by_bind to 1 should fix your problem (hopefully).
(In reply to Dobrica Pavlinusic from comment #24) > David, can you please post your ldap config from koha-conf.xml? From looking > at a code I agree with Rolando that setting auth_by_bind to 1 should fix > your problem (hopefully). I receive the same issue running the latest koha-common received via APT-GET and trying to set up active directory. It doesn't seem to matter what I use for hostname... LDAP:// LDAPS:// or just straight qualified name of AD LDAP server. I always receive the below error messages. I also should state that we are on Windows 2008 Domain and I believe that anonymous is turned off. [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: Use of uninitialized value in string ne at /usr/share/koha/lib/C4/Auth.pm line 670, <DATA> line 522., referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at /usr/share/koha/lib/C4/Auth.pm line 780, <DATA> line 522., referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at /usr/share/koha/lib/C4/Auth.pm line 780, <DATA> line 522., referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: LDAP Auth rejected : (sAMAccountName=duser2) gets 0 hits, referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: LDAP error #1: LDAP_OPERATIONS_ERROR, referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: # Server encountered an internal error, referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: , referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Mon Jul 01 11:19:34 2013] [error] [client 127.0.0.1] [Mon Jul 1 11:19:34 2013] opac-user.pl: Use of uninitialized value $retuserid in string ne at /usr/share/koha/lib/C4/Auth.pm line 817, <DATA> line 551., referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl This is my koha-conf.xml file which as far as I can tell matches all of the requirements...? Can you verify for me? <useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on --> <ldapserver id="ldapserver" listenref="ldapserver"> <hostname>ldaps://[server qualified name]</hostname> <base>dc=[domain],dc=[extension]</base> <user>[CN OU DN Information]</user> <!-- DN, if not anonymous --> <pass>[PASSWORD]</pass><!-- password, if not anonymous --> <replicate>1</replicate> <!-- add new users from LDAP to Koha database --> <update>1</update> <!-- update existing users in Koha database --> <auth_by_bind>1</auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory --> <principal_name>%s@daviscollege.edu</principal_name> <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid --> <mapping> <!-- match koha SQL field names to your LDAP record field names --> <firstname is="givenname"></firstname> <surname is="sn"> </surname> <address is="postaladdress"></address> <city is="l"></city> <branchcode is="branch">[Branch Code]</branchcode> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <email is="mail"></email> <categorycode is="category">[category code]</categorycode> <phone is="ExtensionAttribute1"></phone> </mapping> </ldapserver> </config>
Have you tried setting ´auth_by_bind´ to 0 in your koha-conf.xml? Let me know if it works for your that way.
Yes, I tried 0 and 1... You know I just noticed that there are diffs attached and when I compare those files with koha-common files the changes are not there... I assume I need to download the two attached diffs and patch the files. Then test again?
(In reply to acowell from comment #27) > Yes, I tried 0 and 1... You know I just noticed that there are diffs > attached and when I compare those files with koha-common files the changes > are not there... I assume I need to download the two attached diffs and > patch the files. Then test again? Sorry, never mind, I was reading the DIFF backwards and the changes are applied in latest 3.12 common that I'm running. After making changes to koha-conf.xml do you need to restart the apache or koha-common service or should things happen in live time? Sorry, new to Koha and this is the one show stopper from us being able to deploy koha at our college.
Just to update... I changed <update> to 0 and <auth_by_bind> to 0 and now I get this in my OPAC Error log. [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: Use of uninitialized value in string ne at /usr/share/koha/lib/C4/Auth.pm line 670, <DATA> line 522., referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at /usr/share/koha/lib/C4/Auth.pm line 780, <DATA> line 522., referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: Use of uninitialized value $pki_field in string eq at /usr/share/koha/lib/C4/Auth.pm line 780, <DATA> line 522., referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: LDAP Auth rejected : invalid password for user '<<USERNAME>>'. LDAP error #16: LDAP_NO_SUCH_ATTRIBUTE, referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: # The request referenced an attribute that does not exist, referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: , referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl [Mon Jul 01 13:59:31 2013] [error] [client 10.0.1.88] [Mon Jul 1 13:59:31 2013] opac-user.pl: Use of uninitialized value $retuserid in string ne at /usr/share/koha/lib/C4/Auth.pm line 817, <DATA> line 581., referer: http://10.0.1.99/cgi-bin/koha/opac-user.pl
From reading the entries you posted from your error log, it seems the main one, LDAP Auth rejected : invalid password for user '<<USERNAME>>'. LDAP error #16: LDAP_NO_SUCH_ATTRIBUTE, refers to a piece of code from Auth_with_ldap.pm that remained unchanged. Looking at the source code it seems like your LDAP entries don't have an 'userpassword' attribute, which results in the failed authentication process. Again, the patch aimed to solve LDAP auth with anonymous bind. If that's your LDAP server scenario, then you should be able to login with the 'auth_by_bind' set to 1. Otherwise, 'auth_by_bind' should be set to 0. To try to help you further, can you ask your LDAP server admins a step-by-step description of the authentication process of you setup?
You would be correct, in a windows active directory domain the userPassword attribute is a write-only field. When viewed, it says <NOT SET>. If I set auth_by_bind to 1 I receive this following error, no matter what user account I attempt to login as. I also do not see a failed login attempt in the LDAP server security event logs, so it’s like it’s failing before even attempting to connect to the LDAP server. [Tue Jul 02 08:11:39 2013] [error] [client 127.0.0.1] [Tue Jul 2 08:11:39 2013] opac-user.pl: LDAP Auth rejected : (sAMAccountName=duser1) gets 0 hits, referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl [Tue Jul 02 08:11:39 2013] [error] [client 127.0.0.1] [Tue Jul 2 08:11:39 2013] opac-user.pl: LDAP error #1: LDAP_OPERATIONS_ERROR, referer: http://127.0.1.1/cgi-bin/koha/opac-user.pl What is strange, is if I set auth_by_bind to 0. I see in my domain controller this log that is scored by the auth_by_bind user, but won’t authenticate or create the users account in koha. An operation was performed on an object. Subject : Security ID: <domain>\<binding user> Account Name: <binding user> Account Domain: <domain> Logon ID: 0x29a39618 Object: Object Server: DS Object Type: user Object Name: CN=Dummy User,OU=<Sub OU>,OU=<Sub OU>,OU=<Sub OU>,OU=<Sub OU>,DC=<domain>,DC=<domain ext> Handle ID: 0x0 Operation: Operation Type: Object Access Accesses: Control Access Access Mask: 0x100 Properties: Control Access {91e647de-d96f-4b70-9557-d63ff4f3ccd8} {6617e4ac-a2f1-43ab-b60c-11fbd1facf05} {b3f93023-9239-4f7c-b99c-6745d87adbc2} {b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7} {771727b1-31b8-4cdf-ae62-4fe39fadf89e} {612cb747-c0e8-4f92-9221-fdd5f15b550d} {bf967aba-0de6-11d0-a285-00aa003049e2} Additional Information: Parameter 1: - Parameter 2: As for a step by step processing, we’re pretty much a pure Windows 2008 Domain Model right out of the box. So I’m not sure exactly what type of step by step I could provide, besides Microsoft documentation on authentication processes. http://technet.microsoft.com/en-us/library/cc755284(v=ws.10).aspx I can say that we have a Moodle server that is doing LDAPS authentication right to both of our domain controllers. A couple of notes from that server that I don’t see the ability to set in Koha is these options. LDAP Version = 3 LDAP Encoding = cp1252 I also see in Koha you can set a BASE, but in Moodle you set a context which is the first container to begin searching for users in. ou=<OU>,dc=<DOMAIN>,dc=<DOMAIN EXT> I switched the <BASE> in koha to CN=Users, DC=<DOMAIN>, DC=<DOMAIN EXT> and moved the Dummy User to the Users container. But that didn’t work either, still receive the above LDAP_OPERATIONS_ERROR. I did a little more testing and actually fired up wireshark on the domain controller I'm trying to authenticate against. If I use Ubuntu's ldapsearch with the same information I'm using in the Koha-conf files. I get an LDAP bindRequest(1) "duser1@daviscollege.edu" simple. When I attempt to authenticate through Koha. I get 'bindRequest(1) "<ROOT>" simple'. It's like Koha is not actually passing the authenticating users userPrincipleName through correctly.
I too manage some Moodle installations with LDAP auth and it works the same way as in our Koha installation. Nevertheless I'm already looking at Moodle's LDAP settings and source code to try to understand how they implement the AD case. All that technical info from MS' site is too much and not conclusive, I was looking for something in the likes of what I wrote on comment #6 of this thread. If you can provide such a description that would be a plus.
Those steps are exactly how I believe it should be handled. However, I notice this line. - The <principal_name> setting in koha-conf.xml isn't used anymore; That appears to be the problem with AD LDAP. I wish I could upload a picture of my Wireshark results. On the bindRequest(1) "<ROOT>" packet coming from Koha login attempt it says that the authentication is simple, but the authentication name is missing. I'm wondering if it's missing because the principal_name is not passed to AD/LDAP now? On the ldapsearch in Ubuntu, when I capture those packets. The authentication is simple, but it has the binding account username & password filled in, in the bindRequest. I'm not sure if this site might help you at all, but I just stumbled a crossed it and thought I'd share. http://www.netid.washington.edu/documentation/ldapAuth.aspx Basically, password are passed to LDAP to verify that an account can connect. If it can, then success and then grab Attributes. Now AD LDAP Doesn't store passwords in readable formats in attributes, instead I believe it utilizes some type of tokens. Koha should not store the password for the user that authenticated or tokens. I don't know how Koha actually looks at authentication, like if it always attempts ldap before local auth lookups if use ldap is set to 1 or not. But LDAP auth should be prioritized over local auth and the locally stored record of the users account should be created with a field or tagged some how indicating that it's an LDAP user, so whenever the system tries to verify the account it always checks against LDAP. Maybe I'm just babbling and Koha already does this in some sort. Aaron
Ok, I just had a major break through and realized, hey... why don't I just reverse this patch and see what happens... SUCCESS! I can now authenticate to Active Directory LDAP with no problems! I believe that it's the dropping out of using the principal_name that broke AD LDAP Auth. Aaron
Can you paste the LDAP section of your current working koha-conf.xml? I'll try to come up with an update to the patch to allow your AD LDAP auth scenario without messing with the existing ones. Guess I didn't succeed in my previous effort :s
Sorry for the delay, extended holiday break and just getting back into the swing of things. Here's my koha-conf.xml that is working after reverting this patch. <useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on --> <ldapserver id="ldapserver" listenref="ldapserver"> <hostname>ldap://<<SERVER NAME/IP>></hostname> <base>DC=<<DOMAIN>>,DC=<<DOMAIN EXT>></base> <user>CN=<<Users name>>,OU=<<Sub OU>>,OU=<<Sub OU>>,OU=<<Sub OU>>,OU=<<Sub OU>>,dc=<<DOMAIN>>,dc=<<DOMAIN EXT>></user> <!-- DN, if not anonymous --> <pass><<USERS PASSWORD>></pass> <!-- password, if not anonymous --> <replicate>1</replicate> <!-- add new users from LDAP to Koha database --> <update>1</update> <!-- update existing users in Koha database --> <auth_by_bind>1</auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory --> <principal_name>%s</principal_name> <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid --> <mapping> <!-- match koha SQL field names to your LDAP record field names --> <firstname is="givenname"></firstname> <surname is="sn"> </surname> <address is="streetAddress"></address> <city is="l"></city> <state is="st"></state> <country is="c"></country> <branchcode is="<<BRANCH CODE ATTRIBUTE IN AD"><<DEFAULT BRANCH CODE>></branchcode> <userid is="userPrincipalName"></userid> <password is=""></password> <email is="mail"></email> <categorycode is="<<DEFAULT CATEGORY CODE ATTRIBUTE>>"><<DEFAULT CATEGORY CODE>></categorycode> <cardnumber is="<<CARD NUMBER ATTRIBUTE>>"></cardnumber> </mapping> </ldapserver> ------------------------------- To note, we authenticate by using email addresses, so for the userid, I used the userPrincipalName and changed the <principle_name> to <principal_name>%s</principal_name> instead of what most talk about doing <principal_name>%s@<<domain name & ext>></principal_name>. I did try the common way of using the sAMAccountName for the userid attribute and using %s@domain.ext for principal_name and that way worked as well. I also started testing under LDAP:// to be able to sniff out the problem, but will be testing under LDAPS://, but don't expect a problem, will update if it doesn't work after testing. Thanks for your attention to this matter! Aaron
We're running into the exact same issues here on AD 2008. We've tried with/without bind. Is there a way to get this working in the meantime? We're running the tarball version so reverting patches aren't as simple as with Git installs. I updated to 3.12.1 and after a bit of testing it all seemed fine because we didn't have any new users. But once we did, we started getting failed logins everywhere. I would request this be marked as a blocker and that it be removed from all future versions until this is fixed.
(In reply to Derryn from comment #37) > We're running into the exact same issues here on AD 2008. We've tried > with/without bind. Is there a way to get this working in the meantime? > We're running the tarball version so reverting patches aren't as simple as > with Git installs. I updated to 3.12.1 and after a bit of testing it all > seemed fine because we didn't have any new users. But once we did, we > started getting failed logins everywhere. I would request this be marked as > a blocker and that it be removed from all future versions until this is > fixed. Derryn, I looked at the patch diff above and reversed the lines of codes that was changed by copying & pasting the old code back in. I'm emailing you our Auth_with_ldap.pm file, I'm note sure if there were any changes between 3.12 and 3.12.1. I do know that there is some other people out there working on changing the LDAP authentication, was trying to find the link but no luck so far. But it appeared at the time that it was a complete re-write of the LDAP authentication in Koha. Maybe slated for 3.14 release. Aaron
I updated and at some point ldap, even with my previous and functional hacks, does not function anymore. At this point I've given up on it. Could you send me this modified Auth_with_ldap.pm to test though? I'm also trying on a Zentyal 3.0 server that has both samba ldap and openldap. I can't get it to work but that could be for many reasons.
Created attachment 20821 [details] [review] Bug 7973: Fixed bug in Auth_with_ldap - Counter patch I came across this issue at one of our sites today and patched it before finding the bugzilla entry. The patch already here seems to overcomplicate the issue somewhat unless I'm completely missing something. Attached is my counter patch proposal.
So, my patch test plan differs slightly as I don't add additional requirements to the config. 1. Set auth_by_bind to 1 in the conf.xml as we still want to auth by bind. 2. Also set a user and pass in the conf.xml as we want to use an ldapuser to authenticate the initial search 3. Test that authentication works So, my patch does not require the addition of 'bind_with_service' to the xml config, instead it uses the existing user and pass params.
(In reply to Martin Renvoize from comment #40) > Created attachment 20821 [details] [review] [review] > Bug 7973: Fixed bug in Auth_with_ldap - Counter patch > > I came across this issue at one of our sites today and patched it before > finding the bugzilla entry. > > The patch already here seems to overcomplicate the issue somewhat unless I'm > completely missing something. > > Attached is my counter patch proposal. The patches here have already been pushed Martin. I am obsoleting them. So your patch is not so much a counter patch as a new one, and should be on its own bug, this bug should not have been reopened once the patches were pushed, a new bug should have been lodged. That is of course not your fault, but it still is probably best you put the patch on a new bug, and we close this again. Sound ok?
Oops, I hadn't spotted that this was already in, even though my patch applies on top of it.. what a Muppet! Anywho, I'm glad the original patch is in and makes the ldap code leaner, although I'm still confused as to how it fixes the original bug reported? (It doesn't in my configuration else I wouldn't have got confused and created the patch in the first place ;) ) I'll open a new bug and move my patch over to it. Sounds fine to me to have this bug completely closed to knock it on the head. Apologies for the confusion. Martin (In reply to Chris Cormack from comment #42) > (In reply to Martin Renvoize from comment #40) > > Created attachment 20821 [details] [review] [review] [review] > > Bug 7973: Fixed bug in Auth_with_ldap - Counter patch > > > > I came across this issue at one of our sites today and patched it before > > finding the bugzilla entry. > > > > The patch already here seems to overcomplicate the issue somewhat unless I'm > > completely missing something. > > > > Attached is my counter patch proposal. > > The patches here have already been pushed Martin. I am obsoleting them. > > So your patch is not so much a counter patch as a new one, and should be on > its own bug, this bug should not have been reopened once the patches were > pushed, a new bug should have been lodged. > > That is of course not your fault, but it still is probably best you put the > patch on a new bug, and we close this again. > > Sound ok?
Followup patch moved to new bug and this bug re-closed to prevent future confusion (all as requested/prompted by Chris C)
(In reply to Martin Renvoize from comment #44) > Followup patch moved to new bug and this bug re-closed to prevent future > confusion (all as requested/prompted by Chris C) Specifically, the follow up is in bug 10842.
OK, the problem here is that it breaks LDAP anyone who doesn't have anon searching or single-account searching. Which I thought was the whole point of having auth_by_bind anyway (i.e. that it authenticates by binding as the user supplied because you have nothing else configured to do this with on the LDAP side.) I've created bug 10908 to make a fix for this.