...
DPOD needs details about the LDAP server so it can query the LDAP user registry.
Please make sure you Ensure to have the following details for before proceeding with the next configuration steps of configuration:
| 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
In order 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 discover it figure this out is to have a look at a user entry examine user entries within the LDAP server using an LDAP browsing software compatible with your LDAP server.
Please make sure you Ensure to have the following details for details before proceeding with the next configuration steps of configuration:
| 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 queryfilter | The query search filter to perform use in order to find a user entry based on the login username. Usually the user search query filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the login username. Usually user User entries may 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
In order 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 discover it is to have a look at a group entry figure this out is to examine group entries within the LDAP server using an LDAP browsing software compatible with your LDAP server.
Please make sure you Ensure to have the following details for details before proceeding with the next configuration steps of configuration:
| 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 in within each other (usually true). |
| Group search queryfilter | The query search filter to perform use in order to fetch the list of groups a user belongs to once a user has authenticated successfully. Usually the group search query filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the authenticated user. Usually group Group entries may 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 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.
...
- Scenario A - Define the built-in role name as an attributes on attribute of the user entry
- Scenario B - Define the built-in role name as an attributes on attribute of 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
...
of the User Entry
In this scenario, the LDAP administrator defines an attribute (for example for the user entry (e.g. DPOD_Role attribute) at the user entry that 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.
- For each user that should use DPOD's Web Console, add Add the attribute with one of the built-in role names (e.g. OpDashAdminRole) 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, please make sure you ensure to have the following details for details before proceeding with the next configuration steps of configuration:
| User entry attribute name | The attribute name at 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.
...
If you choose this scenario, please make sure you ensure to have the following details for details before proceeding with the next configuration steps of configuration:
| Group entry attribute name | The attribute name at of the group entry that contains the built-in role name of users that belong to that group. e.g. "cn" |