IBM© DataPower Operations Dashboard v1.0.5.0

A newer version of this product documentation is available.

You are viewing an older version. View latest at IBM DPOD Documentation.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

LDAP Server

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

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)
  • Whether LDAP referrals should be followed or ignored (usually ignored for better performance)
  • A user distinguished name (DN) and its password which is used to connect to the LDAP server and can perform queries (e.g. "cn=LDAP Query User,ou=people,dc=example,dc=org")

LDAP Users

In order to authenticate users, DPOD needs to know what LDAP queries to perform in order to verify usernames and passwords.

The best way to discover it is to have a look at a user entry within the LDAP server using an LDAP browsing software compatible with your LDAP server.

Please make sure you have the following details:

  • User base entry - the location of user entries in the LDAP tree (e.g. ou=people,dc=example,dc=org). Specific locations have better performance than global ones.
  • 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".
    An example of a user search query: (&(objectClass=person)(sAMAccountName={0}))


Scenario A - Define Roles as attributes on the user directory entry

With this method, the LDAP administrator defines an attribute, for example DPOD_role attribute, at the user directory entry level that contains the 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 administrator user named "john" (CN=john) has the attribute "DPOD_role=OpDashAdminRole".

Scenario B - Define Roles as attributes on the group directory entry

With this method, the LDAP administrator defines an attribute at the group directory entry level that contains the role name of 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 be defined in the group class LDAP schema.

Example 2: (group CN equals to role name):

An administrator user named "john" (CN=john) belongs to a group named "OpDashAdminRole" (CN=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".


Step 1- choose your preferred scenario:

Scenario A - an attribute at the user directory entry

When your installation scenario matches Scenario A in the Concepts Section, perform the following steps:

  1. If necessary, add an attribute to the user class LDAP schema (e.g. DPOD_role attribute).
  2. For each user that should use DPOD's Console, add the attribute with one of the built-in role names:
    1. OpDashAdminRole
    2. OpDashPowerUserRole 
    3. OpDashOperatorRole
    4. OpDashInvestigatorRole

Scenario B - an attribute at the group directory entry

When your installation scenario matches Scenario B in the Concepts Section, perform the following steps:

  1. If necessary, add an attribute to the group class LDAP schema (e.g. DPOD_role attribute).
  2. Create 4 groups - one for each built-in role. The group names do not have to be identical to the built-in role names.
  3. For each group, if required, add the attribute with one of the following values:
    1. OpDashAdminRole
    2. OpDashPowerUserRole 
    3. OpDashOperatorRole
    4. OpDashInvestigatorRole

 

If the groups CN is the same as the built-in role names, no additional attribute is required.


  • No labels