This page lists all the parameters required for LDAP configuration, and possible scenarios.

Ensure to have the following details before proceeding with the next configuration steps.

LDAP Servers

DPOD needs details about the LDAP servers so it can query the LDAP registry.

LDAP servers IP addresses	The IP addresses of the LDAP servers
LDAP servers ports	e.g. 389 or 3268 if using Global Catalog in AD
LDAPS host name verification	Whether to verify host name against the certificate in case of using LDAPS (Secure LDAP over SSL/TLS)
Referrals	Whether LDAP referrals should be followed or ignored (usually ignored for better performance)
Query user distinguished name (DN) and its password	A user that is used to connect to the LDAP server and perform queries. e.g. cn=LDAP Query User,ou=people,dc=example,dc=org

LDAP Users

To be able to authenticate users, DPOD needs to know what LDAP queries it needs to perform in order to verify usernames and passwords.

You might find it useful to examine a user entry within the LDAP registry using an LDAP browsing software compatible with your LDAP registry.

User search base entry	The location in the LDAP tree where user entries should be searched for. Specific locations have better performance than global ones. e.g. ou=people,dc=example,dc=org
User search filter	The LDAP filter (using LDAP filter syntax) to use in order to find a user entry, based on the user name entered in the login page. Usually the user search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the login user name. User entries can usually be identified by an "objectClass" of "person", "organizationalPerson" or "inetOrgPerson". The user entry attribute that contains the login user name is usually "uid", "sAMAccountName" or "cn". Use {0} as a placeholder for the user name entered in the login page. e.g. (&(objectClass=person)(sAMAccountName={0}))
User name attribute	The attribute name of the user entry that contains the name of that user (as entered in the login page). This is usually the same attribute that is used in the user search filter described above. Common attributes are "uid", "sAMAccountName" or "cn".
A user and its password for testing	A real user defined in the LDAP registry who will be using DPOD - will be used to verify that the configuration is valid.

LDAP Groups

To be able to assign roles to users, DPOD needs to know what LDAP queries it needs to perform in order to fetch the list of groups a user belongs to.

You might find it useful to examine a group entry within the LDAP registry using an LDAP browsing software compatible with your LDAP registry.

Group search base entry	The location in the LDAP tree where group entries should be searched for. Specific locations have better performance than global ones. e.g. ou=groups,dc=example,dc=org
Group membership search filter	The LDAP filter (using LDAP filter syntax) to use in order to fetch the list of groups a user belongs to once a user has authenticated successfully, based on the user entry's DN. Usually the group membership search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the authenticated user's DN. Group entries can usually be identified by an "objectClass" of "group" or "groupOfUniqueNames". The group entry attribute that contains its members is usually "member" or "uniquemember". Use {0} as a placeholder for the full DN of the member user or the member group (in case of nested search). e.g. (&(objectClass=groupOfUniqueNames)(uniqueMember={0}))
Group membership search nested	Whether to search for nested group membership (groups within groups). Usually set to "true".
Group name search filter	The LDAP filter (using LDAP filter syntax) to use in order to find a group entry, based on its name. Usually the group name search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the group name. Group entries can usually be identified by an "objectClass" of "group" or "groupOfUniqueNames". The group entry attribute that contains the group name is usually "cn". Use {0} as a placeholder for the group name. e.g. (&(objectClass=groupOfUniqueNames)(cn={0}))
Group name attribute	The attribute name of the group entry that contains the name of that group. This is usually the same attribute that is used in the group name search filter described above. The most common attribute is "cn".

Mapping Built-in Roles

To be able to assign built-in roles to users, DPOD needs to map values from LDAP entries (users or groups) to its built-in roles.

OpDashAdminRole mapping	The value of an attribute of LDAP entries that provide Admin access to users or groups. This is usually the name of the group of admins. e.g. MyDpodAdminsGroup
OpDashPowerUserRole mapping	The value of an attribute of LDAP entries that provide Power User access to users or groups. This is usually the name of the group of power users. e.g. MyDpodPowerUserGroup
OpDashOperatorRole mapping	The value of an attribute of LDAP entries that provide Operator access to users or groups. This is usually the name of the group of operators. e.g. MyDpodOperatorsGroup
OpDashInvestigatorRole mapping	The value of an attribute of LDAP entries that provide Investigator access to users or groups. This is usually the name of the group of investigators. e.g. MyDpodInvestigatorGroup
OpDashAppAdminRole mapping	The value of an attribute of LDAP entries that provide App Admin access to users or groups. This is usually the name of the group of DPOD installation admins. e.g. MyDpodAppAdminsGroup

Custom Roles

Custom roles are based on LDAP user names and LDAP group names, and are defined by the administrator using DPOD's Web Console.

There is no additional configuration required to enable custom roles in the Web console once LDAP is enabled.

Recommended Configuration

The LDAP administrator creates 5 groups within the LDAP registry - one for each built-in role - based on the organization's naming conventions and standards.
Users and other groups are added to the newly created groups according to the desired roles.
Map built-in roles using the names of the newly created groups (see "Mapping Built-in Roles" above).
Make sure to use "cn" as the group role attribute name and "group_attribute" as the built-in role method (see LDAP Configuration Script).

Advanced Configuration

Use the advanced configuration only if the recommended one described above does not fit your needs.

DPOD allows for advanced configuration to provide the most flexible integration with LDAP registry.

Scenario A - Define the Built-in Role Name as an Attribute of the User Entry

In this scenario, the LDAP administrator defines an attribute in each user entry (e.g. DPODRole attribute) which defines that user's built-in role name.

The attribute must be defined in the user class LDAP schema, which means that this schema might need to be extended.
This attribute should have different values - one value for each DPOD built-in role.
Map built-in roles according to those values (see "Mapping Built-in Roles" above).
Make sure to use this attribute as the user role attribute name and "user_attribute" as the built-in role method (see LDAP Configuration Script).

Scenario B - Define the Built-in Role Name as an Attribute of the Group Entry

In this scenario, the LDAP administrator defines an attribute in each group entry (e.g. DPODRole attribute) which defines the built-in role name of users/groups that belong to that group.

The attribute must be defined in the group class LDAP schema, which means that this schema might need to be extended.
This attribute should have different values - one value for each DPOD built-in role.
The LDAP administrator creates 5 groups within the LDAP registry - one for each built-in role. Each group should have a different value - one value for each DPOD built-in role.
Map built-in roles using the names of the newly created groups (see "Mapping Built-in Roles" above).
Make sure to use this attribute as the group role attribute name and "group_attribute" as the built-in role method (see LDAP Configuration Script).

Browser not supported