...
Please make sure you have the following details:
| 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) |
| A user distinguished name (DN) and its password |
...
Used to connect to the LDAP server and can perform queries |
...
. |
...
LDAP Users
In order to authenticate users, DPOD needs to know what LDAP queries to perform in order to verify usernames and passwords.
...
Please make sure you have the following details:
| 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 |
...
| " | |
| Query sub-tree | Whether user entries should be queried in the entire sub-tree of the user base entry (usually true). |
| User search query |
...
| The query to perform in order to find a user entry based on the login username. Usually the user search query combines 2 conditions: First filter the entries based on "objectClass" attribute and then filter the entries based on the login username. Usually user entries may 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 username and its password |
...
| 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
In order to assign roles to users, DPOD needs to know what LDAP queries to perform in order to fetch the list of groups a user belongs to.
...
Please make sure you have the following details:
| 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 |
...
| " | |
| 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 in each |
...
| other (usually true). |
| Group search query |
...
| The query to perform in order to fetch the list of groups a user belongs to once a user has authenticated successfully. Usually the group search query combines 2 conditions: First filter the entries based on "objectClass" attribute and then filter the entries based on the authenticated user. Usually group entries may 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}))" |
Built-in Roles
For security reasons, authenticated users are assigned with 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 attributes on the user
...
- entry
- Scenario B - Define the built-in role name as an attributes on the group entry
| Note |
|---|
The most common scenario is Scenario B, where the group's name (cn) is used as the built-in role name attribute. |
Scenario A - Define the Built-in Role Name as an Attributes on the User Entry
In this scenario, the LDAP administrator defines an attribute , (for example DPOD_roleRole attribute, ) at the user directory entry level that contains the built-in role name of that user.
Multiple roles are assigned using several instances of the attribute in the user entry.
The attribute must be defined in the user class LDAP schema.
Example 1:
An , which means that this schema might need to be extended.
For example, an administrator user named "john" (CNcn=john) has the attribute "DPOD_roleRole=OpDashAdminRole".
If you choose this scenario, please make sure you have the following details:
| User entry attribute name | The attribute name at the user entry that contains the built-in role name of that user. e.g. "DPOD_Role" |
Scenario B - Define
...
the Built-in Role Name as an Attribute on the Group Entry
In this scenario, the LDAP administrator defines an attribute at the group directory entry level that contains the built-in role name of users that group. The roles of a user are fetched by searching for all groups of a user and accumulating the values of the attribute from each group entry.
Multiple roles are assigned by adding the user to several groups that have that attribute defined. The attribute should belong to that group.
The attribute must be defined in the group class LDAP schema, which means that this schema .
Example 2: (group CN equals to role name):
An 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.
For example, an administrator user named "john" (CNcn=john) belongs to a group named "OpDashAdminRole" (CNcn=OpDashAdminRole)
Example 3 (custom attribute):
An administrator user named "john" (CN=john) belongs to a group named "DPAdmins" that has the attribute "DPOD_role=OpDashAdminRole"..
If you choose this scenario, please make sure you have the following details:
| Group entry attribute name | The attribute name at the group entry that contains the built-in role name of users that belong to that group. e.g. "cn" |
Step 1- choose your preferred scenario:
...
- If necessary, add an attribute to the group class LDAP schema (e.g. DPOD_role attribute).
- Create 4 groups - one for each built-in role. The group names do not have to be identical to the built-in role names.
- For each group, if required, add the attribute with one of the following values:
- OpDashAdminRole
- OpDashPowerUserRole
- OpDashOperatorRole
- OpDashInvestigatorRole
| Note |
|---|
If the groups CN cn is the same as the built-in role names, no additional attribute is required. |
...