EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

KB17701: Visual representation and conflict resolution of LDAP user group membership in the MicroStrategy Intelligence Server


Community Admin

• Strategy


When standard authentication is used against a Strategy Intelligence Server 9.x installation, users' group memberships are simple to handle because there is only one source for group membership information: the Strategy Metadata. The Strategy user and group editors accurately reflect the user and group relationships that exist in the metadata.
 
Lightweight Directory Access Protocol (LDAP) integration introduces another source -- the LDAP server -- of user and group membership data. Since there are two user/group repositories, conflicts may arise, in terms of representation in the Strategy interface and application of user privileges within a user session.
 
Visual representation
In the Strategy Intelligence Server, visual representation of user and group relationships follows one simple rule. Only those relationships that exist in the metadata are ever displayed in the user and group editors.
 
The consequences for LDAP integration are as follows:

  • Group memberships defined in the LDAP server are not visible in the Strategy User Editor.
  • Users imported from the LDAP server will belong only to the Strategy user group 'LDAP Users' by default. Only this group membership appears in Strategy.
  • Additional memberships may be added in the User Editor. These memberships are saved in the metadata and always applied to user sessions, whether or not the user is a member of the corresponding group in the LDAP server.

With LDAP integration, the expected usage is that user security will be administered through the LDAP server. Strategy uses the information in the LDAP server, but does not mirror group memberships in the metadata. This way, Strategy can adapt to changes in the user/group structure in the LDAP server automatically.
 
Manually assigning groups in Strategy specifies that the user should be a member of that group every time that user logs in, regardless of the LDAP server's data. A group membership that exists in the metadata, and which is displayed in the User Editor, thus has a different meaning from a group membership declared in the LDAP server alone. Metadata user-group relationships are not automatically removed from the metadata if the user is removed from a group in the LDAP server. They should be considered permanent, where group memberships in the LDAP server may change independently.
 
Application of user privileges to a user session
Every time a user authenticates against a Strategy Intelligence Server 9.x, a set of user privileges is assigned to the user session. The enabled privileges determine what options are available to the user for the duration of that session. The privileges persist until the session ends (either through logout or timeout), and the privileges are reevaluated the next time the user logs in.
 
In LDAP integration, the authentication procedure is as follows:

  1. Verify the user's credentials against the LDAP server; fail if incorrect.
  2. Match the LDAP user's distinguished name (DN) against one and only one user in the Strategy Metadata. (All DNs saved in the metadata must be unique; no two users can have the same DN.)
  3. The user session will inherit all privileges assigned directly to the user, and privileges belonging to any Strategy Metadata group to which the user belongs.
  4. If no corresponding user exists in the Strategy Metadata, privileges from the LDAP Users group applied to normal logins. Guest sessions use the privileges from the LDAP Public group.
  5. Search for LDAP groups to which the user belongs.
  6. Match the DNs against groups in the Strategy Metadata.
  7. Any privileges belonging to those Strategy Metadata groups will be added to the user session.

The user session, then, has the sum total of all the privileges that derive from group memberships in the Strategy Metadata as well as in the LDAP server.
A typical security configuration for LDAP integration includes the following elements:

  • Baseline privileges assigned to the LDAP Users group.
  • Imported or linked groups corresponding to LDAP server groups. More substantial privileges are assigned to these groups, based on the users' expected level of access.
  • Users are generally not assigned manually to Strategy user groups, instead deriving privileges dynamically from LDAP group memberships (steps 3 and 4).
  • If a user needs to be added to or removed from a group, the change is made in the LDAP server. Strategy will detect the change the next time the user logs in and automatically adjust privileges. No permanent changes need be made in the metadata in this case.

Effectively, creating additional group memberships in the Strategy Metadata takes some degree of control away from the LDAP server over the group memberships that apply at login time. It is impossible for the LDAP server to deny privileges that have been manually assigned in the metadata. Manual assignment should be reserved for privileges that users should always have, regardless of the state of the LDAP server.
 
Thus it might be clearer why Strategy does not display LDAP group memberships in the Strategy User Editor.

  • As far as Strategy is concerned, LDAP memberships do not exist except in the context of a user session. Since the information in the user editor is independent of any session, session-specific information cannot be displayed.
  • Editing group memberships in the metadata provides another security option to administrators.

Comment

0 comments

Details

Knowledge Article

Published:

June 1, 2017

Last Updated:

June 1, 2017