LDAP Authentication

LDAP and User Roles

It is recommended that certain user rights are removed when using LDAP for login. The user should not be allowed to change their password or their email address. It is also suggested that the user not be allowed to edit their profile, however I have found certain fields that I would like the user to edit. To set the rights edit the file :

LDAP Testing

Below is test script to check whether you can connect to the LDAP server and get attributes back for a particular user. This should generall be saved in /opt/eprints3/archives/ARCHIVE/bin/ldaplookup It can be called as follows:

LDAP Authentication with Bulk Import of Users

This recipe enables authenticating passwords against an LDAP directory for all users (including administrators). The users will need to already exist in EPrints, most likely created by a bulk import from your LDAP server.

The recommendation for EPrints is not to allow users to alter email and passwords, as these changes are not at present written back to the LDAP database.

LDAP Configuration

Both the scripts for LDAP user login and import/update of users from LDAP require a number of parameters these are best saved in the archive's cfg/cfg.d/ldap.pl file.

LDAP Authentication

All changes for LDAP authentication can be made in a single file, the file contains useful notes on configuration. Here is an example from my site, I have configured a standard Samba Domain using LDAP for authentication, if you have similar then this config may work for you :

Things to note

These scripts use a dedicated proxy account which must exist in your LDAP tree and has appropriate permissions (ACL settings) to search for users and read their uid,givenname,sn,mail attributes.

It gets this proxy accounts' password from a file inside the repository configuration. this file needs to have read permissions for the user your webserver runs as (e.g. www-data on Debian). Use file system permissions to protect this (e.g. chmod 400 ldap.passwd).

It changes the flow of user_login.pl a little to only check for local admin accounts (no users or editors; we have them all in our LDAP tree) and only when no user is found for ldap authentication. This allows you to have your admins in LDAP (if you want) but still use the local admin for "promoting" other users to admins, among other things (which could also be done with a simple SQL update directly in the RDBMS). If you don't need the local admin, remove those lines and just return 0 since no user was found in LDAP.

you could change the default role for generated user accounts from user, if you really wanted.

Kerberos Authentication on AD with On-Demand Creation of Users using LDAP

Tested on 3.3.8

Here's another example of a customized /opt/eprints3/archives/ARCHIVEID/cfg/cfg.d/user_login.pl:

Possible enhancements

Currently this script does not remove local eprints accounts from the database: when accounts get deleted from the LDAP database the corresponding local EPrints accounts sit around forever. But since login isn't possible anymore this is not a risk or of high priority.

Depending on your situation it may be enough to run some kind of cleanup script, e.g. once a year, that get's a list of all local EPrints accounts, loops over them and $user->removes all those, which cannot be found in LDAP anymore (except for those where $user_type eq 'admin', so you don't risk losing your local admins).