How to connect Koha to LDAP / Active Directory

Published by Stephan on

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.

Connect Koha to Active Directory / AD (linuxmuster.net v7)

Linuxmuster.net v7 comes with a Samba 4 Active Directory. This has also changed the connection to Koha compared to the previous version. The settings are still in /etc/koha/sites/library/koha-conf.xml (if the Koha instance is called library). We need to edit this file as follows:

A few short hints:

  • <hostname>: Here we have to enter the address of the LDAP server (the linuxmuster.net v7 server). We also need to make sure that our Koha server can reach the LDAP server through the ports (TCP/UDP 636) for LDAPS.
  • <base>: The LDAP path for our user accounts. The domain at the end will probably need to be adjusted.
  • <user>: the bind-user, so that Koha can access the user data in AD.
  • <pass>: The password of the Bind-User. It can be found on the linuxmuster.net server at /etc/linuxmuster/.secret/global-binduser
  • <replicate>: If a user logs in via LDAP, we want him to get a Koha account as well.
  • <update>: We need this option to update users with information from LDAP if a Koha account already exists.
  • <auth_by_bind>: We want to use the bind user for the logon credentials check. For Active Directory, this option must be 1.
  • <principal_name>: This is probably the most difficult part. The most suitable is the userPrincipalName from AD. For linuxmuster.net v7 it is set to [email protected] (adjust domain again!). User is replaced here by %s (which again is determined by the mapping below).
  • <mapping>: Here we can define which data from LDAP / AD should overwrite which attribute in Koha. Most importantly, userid is important, as this is used to replace the %s in <principal_name>. With Samba 4 / AD the mapping looks like this: <userid is=”samAccountName”></userid>

Configure Koha LDAP connection (linuxmuster.net v6.2)

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

Test Koha LDAP / AD connection via command line

Especially when setting up the connection to the LDAP / AD server it is faster if you can test directly on the command line if the configuration is correct. To do this, enter the following commands:

Make sure to adapt the path to the koha-conf.xml, as well as user and password.

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

Avatar

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.

Leave a Reply

Your email address will not be published.