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
This broke LDAP configuration after upgrade to 17.05, will tyr to provide a patch shortly
Thanks for writing this down Nick, just had this problem and couldn't even get in with the DB admin.
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
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>
Can't believe I hadn't come across this until now! Signing Off.
I just had to add the extra configs because of this last night lol.
Hi Liz, could you sign off so we can count Martin for QA?
Is this also valid for master?
I don't have a non-production LDAP to test against :(
Alex, could you have a look at this one and QA it?
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>
Thx, Brendan. Martin, are you ok with switching to PQA counting yours as QA?
Certainly, the code is solid and I'm more than happy for my SO to count as QA :)
Awesome work all! Pushed to master for 18.11
Pushed to 18.05.x for 18.05.03
Pushed to 17.11.x for 17.11.09
Pushed to 17.05.x for 17.05.14
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 ~ >
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).
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).
(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.
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.
(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
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/
Still not working in 18.05.05-1 Martin, any idea on this?
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>
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.
Hi! Experiencing the same with Koha 19.11.08.000. settings in koha_conf.xml for ldap below: <ldapserver id="ldapserver"> <hostname>ldap://ipaddress</hostname> <base>dc=xxx,dc=xxx,dc=xxx</base> <user>xxx@xxx.xxx.xxx</user> <pass>password</pass> <replicate>1</replicate> <update>1</update> <auth_by_bind>1</auth_by_bind> <anonymous_bind>0</anonymous_bind> <principal_name>cn=%s,ou=Students,dc=xxx,dc=xxx,dc=xxx</principal_name> <mapping> <!-- <userid is="uid"></userid>--> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <branchcode is="branch">BRANCHCODE</branchcode> <email is="mail"></email> </mapping> </ldapserver> Tried different combinations but still getting this error: LDAP search failed to return object : 000004DC: LdapErr: DSID-0C090728, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 I can shelldap to it: shelldap --server xx.xxx.x.xxx --basedn dc=xxx,dc=xxx,dc=xxx --binddn xxx@xxx.xxx.xxx ~ > ls root@library:/home/xxx# shelldap --server xx.xxx.x.xxx --basedn dc=xxx,dc=xxx,dc=xxx --binddn xxx@xxx.xxx.xxx ~ > ls CN=Builtin CN=Computers CN=ForeignSecurityPrincipals CN=Infrastructure CN=LostAndFound CN=Managed Service Accounts CN=NTDS Quotas CN=Program Data CN=System CN=TPM Devices CN=Test User CN=Users CN=made in. 253 OU=BoardMembers OU=Distribution Email Group OU=Domain Controllers OU=Faculty OU=Moodle3 OU=PWMUSERS OU=RDS OU=Staff OU=Students ~ >