The database backend uses a LDAP service to store information and passwords for users.
In the administration page, go to Parameters/Users data sources
and add a new user module by clicking on the +
button. In the modal, enter a name and a display name (the name must be unique among all user backend instances).
Select the type LDAP backend user module
in the Type drop-down button.
Below is the definition of all parameters.
Name (identifier) of the module instance, must be unique among all the user backend module instances, even of a different type.
Name of the instance displayed to the user.
Check this option if you want to use this backend as read-only. All user properties such as e-mail, name, password, scopes can't be modifier with Glewlwyd, even administrators.
Check this option if you allow users to manage multiple passwords. More information about multiple passwords use-cases are avaiable in the Getting Started Dcumentation.
URI to connect to the LDAP service, ex: ldaps://ldap.example.com/
DN used to access the LDAP service. The DN must have write access if you want to use this backend in write mode.
Password to use with the Connection DN
.
Page size to list users in this backend. This option must be lower than the maximum of results that the LDAP service can send.
Base DN to look for users.
Search scope on the LDAP Base DN. Values available are one
, subtree
, children
.
Filter to apply when performing a search of users.
Username of the user. This property will be used to build the search filter on a user connection.
You can specify multiple values by separating them with a comma ,
. On read mode, the first value will be used, on write mode, all values will be used.
Name of the user.
You can specify multiple values by separating them with a comma ,
. On read mode, the first value will be used, on write mode, all values will be used.
Scopes available for the user. The LDAP property must store multiple values.
You can specify multiple values by separating them with a comma ,
. On read mode, the first value will be used, on write mode, all values will be used.
Property used to store the user e-mail value.
You can specify multiple values by separating them with a comma ,
. On read mode, the first value will be used, on write mode, all values will be used.
Property used to store the user password. This property is not used if the instance is in read-only mode.
You can specify multiple values by separating them with a comma ,
. On read mode, the first value will be used, on write mode, all values will be used.
Algorithm used to hash the user password. This property is not used if the instance is in read-only mode.
This property is mandatory to store the rdn property. This property is not used if the instance is in read-only mode.
You can specify multiple values by separating them with a comma ,
.
This value will contain all the object class values when Glewlwyd will create new users in the LDAP backend. Values must be separated with a comma ,
.
This section allows to specify new properties for the user. The properties may be available for schemes, plugins, in the admin page or in the profile page.
Property name, ex: phone
, address
, human
, etc.
Corresponding LDAP property name.
If this option is checked, the property values will be available as an array of string values, otherwise a single string value.
If this option is set to base64
, the property content will be converted to base64 for Glewlwyd. On the other hand, if this property is writable by Glewlwyd, the data must be in base64.
If this option is checked, plugins, schemes and administrators can have access to this property in read mode.
If this option is checked, plugins, schemes and administrators can have access to this property in write mode.
If this option is checked, the user can have access to this property in read mode in its profile API.
If this option is checked, the user can have access to this property in write mode in its profile API.
This section allows to specify a correspondence between a Glewlwyd scope and a value in the scope property. The main goal is to use an existing LDAP service whose users have property that can be related to scopes (group names, etc.). For example, the group name value accounting
will correspond to the scope mail
.
LDAP value that must match.
Name of the scope that will be returned. This value must be an existing scope name.
How the LDAP value must match.