LDAP Configuration
Introduction
Starting with Relution version 5.18.0 it is possible to configure LDAP providers for user, group and class import directly via the Relution Portal. The usual configuration parameters are included here and can be conveniently verified by various functional tests. A restart of the Relution service is no longer necessary with the configuration via the portal and facilitates changes and reconfigurations, since the operational flow does not have to be interrupted. We recommend for the configuration of LDAP synchronization, knowledge in the subject as well as the use of an LDAP browser that can display attributes correctly. For Windows the “Softerra LDAP Browser” and for Linux or MacOS the “Apache Directory Studio” has proven itself. Both tools are free of charge.
Basics
To configure LDAP, go to Settings > LDAP Synchronization.
Here you can set up multiple LDAP providers per organization. Note that the mail addresses of the users in Relution must be unique. Failure to do so may result in errors, preventing some user accounts from being created.
To create a new LDAP provider, click on Add
.
Basic configuration
The mask for configuration is divided into several levels. Here you may not always need all parameters for your case. Some fields already contain examples that suggest the syntax.
LDAP synchronization
Assign a name for your LDAP provider here. Choose a short and meaningful name here.
Server settings.
- LDAP server URLs: Enter the URL of the LDAP server here and confirm it with Enter.
If you are using LDAPs and the server does not have a trusted certificate, the certificate can be stored here in order to classify it as trusted for Relution.
Alternatively, you can trust all certificates.
Check your configuration by clicking on Test network connection
. The connection attempt should be successful before you continue.
Authentication
- Bind DN or username: username with read permissions in LDAP. Ideally, the Distinguished Name (DN) is used here.
- Bind Password: The corresponding password to the user.
Check the entries with the corresponding button here as well.
Base DN
If the authentication worked, the Base-DN of the server is determined automatically. It can be entered directly in the corresponding field by clicking on Use determined base DN as base DN
. Any necessary changes can be made at any time.
Users
Search criteria for users
- Search base for users (OU): Enter the search base for users here. This is relative to the base DN.
For example:OU=users
. - Search filter for users: Conventional LDAP search filters are used here. Note that Relution always uses the placeholder
%v
for user input. For example, a simple search filter for users could be:(&(cn=%v)(objectClass=person))
. - Search range for users Here you can configure how deep in the path to search for user accounts with the corresponding search filter. Note that selecting
sublevel
may result in a lot of hits.
Manual mapping for users
Relution checks which LDAP it is after the connection is established. For example openLDAP or an Active Directory. Then the appropriate fields are pre-configured via an auto-mapping. This function can be partially or completely overridden by activating a manual mapping.
For example, setting a foreign key is recommended. This can be useful when users change their name. The user account can still be identified this way and the name and mail address will just be updated without creating a new account in Relution.
User synchronization.
Check if the users can be imported and the filters return the correct results by clicking on the corresponding button.
You also have the option to enable
Periodic user import
. This is an automatic synchronization that runs automatically every 24 hours at the selected time.A manual LDAP sync can be started at any time via the Relution Portal.
Synthetic group: this is a group that is automatically created by the LDAP sync. All users coming from the corresponding LDAP provider are stored here.
If a synchronized user has been removed in LDAP, there are three reaction options available to Relution:
- do nothing: The user remains included in Relution. However, it can no longer be used for login because the LDAP provider refuses authentication.
- disable users in Relution: This is the recommended setting as user accounts remain associated with devices and there is no loss of data if the accounts are accidentally not found anymore. For example, by renaming a group in LDAP, which now cannot be found by a filter.
- delete users from Relution: Caution is required here. Users that are no longer found by the importer are removed directly from the database, regardless of any links to devices, groups or classes.
Groups
Search criteria for groups
- Search base for groups (OU): Enter the search base for the groups here. This is relative to the base DN.
For example:OU=groups
. - Search filter for users: Conventional LDAP search filters are used here. Note that Relution always uses the placeholder
%v
for user entries. For example, a simple search filter for groups could be:(&(cn=%v)(objectClass=groupOfNames))
. - Search range for groups: Here you can configure how deep in the path to search for groups with the corresponding search filter. Note that selecting
sublevel
may result in a lot of hits.
Manual mapping for groups
The manual mapping behaves for groups as it does for users.
Often the entryUUID
field is used for the foreign key (UID)
and the member
field for member
. Check the attributes with one of the LDAP tools recommended above or via the console with ldapsearch
.
Group synchronization
Here you can specify the synchronization time when groups should be updated. This task runs every 24 hours and can be started manually at any time via the Relution Portal.
Education
LDAP synchronization can also be used to create classes that are displayed in the Education
section of the menu and can be used for the Relution Teacher Console or in Apple Classroom.
Classes to be created in Relution are group objects in LDAP. They must contain both teachers and students.
Search criteria for classes
The configuration here is similar to that for users and groups. Define a search base that contains the classes and a corresponding search filter. Likewise, the search range is configured as usual via the corresponding drop-down menu.
Test your configuration via the corresponding button and note that classes will only be created later if both teachers and students are in them.
Search criteria for teachers and students
Here the configuration also consists of the search base and a corresponding filter. Often the individual user types are defined by group memberships. Search filters can look like this, for example:
- Teachers:
(&(memberOf=CN=all-teachers,OU=groups,DC=school,DC=local)(objectClass=person))
- Students:
(&(memberOf=CN=all-students,OU=groups,DC=school,DC=local)(objectClass=person))
Always check your filters for functionality.
Synchronization of education data
Configure here again the appropriate automatic import of the data.