IBM DataPower Operations Dashboard v1.0.10.0
A newer version of this product documentation is available.
You are viewing an older version. View latest at IBM DPOD Documentation.
Planning LDAP Configuration
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. |
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. |
User name attribute | The attribute name of the user entry that contains the name of that user (as entered in the login page). |
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. |
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. |
Group name attribute | The attribute name of the group entry that contains the name of that group. |
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).