Koha is a free library software that we use at our school. We use it to manage both our teaching materials and our school library. Previously we used LITTERA for this, but since last summer we have switched completely to Koha. The core of our school infrastructure is a linuxmuster.net school server. Every student and colleague has an internal username, which is needed to log in at our school computers. linuxmuster.net has a LDAP server for this purpose. In this article I would like to show you how to set up a LDAP connection in Koha, so that all users can log in to the library system with their internal school login.

Configure Koha LDAP connection

Koha saves its settings in the file koha-conf. xml. This file is located at /etc/koha/sites/library/koha-conf. xml, if the Koha instance is called library. We open this file with an editor of our choice and look for the entry <useldapserver>0</useldapserver>.

The documentation for the Koha LDAP connection is not very detailed. The essential information can be found in the Perl documentation on the Koha LDAP module. On this page you will find an example configuration, which we can mostly use. A few small changes are necessary to make the integration between linuxmuster.net and Koha work fine. First we change <useldapserver>0</useldapserver> to <useldapserver>1</useldapserver> to inform Koha that we want to use an LDAP server for the login. Immediately afterwards we insert the following lines:

A few short hints:

  • <hostname>: Here we have to specify the address of the LDAP server (the linuxmuster. net server). Furthermore, we have to make sure that our Koha server can also reach the LDAP server via the ports (TCP/UDP 636) for LDAPS.
  • <base>: The LDAP path for our user accounts. The domain at the end probably needs to be adjusted.
  • <user>: the bind-user, so that Koha can access the user data.
  • <pass>: The password of the bind user. It is located on the linuxmuster. net server at /etc/ldap/ldap. secret
  • <replicate>: When a user logs in via LDAP, we want him/her to have a Koha account.
  • <update>: We need this option to update users with information from LDAP if a coha account already exists.
  • <auth_by_bind>: To check the logon data we want to use the bind-user.
  • <mapping>: Here we can define which data from the LDAP should overwrite which attribute in Koha. Especially important is userid and password.

Test Koha LDAP connection

To test the LDAP connection, we call the Koha OPAC page and log in with a linuxmuster. net user account. If there are problems loading the website or if you can’t log in, you can check the Koha server at /var/log/koha/library/opac-error. log for the reason.

koha login

If the login was successful, you will see a list of the user’s current borrowings:

koha user

Conclusion

The LDAP connection in Koha is a big win for our users. Previously, with LITERRA it was not possible for individual users to see their current loans. Furthermore, the user data now only have to be maintained in one place and not in different programs. Operation via a web interface is a great benefit for all library staff and simplifies their work. Getting started in Koha may be a bit steeper than other library programs, but the possibilities and flexibility of this open source software are impressive!


Stephan

Stephan

I'm a teacher and IT system administrator in an international school. I love open source software and I used it over a decade in my private and work life. My passion is to solve problems with open source software!

1 Comment

Michael Schwartz · February 12, 2018 at 12:45 am

LDAP authentication is not great for security. If you need any other web tools (like email or RocketChat), you will not have SSO with LDAP. Also… you will not be able to authenticate 2 factor authentication. It would be WAY better to make Koha either an OpenID Connect Relying Party (RP) or a SAML Service Provider (SP). This would involve re-directing the user to the central identity provider (IDP), and then creating a session after receiving a positive response and an identity assertion (a digitally signed XML or JSON object with the identity data, like username, email, phone number etc). The free open source Gluu Server would be a good choice, as it provides both a SAML IDP and OpenID Connect Provider, and it can use the existing backend LDAP data (even the password) as the authoritative source for identity.

Comments are closed.