Bug 18947 - Unexpected Active Directory LDAP authentication failure mode
Summary: Unexpected Active Directory LDAP authentication failure mode
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All Linux
: P5 - low major (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on: 6979
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-17 18:31 UTC by Sven Coenye
Modified: 2018-11-06 17:51 UTC (History)
12 users (show)

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


Attachments
Bug 18947 - LDAP: do not assume anonymous bind if no user or password (6.01 KB, patch)
2017-12-13 13:38 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 18947 - LDAP: do not assume anonymous bind if no user or password (6.09 KB, patch)
2018-07-12 09:52 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 18947 - LDAP: do not assume anonymous bind if no user or password (6.15 KB, patch)
2018-08-17 19:47 UTC, Brendan Gallagher
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Coenye 2017-07-17 18:31:19 UTC
Commit 68c365ea8ab536a85d92d3769b0bbaa0e1691116 introduced the following line in Auth_with_ldap.pm:

$ldap->{anonymous_bind} = 1 unless $ldapname && $ldappassword;

There is no comment in the code or the Git commit log as to why.

This change silently overrides the settings in koha-conf.xml and causes a previously functional setup with LDAP authentication against Active Directory to fail unless koha-conf.xml defines values for <user> and <pass>. As user and pass are only used if auth_by_bind and anonymous_bind are both false, their values should not come into play in the other cases.

Prior to this change, KOHA would bind against AD with the user supplied credentials, as expected. With the change, KOHA attempts an anonymous bind and then tries to search for the supplied user name. As there was no valid bind in place, AD rejects the attempt.

Workaround: enter some value for <user> and <pass> in the ldapserver configuration block. These do not have to be real credentials as KOHA will not attempt to use them now that auth_by_bind has priority again.

Note: there is an apparent duplicate attempt to do the same further down, by setting $config{anonymous} to ($ldapname and $ldappassword) ? 0 : 1, although that key is not used anywhere in Auth_by_ldap.pm
Comment 1 Nick Clemens 2017-11-06 14:34:03 UTC
This broke LDAP configuration after upgrade to 17.05, will tyr to provide a patch shortly
Comment 2 Liz Rea 2017-11-30 22:39:25 UTC
Thanks for writing this down Nick, just had this problem and couldn't even get in with the DB admin.
Comment 3 Nick Clemens 2017-12-13 13:38:45 UTC
Created attachment 69777 [details] [review]
Bug 18947 - LDAP: do not assume anonymous bind if no user or password

To test:
Ideally tested on a working ldap server with bind by auth and no
anonymous bind
1  - Define an LDAP config with bind by auth
2  - Don't define user/pass
3  - Define anonymous_bind = 0
4  - Attempt bind by auth
5  - Error is something like:
LDAP search failed to return object : XXXXXXXXX: LdapErr: XXXX-XXXXXX,
     comment: In order to perform this operation a successful bind must
     be completed on the connection., data 0, v2580 at
     /usr/share/koha/lib/C4/Auth_with_ldap.pm line 102.
6  - Define user/pass
7  - Now bind by auth should work
8  - remove user/pass
9  - Apply patch
10 - Attempt again
11 - Bind by auth shoudl succeed

prove -v t/db_dependent/Auth_with_ldap.t
Comment 4 Martin Renvoize 2018-07-12 09:52:21 UTC
Created attachment 76879 [details] [review]
Bug 18947 - LDAP: do not assume anonymous bind if no user or password

To test:
Ideally tested on a working ldap server with bind by auth and no
anonymous bind
1  - Define an LDAP config with bind by auth
2  - Don't define user/pass
3  - Define anonymous_bind = 0
4  - Attempt bind by auth
5  - Error is something like:
LDAP search failed to return object : XXXXXXXXX: LdapErr: XXXX-XXXXXX,
     comment: In order to perform this operation a successful bind must
     be completed on the connection., data 0, v2580 at
     /usr/share/koha/lib/C4/Auth_with_ldap.pm line 102.
6  - Define user/pass
7  - Now bind by auth should work
8  - remove user/pass
9  - Apply patch
10 - Attempt again
11 - Bind by auth shoudl succeed

prove -v t/db_dependent/Auth_with_ldap.t

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 5 Martin Renvoize 2018-07-12 09:52:57 UTC
Can't believe I hadn't come across this until now!

Signing Off.
Comment 6 Liz Rea 2018-07-13 00:36:31 UTC
I just had to add the extra configs because of this last night lol.
Comment 7 Katrin Fischer 2018-07-13 06:03:56 UTC
Hi Liz, could you sign off so we can count Martin for QA?
Comment 8 Katrin Fischer 2018-07-15 17:55:26 UTC
Is this also valid for master?
Comment 9 Liz Rea 2018-07-15 20:53:41 UTC
I don't have a non-production LDAP to test against :(
Comment 10 Jonathan Druart 2018-08-06 13:25:07 UTC
Alex, could you have a look at this one and QA it?
Comment 11 Brendan Gallagher 2018-08-17 19:47:52 UTC
Created attachment 78001 [details] [review]
Bug 18947 - LDAP: do not assume anonymous bind if no user or password

To test:
Ideally tested on a working ldap server with bind by auth and no
anonymous bind
1  - Define an LDAP config with bind by auth
2  - Don't define user/pass
3  - Define anonymous_bind = 0
4  - Attempt bind by auth
5  - Error is something like:
LDAP search failed to return object : XXXXXXXXX: LdapErr: XXXX-XXXXXX,
     comment: In order to perform this operation a successful bind must
     be completed on the connection., data 0, v2580 at
     /usr/share/koha/lib/C4/Auth_with_ldap.pm line 102.
6  - Define user/pass
7  - Now bind by auth should work
8  - remove user/pass
9  - Apply patch
10 - Attempt again
11 - Bind by auth shoudl succeed

prove -v t/db_dependent/Auth_with_ldap.t

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Comment 12 Katrin Fischer 2018-08-19 11:25:03 UTC
Thx, Brendan. Martin, are you ok with switching to PQA counting yours as QA?
Comment 13 Martin Renvoize 2018-08-20 09:02:49 UTC
Certainly, the code is solid and I'm more than happy for my SO to count as QA :)
Comment 14 Nick Clemens 2018-08-21 13:54:25 UTC
Awesome work all!

Pushed to master for 18.11
Comment 15 Martin Renvoize 2018-08-24 08:58:39 UTC
Pushed to 18.05.x for 18.05.03
Comment 16 Fridolin SOMERS 2018-08-28 12:59:20 UTC
Pushed to 17.11.x for 17.11.09
Comment 17 Fridolin SOMERS 2018-09-24 13:00:05 UTC
Pushed to 17.05.x for 17.05.14
Comment 18 jesus 2018-10-05 09:01:58 UTC
I think something is broken here yet... 

I updated from 17.11.04-1 to 18.05.04-1 stock Debian packages. This update broke my functioning ldap configuration.

What I see is that if ldap is enabled and using auth_by_bind, I am not able to login either using any local accounts or AD ones, and I get this error:

LDAP search failed to return object : 000004DC: LdapErr: DSID-0C09075A, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 at /usr/share/koha/lib/C4/Auth_with_ldap.pm line 101.

My version is:

root@newkoha:~# apt-cache show koha-common
Package: koha-common
Source: koha
Version: 18.05.04-1
Architecture: all


My koha ldap config is:

<ldapserver id="ldapserver">
  <hostname>some.ip.address.here</hostname>
  <!--base>ou=alumnos,dc=aulas,dc=campus,dc=local</base -->
  <base>dc=aulas,dc=campus,dc=local</base>
  <user>biblio@aulas.campus.local</user><!-- DN, if not anonymous -->
  <pass>some.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>
  <anonymous_bind>0</anonymous_bind>
  <principal_name>%s@aulas.campus.local</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 -->
   <userid       is="cn"></userid>
   <password     is=""></password>
   <email        is="userprincipalname"></email>
   <firstname    is="givenName"></firstname>
   <surname      is="displayName"></surname>
   <dateexpiry   is="">2100-01-01</dateexpiry>
   <categorycode is="">PT</categorycode>
  </mapping>
</ldapserver>


My ldap infrastructure works just fine:

root@newkoha:~# shelldap --server some.ip.address.here --basedn DC=aulas,DC=campus,DC=local --binddn biblio@aulas.campus.local
~ > ls
CN=Builtin
CN=Computers
CN=ForeignSecurityPrincipals
CN=Infrastructure
CN=Keys
CN=LostAndFound
CN=Managed Service Accounts
CN=NTDS Quotas
CN=Program Data
CN=System
CN=TPM Devices
CN=Users
CN=kms
OU=Actualizador
OU=Alumnos
OU=Aula S1-02
OU=Aula S2-01
OU=Aula S2-02
OU=AulaS1-2_Mac
OU=Aulas Teoria
OU=Domain Controllers
OU=GRUPOS_ALUMNOS
OU=Impresoras
OU=Mac
OU=Ordenadores
OU=Profesores
~ >
Comment 19 Martin Renvoize 2018-10-05 09:35:57 UTC
Hi Jesus, 

I'm just trying to get to the bottom of this one.. could you verify a 'grep' (or 'search') works using your shelldap client using the biblio user for connection?  That's is a bit closer to how Koha functions internally than the 'ls' command you included.

The basic flow in your configuration after the patch is to bind as biblio then ldapsearch for user, and finally bind as the user that has been found.  Before the patch, contrary to the documentation the initial service bind was not taking place, the search was not executed and instead a direct bind was attempted using the constructed ldapuser name of the user (constructed using the principal_name configuration).
Comment 20 Martin Renvoize 2018-10-05 09:52:11 UTC
Hang on.. I just re-read the code again.

So.. it will be binding on the 'user' (not the service user as defined in the config, but the user whose trying to login).. then as you've got 'update' and 'replicate' enabled that same just bound user will do an ldapsearch upon themselves.

That doesn't feel right. I bet you're normal koha users don't have search permissions (even to search for themselves) on the ldap directory (and nor should they).
Comment 21 Martin Renvoize 2018-10-05 10:44:20 UTC
(In reply to Martin Renvoize from comment #20)
> That doesn't feel right. I bet you're normal koha users don't have search
> permissions (even to search for themselves) on the ldap directory (and nor
> should they).

Ignore the 'and nor should they' there.. it seems in LDAP to only way to get back the ldapentry for yourself is indeed to search for yourself, so it does make sense for a uesr to be able to bind and then search for themselves.
Comment 22 jesus 2018-10-05 14:40:05 UTC
Yep, no problem with searching even for other users:

ou=Profesores,~ > grep cn=Profesor
CN=Profesor,OU=Profesores,DC=aulas,DC=campus,DC=local
ou=Profesores,~ >

I'm even more concerned about the impossibility of login for local koha users or even cached credentials.
Comment 23 Nick Clemens 2018-10-10 16:35:36 UTC
(In reply to jesus from comment #22)
> Yep, no problem with searching even for other users:
> 
> ou=Profesores,~ > grep cn=Profesor
> CN=Profesor,OU=Profesores,DC=aulas,DC=campus,DC=local
> ou=Profesores,~ >
> 
> I'm even more concerned about the impossibility of login for local koha
> users or even cached credentials.

Are you still experiencing issues? So far all cases we have seen have been remedied by adding <anonymous_bind>0</anonymous_bind> and restarting memcached and apache
Comment 24 jesus 2018-10-11 08:56:29 UTC
Yes, I'm still experiencing this issue.

You can see my configuration above with <anonymous_bind>0</anonymous_bind> and I have restarted the server several times.

This is my test server before upgrading the production one, so I am free to debug in whatever way you may further consider.

User and password check ok with shelldap, but I still get auth rejected error when trying to access the OPAC:

[Thu Oct 11 10:53:42.471369 2018] [cgi:error] [pid 1611] [client 192.168.222.176:50338] AH01215: [Thu Oct 11 10:53:42 2018] opac-user.pl: LDAP Auth rejected : search with filter '(cn=biblio)' returns no hit: /usr/share/koha/opac/cgi-bin/opac/opac-user.pl, referer: http://campus.koha.somedomain.es/
Comment 25 jesus 2018-10-24 10:47:03 UTC
Still not working in 18.05.05-1

Martin, any idea on this?
Comment 26 Victor Grousset/tuxayo 2018-10-30 15:29:08 UTC
Hi, we got the error at /usr/share/koha/lib/C4/Auth_with_ldap.pm line 101
on two instances when updating from 17.11.06 to 17.11.09
And <anonymous_bind>0</anonymous_bind> worked
(with a restart of memcached and starman/plack)

Here is the rest of the config if that can help those for which anonymous_bind isn't enough.


 <ldapserver id="SOME_ID">
      <hostname>ldaps://SOME_IP_ADDR</hostname>
      <user>CN=FOOBAR,OU=FOOBAR,OU=FOOBAR,DC=FOOBAR,DC=FOOBAR</user>
      <pass>FOOBAR</pass>
      <base>ou=FOOBAR,ou=FOOBAR,dc=FOOBAR,dc=FOOBAR</base>
      <principal_name>cn=%s, ou=FOOBAR,ou=FOOBAR,dc=FOOBAR,dc=FOOBAR</principal_name>
      <update>1</update>
      <replicate>1</replicate>
      <anonymous>0</anonymous>
      <auth_by_bind>0</auth_by_bind>
      <anonymous_bind>0</anonymous_bind>
      <mapping>
         <firstname    is="givenName"           ></firstname>
         <surname      is="sn"                  ></surname>
         [...]
      </mapping>
 </ldapserver>
Comment 27 jesus 2018-11-06 17:51:47 UTC
Thanks Victor,

<auth_by_bind>0</auth_by_bind> did the trick for me...

I discovered that I also had problems with the user I was testing with: Despite being active and able to browse the directory with shelldap, it wouldn't be able to login successfully to koha. Deleting the user and creating it again cleared the error for me.