Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
Analytic Services provides a comprehensive system for managing access to applications, databases, and other objects. The Analytic Services security system provides protection in addition to the security available through your local area network.
This chapter contains the following sections:
The Analytic Services security system addresses a wide variety of database security needs with a multi layered approach to enable you to develop the best plan for your environment. Various levels of permission can be granted to users and groups or defined at the system, application, or database scope. You can apply security in the following ways:
To grant permissions to individual users and groups of users. When higher, these permissions take precedence over minimum permissions defined for applications and databases. Ordinary users have no inherent permissions. Permissions can be granted to users and groups by editing the users and groups or by using the grant statement in MaxL DDL (data-definition language). For an explanation of the methods used to grant permissions, see Granting Permissions to Users and Groups.
You can create users who log on using the parameters of an external authentication repository instead of the Analytic Services password. If you want users to use an outside authentication repository such as LDAP, you must implement the Hyperion security platform and create the Analytic Services users with a reference to the security platform. For information about the security platform, see Using the Hyperion Security Platform for External Authentication.
To set common permissions for all users of an application or database, you can set minimum permissions that all users can have at each application or database scope. Users and groups with lower permissions than the minimum gain access; users and groups with higher granted permissions are not affected. You can also temporarily disable different kinds of access using application settings. For a detailed explanation of the use of application and database settings, see Managing Global Security for Applications and Databases.
Create and manage login restrictions for the entire Analytic Server. View and terminate current sessions and requests running on the entire Analytic Server or only on particular applications and databases. For a comprehensive discussion of how to manage the activities of users, see Managing User Activity on the Analytic Server.
Define database permissions that users and groups can have for particular members, down to the individual data value (cell). To learn more about how and why to use filters, see Controlling Access to Database Cells.
Table 28 describes all security permissions and the tasks that can be performed with those permissions.
Permission |
Affected Scope |
Description |
---|---|---|
No inherent access to any users, groups, or data values, unless access is granted globally or by means of a filter. No Access is the default when creating an ordinary user. Users with No Access permissions can change their own passwords. |
||
Ability to read metadata (dimension and member names) and update data for the corresponding member specification. |
||
Ability to calculate, read, and update data values for the assigned scope, using the assigned calculation. Supervisors, application designers for the application, and database designers for the database can run calculations without being granted execute access. |
||
Ability to modify outlines, create and assign filters, alter database settings, and remove locks/terminate sessions and requests on the database. A user with Database Designer permission in one database does not necessarily have that permission in another. |
||
Ability to create, delete, and modify databases within the assigned application. Ability to modify the application settings, including minimum permissions, remove locks on the application, terminate sessions and requests on the application, and modify any object within the application. You cannot create or delete an application unless you also have been granted the system-level Create/Delete Applications permission. A user with Application Designer permission in one application does not necessarily have that permission in another. |
||
Ability to access specific data and metadata according to the restrictions of a filter assigned to the user or group. The filter definition specifies, for subsets of a database, whether Read, Write, No Access, or MetaRead is allowed for each subset. A user or group can be granted only one filter per database. Filters can be used in conjunction with other permissions. For a comprehensive discussion of filters, see Controlling Access to Database Cells. |
||
Ability to create and delete applications and databases within those applications, and control permissions, locks, and resources for applications created. Includes designer permissions for the applications and databases created by this user. |
||
Ability to create, delete, edit, or rename all users and groups having equal or lesser permissions than their own. |
||
When you create a user or a group in Analytic Services, you define a security profile. The security profile is where you define the extent of the permissions that users and groups have in dealing with each other and in accessing applications and databases. This section contains the following sections:
If you are using Administration Services, you also need to create users on the Administration Server. For more information, see About Administration Services Users.
To create a user means to define the user name, password, and permission. You can also specify group membership for the user, and you can specify that the user is required to change the password at the next login attempt, or that the user name is disabled, preventing the user from logging on.
User names can contain only characters defined within the code page referenced by the ESSLANG variable and they cannot contain the backslash (\) character. User names must begin with a letter or a number.
To create a new user, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
For example, to create a user named admin and grant that user Supervisor permissions, use the following MaxL statements:
create user admin identified by 'password'; grant supervisor to admin;
A group is a collection of users who share the same minimum access permissions. Placing users in groups can save you the time of assigning identical permissions to users again and again.
Note: A member of a group may have permissions beyond those assigned to the group, if permissions are also assigned individually to that user.
The process for creating, editing, or copying groups is the same as that for users, except that there are no group passwords. You define group names and permissions just as you do for users.
Note: A group name may not contain a backslash (\).
When you create a new user, you can assign the user to a group. Similarly, when you create a new group, you can assign users to the group. You must define a password for each user; there are no passwords for groups.
To create groups, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can define security permissions for individual users and groups. Groups are collections of users that share the same minimum permissions. Users inherit all permissions of the group and can additionally have access to permissions that exceed those of the group.
Permissions can be granted to users and groups in the following ways:
One way to assign permissions to users and groups is to define user and group types when you create or edit (modify the permissions of) the users and groups.
In Administration Services, users and groups can be created in different ways to specify their system-level permissions. These methods are represented in Administration Services Console as user types. In MaxL, user types do not exist; instead you grant the permissions after the user is created.
In Administration Services, users can be created with the following types:
A user or group with Supervisor permission has full access to the entire system and all users and groups. The user who installs Analytic Services on the server is designated the System Supervisor for that server. Analytic Services requires that at least one user on each server has Supervisor permission. Therefore, you cannot delete or downgrade the permission of the last supervisor on the server.
Users or groups with ordinary permission have no inherent access to any users, groups, or resources. This type of user is the default user.
This type of user or group can create, delete, edit, or rename users and groups with equal or lower permissions only.
This type of user or group can create and delete applications and control permissions and resources applicable to those applications or databases they created.
Users with Create/Delete Applications permission cannot create or delete users, but they can manage application-level permission for those applications that they have created. For a comprehensive discussion of application-level permission, see Managing Global Security for Applications and Databases.
For instructions about creating users and groups, see Creating Users and Creating Groups.
If you need to grant resource-specific permissions to users and groups that are not implied in any user types, you can grant the specific application or database permissions to users when creating or editing them in Administration Services. Using MaxL, you grant the permissions after the user is created by using the grant statement.
You can grant or modify user and group application and database permissions from an edit-user standpoint or from an application or database security perspective. The results are the same.
Note: If a user has insufficient permission to access the data in a database, the value does not show up in queries, or shows up as #NOACCESS.
There is no need to grant permissions to users or groups that are already Supervisors-they have full permissions to all resources on the Analytic Server. For a given database, users or groups can also be granted any of the following permissions:
Database permission |
Description |
---|---|
Indicates no access to any object or data value in a database. |
|
Indicates that data and metadata access is restricted to those filters assigned to the user. (For a comprehensive discussion of filters, see Controlling Access to Database Cells.) The Filter check box grants a filter object to a user or group. A user or group can be granted only one filter per database. Selecting this option or any other option except None enables the selection of a filter object from the list box. |
|
Indicates read permission, that is, the ability to retrieve all data values. Report scripts can also be run. |
|
Indicates that all data values can be retrieved and updated (but not calculated). The user can run, but cannot modify, Analytic Services objects. |
|
Indicates that metadata (dimension and member names) can be retrieved and updated for the corresponding member specification. |
|
Indicates that all data values can be retrieved, updated, and calculated with the default calculation or any calculation for which the user has been granted permission to execute. |
|
Indicates that all data values can be retrieved, updated, and calculated. In addition, all database-related files can be modified. |
To grant or modify application or database permissions for a user or group, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
Managing User/Group Permissions for Applications and Databases |
||
Users and groups can be granted Application Designer or Database Designer permission for particular applications or databases. These permissions are useful for assigning administrative permissions to users who need to be in charge of particular applications or databases, but who only need ordinary user permissions for other purposes.
You need to grant database access to other users if any of the following conditions apply:
For references to methods you can use to grant Designer permissions to a user or group, see Granting Application and Database Access to Users and Groups.
To help manage security between users and groups, the following user-management tasks are available at varying degrees to users with different permissions:
To view users and groups, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
To edit a user means to modify the security profile established when the user was created. For information about changing user passwords, see Propagating Password Changes.
To change a password or other user properties, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
To edit a group means to modify the security profile established when the group was created.
To view or change group membership, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
An easy way to create a new user with the same permissions as another user is to copy the security profile of an existing user. The new user is assigned the same user type, group membership, and application/database access as the original user.
You can also create new groups by copying the security profile of an existing group. The new group is assigned the same group type, user membership, and application access as the original group.
You can copy users and groups on the same Analytic Server or from one Analytic Server to another, according to your permissions. You can also migrate users and groups across servers along with an application. For more information, see "Copying Users" in Essbase Administration Services Online Help.
To copy a user or group means to duplicate the security profile of an existing user or group, and to give it a new name. It is helpful to copy users and groups because it saves you the time of reassigning permissions in cases where you want them to be identical.
Note: Copying removes any security permissions the creator does not have from the copy. For example, a user with Create/Delete Users permission cannot create a new supervisor by copying the profile of an existing supervisor.
To create a new user or group by copying the security profile of an existing user or group, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
To delete users and groups, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
To rename users and groups, use either of the following methods:
Note: A group name may not contain a backslash (\).
Tool |
Topic |
Location |
---|---|---|
External authentication means that the user login information needed by Analytic Services is maintained in a central authentication directory, such as Lightweight Directory Access Protocol (LDAP) Directory, Microsoft Active Directory, or Windows NT LAN Manager.
An authentication directory is a centralized store of user information such as login names and passwords, and other corporate information. The repository functions like a telephone directory. The authentication directory probably contains much more than user names and passwords; for example, it may include e-mail addresses, employee IDs, job titles, access rights, and telephone numbers. It may also contain objects other than users; for example, it may contain information about corporate locations or other entities.
To use the security platform for Analytic Services, your organization must already have an authentication directory that contains centralized user information. Additionally, you must employ an XML-based security configuration file to specify correct information pertaining to your corporate authentication directory.
The following types of authentication repositories are supported by the security platform:
To learn more about implementing the Hyperion security platform,
Note: Prior to this release, Analytic Services provided support for external authentication using built-in modules supplied as parameters to the AUTHENTICATIONMODULE essbase.cfg
setting. Those modules did not include the ability to share the same external authentication scheme with other Hyperion software applications or to enable single sign-on to Analytic Services from other Hyperion applications. Support for the earlier modules is unaffected by the new security platform. Implementation of the security platform is optional, but Hyperion strongly encourages using the security-platform authentication over the built-in modules authentication.
In addition to granting permissions to users and groups, you can change security settings for entire applications and databases and their related files and resources. Application and database security settings enable you to manage connections and create a lowest-common-security profile for the applications and databases.
This section contains the following sections:
You can define permissions and other security settings that apply to applications by changing the application settings. The settings you define for the application affect all users, unless they have higher permissions granted to them at the user level.
Only users with Supervisor permission (or Application Designer permission for the application) can change application settings.
To define settings for an application, see Setting General Application Connection Options or Setting Application and Database Minimum Permissions.
The following application settings are available:
The following settings are available for various levels of application security. For information about how and when disabling these settings takes effect, see Table 30.
When disabled, prevents all users from starting the application directly or as a result of operations that would start the application; for example, attempting to change application settings or create databases. By default, the application is not prevented from starting.
When enabled, the application starts automatically whenever the Analytic Server starts. By default, the application does not start when the Analytic Server starts.
When unchecked, prevents any user from making any requests to databases in the application, including non-data-specific requests such as viewing database information or changing database settings. Supervisors are affected by this setting as a safety mechanism to prevent accidental changes to databases during maintenance operations. By default, commands are enabled.
When unchecked, prevents any user with a permission lower than Application Designer for that application from making connections to databases within the application which require the databases to be started. By default, connections to databases are allowed.
When unchecked, prevents modification to on-disk database structures; for example, any operation that might have an effect on the data, including updating the data or making outline modifications. Supervisors are affected by this setting as a safety mechanism to prevent accidental updates to databases during maintenance operations. By default, updates are enabled.
When unchecked, Analytic Services ignores all security settings in the application and treats all users as Application Designers. By default, security is enabled.
Table 30 describes when the implementation of protective application settings takes effect, how long the effects last, and which users are affected.
To change application settings, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
Note: If performing maintenance operations that require disabling commands or updates, make those maintenance operations within the same session as the one in which the setting was disabled.
If you disable commands or updates in a MaxL script, be aware that the end of the script constitutes the end of the session. Calling a nested MaxL or ESSCMD script from the current MaxL script also constitutes the end of the session.
If you disable commands or updates in an ESSCMD script, the end of the script constitutes the end of the session, but calling a nested ESSCMD script from the current ESSCMD script does not constitute the end of the session.
Caution: Never power down or reboot your client computer when you have cleared any of the Allow settings. Always log off from the server correctly. Improper shutdown can cause the application to become inaccessible, which requires a full application shutdown and restart.
If a power failure or system problem causes Analytic Server to improperly disconnect from the Analytic Services client, and the application is no longer accessible, you must shut down and restart the application. For instructions about starting and stopping Analytic Services, see Starting and Stopping Analytic Server.
Minimum database access permissions can be specified at the application or database level. If specified for an application, minimum database access permissions apply to all databases within the application. When a minimum permission is set to a level higher than None (or No Access) for an application or database, all users inherit that permission to access the database or databases.
For example, if an application has Read permission assigned as the minimum database access level, all users can read any database within that application, even if their individual permissions do not include Read access. Similarly, if a database has a minimum permission setting of None, only users with sufficient granted permissions (granted directly, or implied by filters or group membership) can gain access to the database.
Users with Supervisor, Application Designer, or Database Designer permissions are not affected by minimum-permission settings applied to applications or databases they own. Supervisors have full access to all resources, and Application Designers and Database Designers have full access for their applications or databases.
Users and groups with lower than the minimum permissions inherit at least the minimum permissions for any applications or databases.
Changes to the minimum permission settings for applications affect only those databases that have lower minimums. In other words, settings defined at a lower level take precedence over more global settings.
The permissions listed in Table 31 are available as minimum settings for applications and databases. Databases of an application inherit the permissions of the applications whenever the application permissions are set higher than those of the database.
Note: Although any user with a minimum of Read access to a database can start the database, only a Supervisor, a user with Application Designer permission for the application, or a user with Database Designer permission for the database can stop the database.
To set minimum permissions for an application, see "Setting Minimum Permissions for Applications" in the Essbase Administration Services Online Help, or see alter application in the MaxL DDL section of the Technical Reference.
To set minimum permissions for a database, see "Setting Minimum Permissions for Databases" in the Essbase Administration Services Online Help, or see alter database in the MaxL DDL section of the Technical Reference.
This topic explains how to manage the activities of users connected to the Analytic Server. The security concepts explained in this section are session and request management, lock management, connection management, and password and user name management. For information about managing security for partitioned databases, see Designing Partitioned Applications.
The security system lets you disconnect a user from the Analytic Server when you want to perform maintenance tasks.
To view sessions, disconnect sessions, or terminate requests, you must have Supervisor permission or Application Designer permission for the specified application. You can view or terminate only sessions or requests for users with permissions equal to or lesser than your own.
A session is the time between login and logout for a user connected to Analytic Server at the system, application, or database scope. A user can have more than one session open at any given time. For example, a user may be logged on to different databases. If you have the appropriate permissions, you can log off sessions based on any criteria you choose; for example, an administrator can log off a user from all databases or from a particular database.
A request is a query sent to Analytic Server by a user or by another process; for example, a default calculation of a database, or a restructuring of the database outline. Each session can process only one request at a time.
Note: You cannot terminate a restructure process. If you attempt to terminate it, a "command not accepted" error is returned, and the restructure process is not terminated.
To disconnect a session or request using Administration Services, see "Disconnecting User Sessions and Requests" in the Essbase Administration Services Online Help.
To disconnect a session or request using MaxL, see the following table:
Spreadsheet Add-in users can interactively send data from a spreadsheet to the server. To maintain data integrity while providing multiple-user concurrent access, Analytic Services enables users to lock data for the purpose of updating it. Users who want to update data must first lock the records to prevent other users from trying to change the same data.
Occasionally, you may need to force an unlock operation. For example, if you attempt to calculate a database that has active locks, the calculation must wait when it encounters a lock. By clearing the locks, you allow the calculation to resume.
Only Supervisors can view users holding locks and remove their locks.
To view or remove locks, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can place limitations on the number of login attempts users are allowed, on the number of days users may not use Analytic Services before becoming disabled from the server, and on the number of days users are allowed to have the same passwords. Only system administrators (users with Supervisor permission) can access these settings. The limitations apply to all users on the server, and are effective immediately upon clicking OK.
Note: If you later change the number of unsuccessful login attempts allowed, Analytic Services resets the count for all users. For example, if the setting was 15 and you changed it to 20, all users are allowed 20 new attempts. If you changed the setting to 2, a user who had already exceeded that number when the setting was 15 is not locked out. The count returns to 0 for each change in settings.
To place limitations on users, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can change a user's password and then propagate the new password to other Analytic Servers. You need Create/Delete Users and Groups permissions for both the source and the target servers. The user whose password you are changing must exist on the target servers, and the target servers must be running.
If you use Administration Services to change a user's Analytic Server password, and if the user is also an Administration Services user, the user's Administration Services user properties are updated automatically. The user's Administration Services password is not affected. For more information, see "Changing Passwords for Analytic Server Users" in Essbase Administration Services Online Help.
To change a user's Analytic Server password and propagate the new password to other Analytic Servers, see "Propagating Passwords Across Servers" in Essbase Administration Services Online Help.
You can prevent a user from logging in to an Analytic Server by disabling the user name at the Analytic Server level. A username is disabled automatically when the user exceeds limitations specified, or a username can be disabled manually for individual users. For more information about limitations that cause user names to become disabled automatically, see Managing Passwords and User Names.
Administration Services provides a Disabled Usernames window that enables you to view and activate all usernames that have been disabled for an Analytic Server. Only a user with at least Create/Delete User permission can view or reactivate disabled user names.
To disable a user name manually, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
To view or activate currently disabled user names, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
All information about users, groups, passwords, permissions, filters, applications, databases, and their corresponding directories is stored in the essbase.sec
file in the ARBORPATH\bin
directory. Each time you successfully start the Analytic Server, a backup copy of the security file is created as essbase.bak
. You can also update the security backup file more often by using one of the following methods:
To update the security backup file, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
If you attempt to start Analytic Server and cannot get a password prompt or your password is rejected, no .bak
file is created. You can restore from the last successful startup by copying essbase.bak
to essbase.sec
. Both files are in the essbase\bin
directory where you installed Analytic Services.
Caution: If Analytic Services stops running unexpectedly for any reason, such as a freeze or crash, or as the result of terminating a process, do not restart Analytic Server until you copy the backup file (essbase.bak
) to the security file (essbase.sec
). If you do not perform the copy first, when Analytic Server starts, Analytic Services notes that essbase.sec
is corrupt, creates an empty security file, and copies it to essbase.bak
, thus destroying the backup of your security information.
![]() |