Skip to main content

MSTR Defining sets of privileges: Security roles

https://www2.microstrategy.com/producthelp/10.6/SystemAdmin/WebHelp/Lang_1033/Content/Admin/Defining_sets_of_privileges__Security_roles.htm

Defining sets of privileges: Security roles

A security role is a collection of project-level privileges that are assigned to users and groups. For example, you might have two types of users with different functionality needs: the Executive Users who need to run, sort, and print reports, and the Business Analysts who need additional capabilities to drill and change subtotal definitions. In this case, you can create two security roles to suit these two different types of users.
Security roles exist at the project source level, and can be used in any project registered with Intelligence Server. A user can have different security roles in each project. For example, an administrator for the development project may have a Project Administrator security role in that project, but the Normal User security role in all other projects on that server.
A security role is fundamentally different from a user group in the following ways:

A group is a collection of users that can be assigned privileges (or security roles) all at once, for the project source and all projects in it.


A security role is a collection of privileges in a project. Those privileges are assigned as a set to various users or groups, on a project-by-project basis.
For information about how privileges are inherited from security roles and groups, see Controlling access to functionality: Privileges.

Managing security roles

The Security Role Manager lists all the security roles available in a project source. From this manager you can assign or revoke security roles for users in projects, or create or delete security roles. For additional methods of managing security roles, see Other ways of managing security roles.

To assign a security role to users or groups in a project


1In Developer, log in to the project source containing the security role. You must have the Grant/Revoke Privileges privilege.


2Expand Administration, then Configuration Managers, and then select Security Roles. A list of security roles in the project source opens in the main Developer pane.


3Double-click the security role you want to assign to the user or group. The Security Role Editor opens.


4Select the Members tab.


5From the Select a Project drop-down list, select the project for which to assign the security role.


6From the drop-down list of groups, select the group containing a user or group you want to assign the security role to. The users or groups that are members of that group are shown in the list box below the drop-down list.


By default, users are not shown in this list box. To view the users as well as the groups, select the Show users check box.


To assign a top-level group to a security role, from the drop-down list select All Groups.


7Select a desired user or group.


8Click the > icon. The user or group moves to the Selected members list. You can assign multiple users or groups to the security role by selecting them and clicking the > icon.


9When you are finished assigning the security role, click OK. The security role is assigned to the selected users and groups and the Security Role Editor closes.

To create a security role


1In Developer, log in to the project source you want to create the security role in.


2Expand Administration, then Configuration Managers, and then select Security Roles.


3From the File menu, point to New, and select Security Role. The Security Role Editor opens at the General tab.


4Enter a name and description for the new security role.


5Select the Privileges tab.


6Select the privileges to add to this security role. For an explanation of each privilege, see the List of Privileges chapter in the Supplemental Reference for System Administration.
To select all privileges in a privilege group, select the group.

7To assign the role to users, select the Members tab and follow the instructions in To assign a security role to users or groups in a project.


8Click OK to close the Security Role Editor and create the security role.

To delete a security role


1In Developer, log in the project source you want to remove the security role from.


2Expand Administration, then Configuration Managers, and then select Security Roles. A list of security roles in the project source opens in the main Developer pane.


3Click the security role that you want to remove.


4From the File menu select Delete.


5Click Yes to confirm that you want to delete the security role.

Other ways of managing security roles

You can also assign security roles to a user or group in the User Editor or Group Editor. From the Project Access category of the editor, you can specify what security roles that user or group has for each project.
You can assign roles to multiple users and groups in a project through the Project Configuration dialog box. The Project Access - Generalcategory displays which users and groups have which security roles in the project, and allows you to re-assign the security roles.
For detailed instructions on using these editors to manage security roles, see the MicroStrategy Developer Help.
You can also use Command Manager to manage security roles. Command Manager is a script-based administrative tool that helps you perform complex administrative actions quickly. For specific syntax for security role management statements in Command Manager, see Security Role Management in the Command Manager on-line help (from Command Manager, press F1, or select the Help menu). For general information about Command Manager, see Automating Administrative Tasks with Command Manager.
If you are using UNIX, you must use Command Manager to manage your system’s security roles.

Controlling access to a project

You can deny user or group access to a specific MicroStrategy project by using a security role.

To deny user or group access to a project


1In Developer, right-click on the project you want to deny access to. Select Project Configuration. The Project Configuration Editor opens.


2Expand the Project Access category. The Project Access - General dialog box opens.


3In the Select a security role drop-down list, select the security role that contains the user or group who you want to deny project access. For example, select the Normal Users security role.


4On the right-hand side of the Project access - General dialog, select the user or group who you want to deny project access. Then click the left arrow to remove that user or group from the security role. For example, remove the Everyone group.


5Using the right arrow, add any users to the security role for whom you want to grant project access. To see the users contained in each group, highlight the group and check the Show users check box.


6Make sure the user or group whose access you want deny does not appear in the Selected members pane on the right-hand side of the dialog. Then click OK.


7In Developer, under the project source that contains the project you are restricting access to, expand Administration, then expand User Manager.


8Click on the group to which the user belongs who you want to deny project access for. Then double-click on the user in the right-hand side of Developer. The User Editor opens.


9Expand User Definition, then select Project Access.


10In the Security Role Selection row, under the project you want to restrict access to, review the Security Role Selection drop-down list. Make sure that no security role is associated with this project for this user.


11Click OK.
When the user attempts to log in to the project, he receives the message “No projects were returned by this project source.”

The role-based administration model

Beginning with version 9.0, the MicroStrategy product suite comes with a number of predefined security roles for administrators. These roles makes it easy to delegate administrative tasks.
For example, your company security policy may require you to keep the user security administrator for your projects separate from the project resource administrator. Rather than specifying the privileges for each administrator individually, you can assign the Project Security Administrator role to one administrator, and the Project Resource Administrator to another. Because users can have different security roles for each project, you can use the same security role for different users in different projects to further delegate project administration duties.
The predefined project administration roles cover every project-level administrative privilege except for Bypass All Object Security Access Checks. None of the roles have any privileges in common. For a list of the privileges included with each predefined security role, see the List of Privileges chapter in the Supplemental Reference for System Administration.
The predefined administration security roles are:

Power Users, which have the largest subset of privileges of any security role.


Project Bulk Administrators, who can perform administrative functions on multiple objects with Object Manager (see Copying objects between projects: Object Manager), Command Manager (see Automating Administrative Tasks with Command Manager), and the Bulk Repository Translation Tool.


Project Operations Administrators, who can perform maintenance on various aspects of a project.


Project Operations Monitors, who can view the various Intelligence Server monitors but cannot make any changes to the monitored systems.


Project Resource Settings Administrators, who can configure project-level settings.


Project Security Administrators, who create users and manage user and object security.
For instructions on how to assign these security roles to users or groups, see Managing security roles.
Do not modify the privileges for an out-of-the-box security role. During upgrades to newer versions of MicroStrategy, the privileges for the out-of-the-box security roles are overwritten with the default privileges. Instead, you should copy the security role you need to modify and make changes to the copied version.

Comments

  1. Hey there, thanks for providing Solution for this Tableau data integration. I was looking for more information on Tableau Rest API Connection. If you know anything please share. Thanks in advance!

    Tableau Rest Api Connection

    ReplyDelete

Post a Comment

Popular posts from this blog

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

Microstrategy "Error type: Odbc error. Odbc operation attempted

 "Error type: Odbc error. Odbc operation attempted: SQLExecDirect. [HYT00:0: on SQLHANDLE] [MicroStrategy][ODBC Oracle Wire Protocol driver]Timeout expired" is shown when executing reports from Web When users are trying to execute some reports in MicroStrategy web in particular, they may receive the Error “SQL Generation Complete Index out of range” and “Timeout expired” error as shown below: Possible Causes: One possible cause is that the MicroStrategy Intelligence Server using a cached database connection that was already dropped by the RDBMS. To resolve this: Admin should delete the database connection caches and create a new DSNs in case they are sharing DSNs to connect to different databases. In addition, change the settings for the ‘Connection lifetime’ and the ‘Connection idle time out’.  Follow the steps below to perform the mentioned changes and verify the report after each step and some of the settings require i-server r...

Multi-Table Data Import(MTDI) from one or more supported data sources

Multi-Table Data Import(MTDI) from one or more supported data sources In MicroStrategy Analytics Enterprise Web 10 onewards, users can now simultaneously import two or more tables from one or more supported data sources, this feature is called Multi-Table Data Import (MTDI) which has been renamed as Super Cubes in MSTR 2019 (Does it sound like multisourcing for all the users without admin help?) Currently, all connectors in MicroStrategy Web 10 except " OLAP " and " Search Engine Indices " support Multi-Table Data Import. Users are able to add multiple tables/files when doing data import from single connector, as shown below: Users are also able to combine multiple tables/files from different sources and store them into one single Intelligent Cube, as shown below:

Error. Engine Attribute Role Limit Exceeded! To get rid off this error: (1) Turn off Engine Attribute Role setting in VLDB dialog

Error. Engine Attribute Role Limit Exceeded! Some times Microstrategy will give the below error when updating the schema after an attribute is created. MicroStrategy Developer --------------------------- Error(s) occurred while loading schema: [DFCSCHEMA] Population Exception: The object shown in the following hierarchy no longer exists in schema: -Table LKUP_TEST_FEE_SHIPMENTS error. Engine Attribute Role Limit Exceeded! To get rid off this error: (1) Turn off Engine Attribute Role setting in VLDB dialog; OR (2) Use Table Alias featureDSSSQLEngine: Schema loading error: Message from GetErrorInfo : Report cache is not found.. Error(s) occurred while loading schema: 63. CAUSE: This error message means that the table shown in the error text needs to be split into a very large number tables. MicroStrategy has a limitation that only allows one table to be split into no more than 100 tables. The error above is shown when this limitation is surpassed....

"Table structure cannot read or update" in the warehouse catalog error while updating a table structure in Microstrategy

"Table structure cannot read or update"  in the warehouse catalog error while updating a table structure while using Warehouse Catalog in MicroStrategy Developer  This issue could be due to the incorrect prefix.  To fix the issue. 1. Open the Warehouse Catalog. 2. Select the table and assign the correct Prefix update the structure. 3. Save and close the warehouse catalog.

Personalizing file locations, email and file subscriptions using macros in Microstrategy

Personalizing file locations MSTr allows to dynamically specify the  File Location  and  Backup File Location  in a file device using macros.  For example, if you specify the  File Location  as  C:\Reports\{&RecipientName}\ ,  all subscriptions using that file device are delivered to subfolders of  C:\Reports\ . Subscribed reports or documents for each recipient are delivered to a subfolder with that recipient’s name, such as  C:\Reports\Jane Smith\  or  C:\Reports\Hiro Protagonist\ . The table below lists the macros that can be used in the  File Location  and  Backup File Location  fields in a file device: Description Macro Date on which the subscription is sent {&Date} Time at which the subscription is sent {&Time} Name of the recipient {&RecipientName} User ID (32-character GUID) of the recipient {&RecipientID} Distribution Services add...

Types of result caches in Microstrategy

Types of result caches Microstrategy The following types of  result caches are created by Intelligence Server: • Matching caches • History caches • Matching-History caches • XML caches All document caches are Matching caches; documents do not generate History caches or XML caches. Intelligent Cube reports do not create Matching caches. Matching caches Matching caches  are the  results of reports and documents that are retained for later use by the same requests later on. In general, Matching caches are the type of result caches that are used most often by Intelligence Server. When result caching is enabled, Intelligence Server determines for each request whether it can be served by an already existing Matching cache. If there is no match, it then runs the report or document on the database and creates a new Matching cache that can be reused if the same request is submitted again. This caching process is managed by the system administrator and ...

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to  Main.aspx  or  mstrWeb  (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Fact tables levels tables in Microstrategy explained

Fact tables levels in Microstrategy: Fact tables are used to store fact data. Fact tables should contain attribute Id's and fact values which are measurable. All the descriptive information about the fact tables should stored in Dimension tables either in Star Schema fashion or Snow Flake Schema fashion which is best suited to your reporting solution. Since attributes provide context for fact values, both fact columns and attribute ID columns are included in fact tables. Facts help to link indirectly related attributes using these attribute ID columns. The attribute ID columns included in a fact table represent the level at which the facts in that table are stored. So the level of a fact table in the Fact_Item_Day_Customer can be the attribute Id's which is at Day, Item & Customer Id level. For example, fact tables containing sales and inventory data look like the tables shown in the following diagram: Base fact columns ver...

Fiscal Week, Fiscal Month, Fiscal Quarter and Fiscal Year calculations in Microstrategy

Fiscal Week, Fiscal Month, Fiscal Quarter and Fiscal Year calculations in Microstrategy FiscalWeek Returns the numeric position of a week within a fiscal year, for a given  input date. This function is useful in financial reporting when the start of the fiscal year is different than the start of the calendar year. Syntax FiscalWeek< firstWeekDay ,  firstMonth >( Date / Time ) Where: • Date / Time  is the input date or timestamp. • firstWeekDay  (default value is 1) is a parameter that determines which day of the week is considered as the first day of the week. You can type an integer value from 1 to 7, with 1 representing Sunday, 2 representing Monday, and so on until 7 representing Saturday. • firstMonth  (default value is 1) is a parameter that determines which month is considered as the start of the fiscal year. You can type an integer value from 1 to 12, with 1 representing January, 2 representing February, and so on until ...