LDAP configuration requires many parameters. This page lists all the required parameters and possible scenarios.
LDAP Server
DPOD needs details about the LDAP server so it can query the LDAP user registry.
Ensure to have the following details before proceeding with the next configuration steps:
| LDAP server(s) IP address(es) | Up to 2 IP addresses may be configured - a primary IP address and an alternate one |
| LDAP server port(s) | e.g. 389 or 3268 if using Global Catalog in AD |
| 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 can perform queries. |
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.
The best way to figure this out is to examine user entries within the LDAP server using an LDAP browsing software compatible with your LDAP server.
Ensure to have the following details before proceeding with the next configuration steps:
| User base entry | The location of user entries in the LDAP tree. Specific locations have better performance than global ones. e.g. "ou=people,dc=example,dc=org" |
| User query sub-tree | Whether user entries should be queried in the entire sub-tree of the user base entry (usually true). |
| User search filter | The search filter to use in order to find a user entry based on the login username. 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 username. User entries can normally be identified by an "objectClass" of "person", "organizationalPerson" or "inetOrgPerson". The user entry attribute that contains the login username is usually "uid", "sAMAccountName" or "cn". e.g. "(&(objectClass=person)(sAMAccountName={0}))" |
| A user and its password for testing | A real user defined in the LDAP user 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.
The best way to figure this out is to examine group entries within the LDAP server using an LDAP browsing software compatible with your LDAP server.
Ensure to have the following details before proceeding with the next configuration steps:
| Group base entry | The location of group entries in the LDAP tree. Specific locations have better performance than global ones. e.g. "ou=groups,dc=example,dc=org" |
| Role query sub-tree | Whether group entries should be queried in the entire sub-tree of the group base entry (usually true). |
| Nested groups | Whether group entries can be nested within each other (usually true). |
| Group search filter | The search filter to use in order to fetch the list of groups a user belongs to once a user has authenticated successfully. Usually the group search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the authenticated user. Group entries can normally be identified by an "objectClass" of "group" or "groupOfUniqueNames". The group entry attribute that contains its members is usually "member" or "uniquemember". e.g. "(&(objectClass=groupOfUniqueNames)(uniqueMember={1}))" |
| Group name attribute name | The attribute name at the group entry that contains the group name. |
Built-in Roles
For security reasons, authenticated users are assigned built-in roles based on LDAP queries only.
This means, for example, that a user may be granted with Administrator privileges only if it is configured that way in the LDAP user repository.
In order to assign built-in roles to users, DPOD needs to associate a user or a group with its built-in roles using an LDAP entry attribute. There are 2 possible scenarios:
- Scenario A - Define the built-in role name as an attribute of the user entry
- Scenario B - Define the built-in role name as an attribute of the group entry
The most common scenario is Scenario B, where the group's name (cn) is used as the built-in role name attribute.
This scenario does not require extending any schemas - only creating groups with pre-defined names. See below for more details.
Scenario A - Define the Built-in Role Name as an Attributes of the User Entry
In this scenario, the LDAP administrator defines an attribute for the user entry (e.g. DPOD_Role attribute) which contains the built-in role name of that user.
- The attribute must be defined in the user class LDAP schema, which means that this schema might need to be extended.
- Add the attribute with one of the built-in role names (e.g. OpDashAdminRole) to each user that should use DPOD's Web Console.
For example, an administrator user named "john" (cn=john) should have the attribute "DPOD_Role=OpDashAdminRole".
If you choose this scenario, ensure to have the following details before proceeding with the next configuration steps:
| User entry attribute name | The attribute name of the user entry that contains the built-in role name of that user. |
Scenario B - Define the Built-in Role Name as an Attribute of the Group Entry
In this scenario, the LDAP administrator defines an attribute at the group entry that contains the built-in role name of users 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.
Usually, the built-in role name is stored as the group name (cn), thus avoiding the need to extend the schema. - Create 4 groups - one for each built-in role. The group names should be identical to the built-in role names if the chosen attribute is the group name (cn).
- Add users to the groups.
For example, an administrator user named "john" (cn=john) should belong to a group named "OpDashAdminRole" (cn=OpDashAdminRole).
If you choose this scenario, ensure to have the following details before proceeding with the next configuration steps:
| Group entry attribute name | The attribute name of the group entry that contains the built-in role name of users that belong to that group. e.g. "cn" |