Bug 7973 - Allow for new type of LDAP authentication
Summary: Allow for new type of LDAP authentication
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All All
: P5 - low new feature (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-17 17:31 UTC by Elliott Davis
Modified: 2014-05-26 21:04 UTC (History)
12 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Adds different authentication method for LDAP (4.66 KB, patch)
2012-04-17 17:40 UTC, Elliott Davis
Details | Diff | Splinter Review
This patch aims to correct the LDAP bind authentication. (1.73 KB, patch)
2012-10-19 14:05 UTC, Rolando Isidoro
Details | Diff | Splinter Review
Bug 7379- Allow for new type of LDAP authentication (3.91 KB, text/plain)
2012-10-19 15:19 UTC, Rolando Isidoro
Details
[SIGNED-OFF] Bug 7973- Allow for new type of LDAP authentication (3.91 KB, patch)
2013-01-23 10:48 UTC, Vitor Fernandes
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 7973 - Allow for new type of LDAP authentication (3.95 KB, patch)
2013-03-21 09:07 UTC, Dobrica Pavlinusic
Details | Diff | Splinter Review
Bug 7973 : Follow up to remove an extraneous my (878 bytes, patch)
2013-03-21 21:52 UTC, Chris Cormack
Details | Diff | Splinter Review
[PASSED QA] Bug 7973- Allow for new type of LDAP authentication (4.08 KB, patch)
2013-03-22 06:18 UTC, Katrin Fischer
Details | Diff | Splinter Review
[PASSED QA] Bug 7973 : Follow up to remove an extraneous my (981 bytes, patch)
2013-03-22 06:21 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 7973: Fixed bug in Auth_with_ldap - Counter patch (1.64 KB, patch)
2013-09-06 10:26 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Elliott Davis 2012-04-17 17:31:59 UTC
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
Comment 1 Elliott Davis 2012-04-17 17:40:06 UTC Comment hidden (obsolete)
Comment 2 Dobrica Pavlinusic 2012-05-07 20:33:57 UTC
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.
Comment 3 Elliott Davis 2012-05-09 23:49:17 UTC
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.
Comment 4 Dobrica Pavlinusic 2012-06-11 11:21:30 UTC
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?
Comment 5 Rolando Isidoro 2012-10-19 14:05:11 UTC Comment hidden (obsolete)
Comment 6 Rolando Isidoro 2012-10-19 15:19:02 UTC Comment hidden (obsolete)
Comment 7 Vitor Fernandes 2013-01-23 10:48:53 UTC Comment hidden (obsolete)
Comment 8 Paul Poulain 2013-03-20 17:11:59 UTC
Dobrica, you made some comments, could you tell me what you think of this patch ?
Comment 9 Dobrica Pavlinusic 2013-03-21 09:07:08 UTC Comment hidden (obsolete)
Comment 10 Dobrica Pavlinusic 2013-03-21 09:08:30 UTC
This patch works well and provides simplification of our LDAP config which is always a good thing...
Comment 11 Katrin Fischer 2013-03-21 19:35:45 UTC
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?
Comment 12 Rolando Isidoro 2013-03-21 19:51:59 UTC
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
Comment 13 Chris Cormack 2013-03-21 21:52:21 UTC Comment hidden (obsolete)
Comment 14 Katrin Fischer 2013-03-22 06:18:45 UTC Comment hidden (obsolete)
Comment 15 Katrin Fischer 2013-03-22 06:20:56 UTC
I think Rolando Isidoro also needs to be added as a new committer if this gets pushed :)
Comment 16 Katrin Fischer 2013-03-22 06:21:52 UTC Comment hidden (obsolete)
Comment 17 Jared Camins-Esakov 2013-03-23 02:02:03 UTC
This patch has been pushed to master.
Comment 18 David Burke 2013-05-30 20:36:49 UTC
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.
Comment 19 Chris Cormack 2013-05-30 21:37:55 UTC
(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
Comment 20 Galen Charlton 2013-05-30 21:55:58 UTC
(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?
Comment 21 Dobrica Pavlinusic 2013-05-31 12:25:02 UTC
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.
Comment 22 Rolando Isidoro 2013-05-31 14:39:25 UTC
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.
Comment 23 David Burke 2013-05-31 14:57:21 UTC
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.
Comment 24 Dobrica Pavlinusic 2013-06-04 08:00:25 UTC
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).
Comment 25 acowell 2013-07-01 15:48:43 UTC
(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>
Comment 26 Rolando Isidoro 2013-07-01 16:05:22 UTC
Have you tried setting ´auth_by_bind´ to 0 in your koha-conf.xml? Let me know if it works for your that way.
Comment 27 acowell 2013-07-01 17:14:19 UTC
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?
Comment 28 acowell 2013-07-01 17:42:56 UTC
(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.
Comment 29 acowell 2013-07-01 18:12:40 UTC
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
Comment 30 Rolando Isidoro 2013-07-02 09:29:04 UTC
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?
Comment 31 acowell 2013-07-02 14:50:26 UTC
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.
Comment 32 Rolando Isidoro 2013-07-03 08:51:33 UTC
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.
Comment 33 acowell 2013-07-03 14:18:07 UTC
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
Comment 34 acowell 2013-07-03 14:54:32 UTC
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
Comment 35 Rolando Isidoro 2013-07-03 17:22:53 UTC
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
Comment 36 acowell 2013-07-08 12:27:47 UTC
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
Comment 37 Derryn 2013-07-30 07:36:20 UTC
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.
Comment 38 acowell 2013-07-30 12:45:26 UTC
(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
Comment 39 David Burke 2013-08-28 17:18:23 UTC
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.
Comment 40 Martin Renvoize 2013-09-06 10:26:04 UTC
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.
Comment 41 Martin Renvoize 2013-09-06 10:45:28 UTC
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.
Comment 42 Chris Cormack 2013-09-07 00:23:21 UTC
(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?
Comment 43 Martin Renvoize 2013-09-08 11:34:43 UTC
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?
Comment 44 Martin Renvoize 2013-09-08 11:57:26 UTC
Followup patch moved to new bug and this bug re-closed to prevent future confusion (all as requested/prompted by Chris C)
Comment 45 Robin Sheat 2013-09-18 04:21:23 UTC
(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.
Comment 46 Robin Sheat 2013-09-18 05:15:40 UTC
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.