Versions Compared

Old Version 22

changes.mady.by.user Assaf Cohen (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Amit Munwes

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page lists all the parameters required for LDAP configuration, and possible scenarios.

Info

...

Ensure to have the following details before proceeding with the next configuration steps.

LDAP Servers

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

Ensure to have the following details before proceeding with the next configuration steps:

LDAP server IP addressLDAP servers IP addressesThe IP address addresses of the LDAP serverservers
LDAP server portservers portse.g. 389 or 3268 if using Global Catalog in AD
LDAPS host name verificationWhether to verify host name against the certificate in case of using LDAPS (Secure LDAP over SSL/TLS)
ReferralsWhether 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.
e.g. cn=LDAP Query User,ou=people,dc=example,dc=org

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 You might find it useful to examine a user entries entry within the LDAP server registry using an LDAP browsing software compatible with your LDAP serverregistry.

Ensure to have the following details before proceeding with the next configuration steps:

User search base entryThe 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 sub-treeWhether user entries should be queried in the entire sub-tree of the user search base entry (usually true).User search filter

The

search filter

LDAP filter (using LDAP filter syntax) to use in order to find a user entry, based on the

login

user name

, using standard LDAP search filter syntax

entered in the login page.
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 user name.
User entries can

normally

usually be identified by an "objectClass" of "person", "organizationalPerson" or "inetOrgPerson".
The user entry attribute that contains the login user name is usually "uid", "sAMAccountName" or "cn".
Use {0} as a placeholder for the user name entered in the login page.
e.g. (&(objectClass=person)(sAMAccountName={0}))

User name attribute

The attribute name of the user entry that contains the name of that user (as entered in the login page).
This is usually the same attribute that is used in the user search filter described above.
Common attributes are "uid", "sAMAccountName" or "cn".

A user and its password for testingA 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 You might find it useful to examine a group entry within the LDAP server registry using an LDAP browsing software compatible with your LDAP server.Ensure to have the following details before proceeding with the next configuration steps:registry.

search sub-tree role attribute nameThe attribute name at the group entry that contains the role name (usually cn)
Group search base entryThe 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 Whether group entries should be queried in the entire sub-tree of the group search base entry (usually true).
Group search nestedWhether group entries can be nested within each other (usually true).
Group search filterThe search filter to use in 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,

using standard LDAP search filter syntax

based on the user entry's DN.
Usually the group membership search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the authenticated user's DN.
Group entries

can normally

can usually be identified by an "objectClass" of "group" or "groupOfUniqueNames".
The group entry attribute that contains its members is usually "member" or "uniquemember".
Use {0} as a placeholder for the full DN of the member user or the member group (in case of nested search).
e.g. (&(objectClass=groupOfUniqueNames)(uniqueMember={

1

0}))

Group membership search nestedWhether 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.
Usually the group name search filter combines 2 conditions: First filter the entries based on the "objectClass" attribute and then filter the entries based on the group name.
Group entries can usually be identified by an "objectClass" of "group" or "groupOfUniqueNames".
The group entry attribute that contains the group name is usually "cn".
Use {0} as a placeholder for the group name.
e.g. (&(objectClass=groupOfUniqueNames)(cn

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.

...

={0}))

Group name attribute

The attribute name of the group entry that contains the name of that group.
This is usually the same attribute that is used in the group name search filter described above.
The most common attribute is "cn".

Mapping Built-in Roles

To be able to assign built-in roles to users, DPOD needs to associate a user or a group with map values from LDAP entries (users or groups) to 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

...

.

OpDashAdminRole mappingThe 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 mappingThe 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 mappingThe 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 mappingThe 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 mappingThe 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

Info

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 for the in each user entry (e.g. DPODRole attribute) which contains the defines that user's 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 This attribute should have different values - one value for each DPOD 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 "DPODRole=OpDashAdminRole".

If you choose this scenario, ensure to have the following details before proceeding with the next configuration steps:

...

  • .
  • 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 at the group entry that contains 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.Usually, the
  • This attribute should have different values - one value for each DPOD built-in role name is stored as the group name (cn), thus avoiding the need to extend the schema.Create 4 groups .
  • The LDAP administrator creates 5 groups within the LDAP registry - one for each built-in role. The Each group names should be identical to the should have a different value - one value for each DPOD 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.
  • 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).