LDAP Configuration


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.


To configure LDAP, go to Settings > LDAP Synchronization. Here, multiple LDAP providers can be set up per organization. It has to be noted 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, Add has to be clicked.

Basic configuration

The mask for configuration is divided into several levels. Here, one may not always need all parameters for the case. Some fields already contain examples that suggest the syntax.

LDAP synchronization

A name for your LDAP provider has to be assigned here. A meaningful name has to be chosen here.

Server settings

  • LDAP server URLs: The URL of the LDAP server has to be entered here and confirmed with Enter.

If LDAPs are used 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, one can trust all certificates.

The configuration has to be checked by clicking on Test network connection. The connection attempt should be successful before continuing.

Test network connection


  • 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.

The entries with the corresponding button has to be checked 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.


Search criteria for users

  • Searching base for users (OU): Entering the search base for users here. This is relative to the base DN.
    For example: OU=users.
  • Searching filter for users: Conventional LDAP search filters are used here. It has to be noted that Relution always uses the placeholder %v for user input. For example, a simple search filter for users could be: (&(cn=%v)(objectClass=person)).
  • Searching range for users: Here, it is possible to configure how deep in one shopuld go in the path to search for user accounts with the corresponding search filter. Note that selecting sublevel may result in a lot of hits.

User configuration

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

It should be checked, if the users can be imported and the filters return the correct results by clicking on the corresponding button.

  • There is also 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:

    1. Doing nothing: The user remains included in Relution. However, it can no longer be used for login because the LDAP provider refuses authentication.
    2. Disabling 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.
    3. Deleting 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.


Search criteria for groups

  • Searching base for groups (OU): Enter the search base for the groups here. This is relative to the base DN.
    For example: OU=groups.
  • Searching filter for users: Conventional LDAP search filters are used here. It should be noted 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, one can configure how deep in the path to search for groups with the corresponding search filter. It should be noted that selecting sublevel may result in a lot of hits.

Group configuration

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. Checking the attributes with one of the LDAP tools recommended above or via the console with ldapsearch.

Group synchronization

Here, one 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.


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. A search base that contains the classes and a corresponding search filter has to be defined. Likewise, the search range is configured as usual via the corresponding drop-down menu.

The configuration via the corresponding button has to be tested and it has to be noted 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))

The filters of functionality have to be checked always.

Synchronization of education data

Configure here again the appropriate automatic import of the data.

Group configuration

Store Organization Mapping

In the Store Organization it is possible to configure global LDAP providers and synchronize users, groups and classes in organizations with individual mappings. Since Relution Server 5.21, only content that is also configured in a mapping and can be found using the corresponding filters is synchronized there.