User Management and Security in EPM System Security Mode

In This Section:

Using Essbase in EPM System Security Mode

Security for Users and Groups in EPM System Security

Essbase User Roles for Shared Services

Essbase Projects, Applications, and Databases in Shared Services

Essbase Users and Groups in Shared Services

Assigning Access to Users in Shared Services

Migrating Essbase to EPM System Security

User and Group Identities

Security Information Recovery in EPM System Security Mode

Also see:

Using Essbase in EPM System Security Mode

Essbase user management and security is provided through EPM System security, which uses Oracle's Hyperion® Shared Services to provide user management, user provisioning, and external authentication definition. Provisioning refers to the process of assigning roles and access permissions to users for Essbase applications.

Products that implement EPM System security require access to a Shared Services server running Shared Services client and server software, and to a database dedicated to Shared Services.

When using the default deployment option, Essbase is deployed in EPM System security mode.

If you choose not to deploy Essbase in EPM System security mode, Essbase uses its own native security mode to manage security for Essbase applications, databases, and artifacts. There is no change in behavior for Essbase in native security mode, except when using native security mode with external authentication. See Continuing to Use Essbase in Native Security Mode.

To use EPM System security for Essbase deployments that are in Essbase native security mode, you must migrate any Essbase Server applications and any existing Essbase users and groups to Shared Services. See Migrating Essbase to EPM System Security.

Security for Users and Groups in EPM System Security

When running Essbase in EPM System security mode, Essbase obtains user and group details (including user and group information and provisioning to Essbase applications) from Shared Services. Essbase no longer stores all users and groups in the Essbase security file (essbase.sec); therefore, an Essbase Administrator does not need to explicitly synchronize security between Essbase and Shared Services.

When a user logs on to Essbase, Essbase queries Shared Services for that user’s information. The privileges with which a user starts a session are preserved throughout the session, regardless of whether the user’s privileges are changed in Shared Services during the session.

A user or group is stored in the Essbase security file only under the following circumstances:

  • The user or group was not successfully migrated to Shared Services.

  • The user or group is assigned database calculation or filter access.

  • The user or group is specified in the query governor exclude list.

  • The user is the creator of an application or database.

  • The user has locked a database-related artifact.

  • The PERSISTUSERATLOGIN configuration setting is set to TRUE.

    When a user logs on to Essbase, PERSISTUSERATLOGIN specifies whether to add the user to the essbase.sec file, if the user does not already exist in the file.

To remove users or groups from the Essbase security file without de-provisioning them from Shared Services, use the drop user or drop group MaxL statements with the from security_file grammar. Calculation and filter associations also are removed.

For display operations, Essbase queries Shared Services. See:

EPM System Security Migration and Upgrade Considerations

When migrating Essbase from Essbase native security to EPM System security, users that do not successfully migrate are retained in the Essbase security file.

If a user’s database permissions changed during migration to Shared Services, information is written to a text file named AccessModifiedUsers_n.txt, where n represents the sequence ID for the instance of Essbase that is registered with Shared Services. (The sequence ID is incremented each time Essbase is externalized.) This file, which is located in the ARBORPATH/bin directory, contains the following information:

  • The user’s name

  • Applications and databases to which the user has access

  • The user's access level for a specific database before migration to Shared Services

  • The user’s access level after migration to Shared Services, including access acquired through groups and other means

  • The user’s filter assignments

In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels (however, users can have different calculation script and database filters assigned for databases within the same application). During migration to Shared Services, if a user has different access levels for two databases in the same application, the user is given the more restrictive access level for both databases.

When migrating Shared Services users with the option to have user passwords automatically generated, those user names and passwords are written to a text file named MigratedUsersPassword.txt, which is located in the ARBORPATH/bin directory. If the Administrator designated a specific password for the migrated users, the password is not listed in the file. This file is created when performing an upgrade or migration.

User Security Considerations after EPM System Security Migration and Upgrade

The following security issues must be addressed after migrating users to Shared Services or upgrading Essbase:

  • To log on to Essbase and access the Essbase agent, a user no longer must have the Server Access role on the global Essbase Server application. A user with any role (whether directly or indirectly provisioned) on an Essbase application can log on to Essbase and access the Essbase agent.

    To prevent users who do not have a role on the global Essbase Server application from accessing the Essbase agent, you must manually modify users’ roles. Be sure to evaluate the roles that a user inherits from a group.

  • When a user logs on to Essbase, Essbase queries Shared Services for the user’s roles. The more roles that a user has, the longer it takes to complete the login process. To improve login performance, users should not be assigned unneeded roles.

    Essbase no longer assigns the Application Manager role, which is unnecessary, to an Essbase Administrator when he creates an Essbase application. If, in your Essbase deployment, the Application Manager role is assigned to Essbase Administrators, you must manually remove the Application Manager role from the Essbase Administrators.

    Also, an Essbase Administrator who has an Administrator role on the global Essbase Server application might be assigned application roles that are not needed. Essbase provides a migration utility that can remove the application roles for Essbase Administrators only.

The migration utility (which runs on 32-bit Windows only), identifies the users who are affected by both security issues. Additionally, if specified, the utility can correct the issue of Essbase Administrators having application roles.

  To run the migration.bat file:

  1. Navigate to the ESSBASEPATH/utilities directory.

  2. Unzip the migration.zip file, which creates a MigrationTools subdirectory.

  3. In the MigrationTools subdirectory, edit the migration.properities file with the following information:

    • AdminUserName—Name of the Essbase Administrator who runs the migration utility

    • AdminUserPassword—The Essbase Administrator’s password

    • HSSServer—Hostname of the Shared Services Server

    • HSSPort—Port number of the Shared Services Server

    • EssbaseProjectName—The project name for the Essbase Server on which you want to run the migration utility

    • SavedToFile—When set to TRUE, specifies that the results of the migration script should be written to the following text files, which are located in the MigrationTools subdirectory:

      • EntitiesWithCubeRolesOnly.txt—Lists the users and groups that have application roles but do not have a role on the global Essbase Server application

      • EssbaseAdminsWithCubeRoles.txt—Lists the Essbase Administrators who have application roles

        When set to FALSE (the default), the results are written to the screen.

        Sample versions of these files are located in the MigrationTools subdirectory.

    • FixAdminUser—When set to TRUE, removes application roles from Essbase Administrators. When set to FALSE (the default), writes the names of Essbase Administrators, and the application roles assigned to them, to the screen.

      For example:

      AdminUserName = admin
      AdminUserPassword = password
      HSSServer = pant5
      HSSPort = 58080
      EssbaseProjectName = Analytic Servers:ALNG3:1
      SavedToFile true
      FixAdminUser false
      

    Note:

    When running the utility for the first time against an Essbase Server, Oracle recommends setting SavedToFile to TRUE and FixAdminUser to FALSE so that you can view and verify the results. Then, you can set FixAdminUser to TRUE and run the utility again to remove application roles from Essbase Administrators.

  4. Run the migration.bat file.

  5. Make any necessary manual changes.

Essbase User Roles for Shared Services

Roles, which determine the tasks that users can perform, can be grouped in the following ways:

  • Product-specific roles

    Examples of Essbase roles are Administrator and Database Manager. All Essbase roles are specific to a Shared Services application (the permissions granted to the user by the role apply only to the specific application for which the role is assigned, and not to all applications).

  • Shared Services roles

    Examples of Shared Services roles are Project Manager or Provisioning Manager. Most Shared Services roles are global (the role applies to all Shared Services applications). An exception is the Provisioning Manager role, which is specific to an application.

    See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.

The following Essbase roles provide different levels of authority to perform tasks in Essbase.

You can provision a user with the following roles for an Essbase Server:

  • Administrator

  • Create/Delete Application

  • Server Access

You can provision a user with the following roles for an application:

  • Application Manager

  • Database Manager

  • Calc

  • Write

  • Read

  • Filter

  • Start/Stop Application

In Shared Services Console, roles belonging to Essbase are grouped under the Essbase node; roles belonging to Essbase applications are grouped under the application nodes.

Note:

There is no concept of provisioning an Administration Services Administrator user role through Shared Services. When migrated, an Administration Services Administrator is assigned no roles in Shared Services.

Table 120 lists the user roles that are specific to Essbase and the Shared Services role of Provisioning Manager, which is application-specific. The table shows the corresponding tasks that each user can perform.

Table 120. Essbase and Shared Services User Roles and Tasks

User Role

Task Description

Project Manager

(A Shared Services role) Creates and manages projects within Shared Services.

Administrator (previously Supervisor)

Full access to administer the server, applications, and databases.

Note:

The Provisioning Manager role, which is a Shared Services application-specific role, is automatically assigned when you migrate Essbase Administrators (previously known as Supervisors). However, when you create an Essbase Administrator in Shared Services Console, you must manually assign the Provisioning Manager role. Users with the Provisioning Manager role can provision users and groups with roles for applications.

Create/Delete Application

Ability to create and delete applications and databases within applications. Includes Application Manager and Database Manager permissions for the applications and databases created by this user.

Server Access

Ability to access any application or database that has a minimum access permission other than none.

Application Manager (previously Application Designer)

Ability to create, delete, and modify databases and application settings within the particular application. Includes Database Manager permissions for databases within the application.

Note:

The Provisioning Manager role is automatically assigned when you migrate Essbase Application Managers. However, when you create an Essbase Application Manager in Shared Services Console, you must manually assign the Provisioning Manager role.

Database Manager (previously Database Designer)

Ability to manage databases (for example, to change the database properties or cache settings), database artifacts, locks, and sessions within the assigned application.

Calc

Ability to calculate, update, and read data values based on the assigned scope, using any assigned calculations and filter.

Write

Ability to update and read data values based on the assigned scope, using any assigned filter.

Read

Ability to read data values.

Filter

Ability to access specific data and metadata according to the restrictions of a filter.

Start/Stop Application

Ability to start and stop an application or database.

Essbase Projects, Applications, and Databases in Shared Services

Shared Services artifacts include projects, applications, user roles, users, and groups. When you assign access to a user or group in Shared Services, you provision the user or group with a role for an application. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.

Shared Services and Essbase both use the term “application.” Essbase uses “application” to refer to a container for databases. Shared Services uses “application” to refer to an artifact for which you provision users. In this topic, “application” refers to a Shared Services application, unless an Essbase application is specifically stated. In most cases, an Essbase application maps to a Shared Services application, so the distinction is unnecessary.

For Essbase, migration is done at the Essbase Server level. When you migrate an Essbase Server to Shared Services, a Shared Services project is created for the Essbase Server. The project is named Essbase:machineName:EssbaseServer#, where machineName is the Essbase Server computer name and EssbaseServer# is the sequence number. The sequence number for the first Essbase Server that is migrated is 1. When migrating multiple Essbase Servers on the same computer, the sequence number is incremented by 1. Also, if you delete the security file and remigrate an Essbase Server, each successful migration creates a new server project with a new sequence number. You can delete unwanted projects in Shared Services Console.

Essbase automatically creates the following applications within the project and automatically registers the applications with Shared Services:

  • An application named Essbase:machineName:EssbaseServer#, which is the same name as the Shared Services project. This application, which allows you to specify security at the Essbase Server level, is known as the global Essbase Server application. After migration, you can change the name of the global application and application project in Shared Services by using the alter system MaxL statement with the rename global registration name grammar. See the Oracle Essbase Technical Reference.

  • A Shared Services application for each Essbase application on the Essbase Server. In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels. (However, users can have different calculation script and database filters assigned for databases within the same application. See Assigning Database Calculation and Filter Access in Shared Services.)

    In the following illustration, the first instance of Essbase:JWARD:1 is the Shared Services project for the first Essbase Server migrated on JWARD. The second instance of Essbase:JWARD:1 is the global Essbase Server application.

    Projects
       Essbase:JWARD:1
          ASOsamp
          DMDemo
          Demo
          Essbase Servers:JWARD:1
          Sampeast
          Sample
          Sample_U
          Samppart

After you have migrated to Shared Services, when you create an application and database in Essbase, a corresponding Shared Services application is created within the Essbase Server project, and the application is automatically registered with Shared Services.

Essbase Users and Groups in Shared Services

When you migrate to Shared Services, all native Essbase users and groups that do not already exist in an external authentication directory are converted to native Shared Services users and groups in the native Shared Services user directory and are given equivalent roles. Externally authenticated users are registered with Shared Services but are still stored in their original authentication directory. See User and Group Migration.

After you have migrated to Shared Services, you must create and manage users and groups in Shared Services Console, or through the external user directory. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.

When users and groups are stored in an external authentication directory from any supported authentication provider, a user and group can have the same name on the same provider; however, two users or two groups can not have the same name on the same provider.

Shared Services supports aggregated groups, in which a parent group contains one or more subgroups. The subgroups inherit the roles of their parent group. For example, if a parent group is provisioned with the Essbase Administrator role, any subgroups (and users in the groups) inherit the Essbase Administrator role.

Note:

In Essbase, when you copy an application or database and the target Essbase Server is in EPM System security mode, user and group security is not copied with the application. Use the copy provisioning functionality in Shared Services Console to copy security for an application.

Assigning Access to Users in Shared Services

Shared Services Console provides a centralized UI where you can perform user management tasks for EPM System products. The Shared Services Console launches Essbase screens, which allow you to assign security access to database filters and calculation scripts. In EPM System security mode, you use Shared Services Console, MaxL, or the API to manage security. (Some restrictions exist when managing security using MaxL or the API. See the Oracle Essbase Technical Reference and the Oracle Essbase API Reference.) In Administration Services Console you can only view security information.

For information on assigning access to users and groups and viewing a report of users, groups, and provisioned roles for each application, see the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.

Launching and Logging In to Shared Services Console

To manage Essbase users in Shared Services Console, you must log on to the console as a user who is provisioned with the following Shared Services roles:

  • Provisioning Manager role for the appropriate Essbase Server or applications

  • Directory Manager role for the appropriate authentication directory

When you launch Shared Services Console from a browser, you log on as whichever user is appropriate. For example, you must log on as a Shared Services Administrator to provision an Essbase Administrator with the Directory Manager role, so that he or she can create and delete users.

Assigning Server Access in Shared Services

To specify security at the Essbase Server level in EPM System security mode (for example, provisioning a user with the Provisioning Manager role for all Essbase applications on an Essbase Server), provision the user with the appropriate role for the global Essbase Server application; that is, the Shared Services application that represents the Essbase Server. See Essbase Projects, Applications, and Databases in Shared Services.

Figure 143, Shared Services Console Provisioning Panel shows the roles that are available for the Essbase Server named DTRIPATH-PC1 and the Demo application.

Figure 143. Shared Services Console Provisioning Panel

This image shows the provisioning panel in Shared Services Console, as described in the text preceding the image.

Note:

When you provision a user with the Essbase Administrator role, you must also manually provision the user with the Provisioning Manager role for the Essbase Server and for each Essbase application on the server. (When you migrate an Essbase Administrator, the Provisioning Manager role is automatically assigned.)

Assigning Application Access in Shared Services

To specify security at the Essbase application level in EPM System security mode (for example, provisioning a user with the Database Manager role for the Sample application), provision the user with the appropriate role for the application.

Note:

When you provision a user with the Application Manager role, you must also manually provision the user with the Provisioning Manager role for the appropriate application. (When you migrate an Essbase Application Manager, the Provisioning Manager role is automatically assigned.)

You can set minimum permissions for an application, for example, if you want all users to have at least write access to all databases in an application. The default setting is None, meaning that no minimum permission is set; all users can access the application according to their roles.

  To set the minimum permission for an application, see “Setting Minimum Permissions for Applications” in the Oracle Essbase Administration Services Online Help.

Assigning Database Calculation and Filter Access in Shared Services

After provisioning users for Essbase applications in Shared Services Console, you can assign more granular access permissions to users and groups for a specific Essbase application and database. For example, after assigning a user access to an application and assigning the user’s role for the application, you can assign an Essbase filter to the user, or assign the user access to a specific calculation script.

You must create the filters and calculation scripts in Essbase. See Controlling Access to Database Cells Using Security Filters.

When you select an Essbase application from Shared Services Console, you see a list of the users and groups provisioned to that application. You can select the users and groups to which you want to assign additional permissions. You then select the database to which a user or group needs access, and assign filter and calculation script access to selected users and groups. See the Shared Services Console online documentation.

  To specify access permissions in Shared Services, use a tool:

Tool

Topic

Location

Administration Services

Assigning Database Calculation and Filter Access

Oracle Essbase Administration Services Online Help

MaxL

grant

Oracle Essbase Technical Reference

When you assign database calculation and filter access, you automatically log on to Administration Services and Essbase as the Shared Services Console logged-in user. This user must be an Essbase Administrator, Application Manager, or Database Manager. The user must have the Provisioning Manager role for the appropriate applications.

You cannot assign database calculation or filter access to an Essbase Administrator or Application Manager.

Assigning Application Access Type in Shared Services

Essbase and Planning have the concept of an application access type for Essbase and Planning users. For example, when an Essbase user is created using any Essbase administration tool, the user is automatically assigned the application access type “Essbase;” when a Planning user is created using the Planning interface, the user is automatically assigned the application access type “Planning.” A user’s application access type specifies whether the user has access to Essbase applications only, to Planning applications only, or to both.

In Shared Services Console, you can select a global Essbase Server application to see the list of users and groups provisioned to that application. See the Oracle Hyperion Enterprise Performance Management System User and Role Security Guide.

When you assign database calculation and filter access, you automatically log on to Administration Services and Essbase as the Shared Services Console logged-in user. This user must be a valid Essbase Administrator and must have the Provisioning Manager role for the appropriate applications.

  To refresh Essbase with application access type information for newly provisioned users, click Refresh.

Migrating Essbase to EPM System Security

If Essbase and Administration Services are in Essbase native security mode, you can migrate to EPM System security mode. For Essbase, migration is done at the Essbase Server level. After you have converted to EPM System security mode, you cannot convert back to Essbase native security mode.

Essbase Administration Server can run in EPM System security mode with Essbase Server running in Essbase native security mode. However, if any Essbase Server that you administer from Administration Services Console runs in EPM System security mode, Essbase Administration Server must also.

  To migrate Essbase Server, Essbase Administration Server, and users and groups to EPM System security, use a tool:

Tool

Topic

Location

Administration Services

Converting Essbase Server and Migrating Users to Shared Services

Oracle Essbase Administration Services Online Help

MaxL

alter system

Oracle Essbase Technical Reference

You must be an Essbase Administrator to run a migration.

For Essbase Administration Server, if you ran Oracle's Hyperion Enterprise Performance Management System Configurator after installation and specified a Shared Services server and login, at that point, Essbase Administration Server is converted to EPM System security mode. You can view the Shared Services configuration information in the Essbase Administration Server properties window (Configuration tab). You can then choose to migrate Administration Services users to Shared Services.

  To migrate Administration Services users or to remigrate any Essbase users and groups that failed migration, use a tool:

Tool

Topic

Location

Administration Services

Migrating Users to Shared Services

Oracle Essbase Administration Services Online Help

MaxL

display user

display group

alter user

alter group

Oracle Essbase Technical Reference

You must be an Administration Services Administrator to migrate Administration Services users.

Note:

Before migrating users, groups, and applications to Shared Services, ensure that the NETDELAY and NETRETRYCOUNT configuration settings are high enough to allow the migration to complete. Set NETDELAY to at least 3 hours, possibly more, depending on the size of the security file. Return the settings to their original values after the migration is complete. Specify these settings in the client essbase.cfg file, which you place in the ARBORPATH/bin folder of the client computer from which you launch the migration. For example, if you use Administration Services Console to launch the migration, the client essbase.cfg file must be in the ARBORPATH/bin folder on the computer on which Essbase Administration Server is installed.

Essbase automatically creates a backup of the security file before and after migration (essbase.bak_preUPM and essbase.bak_postUPM). Oracle suggests that you manually back up these files to a safe location.

The Administration Services Essbase Server Properties window displays information on whether the server is in EPM System security mode.

Application and Database Migration

After you have migrated to Shared Services, a project is created for each Essbase Server that you migrate. The project contains a Shared Services application for each Essbase application on the migrated server. See Essbase Projects, Applications, and Databases in Shared Services.

User and Group Migration

When you migrate to Shared Services, all native Essbase users and groups that do not already exist in an external authentication directory are converted to native Shared Services users and groups in the native Shared Services user directory and are given equivalent roles. For example, a native Essbase Administrator (previously known as Supervisor) becomes a Shared Services user with the Essbase Administrator and the Provisioning Manager roles assigned, and a native Essbase user with Calc privileges on a database becomes a Shared Services user with the Calc role assigned on the application that contains the database. During migration, Administrators and Application Managers are automatically given the Provisioning Manager role for the appropriate applications.

Note:

When Essbase runs in EPM System security mode, the Essbase create/delete user privilege becomes obsolete. You must be an Essbase administrator to create/delete Essbase users and, additionally, you must be a Shared Services administrator to create/delete users in Shared Services.

Any externally authenticated users are registered with Shared Services but remain stored in their original authentication directory. If a user directory is not running, the entire migration fails.

Any disabled Essbase users or groups do not migrate.

An Essbase user name cannot exist as a group name in Shared Services. If it does, the Essbase user does not migrate.

In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels. During migration, if a user has different access levels for two databases in the same application, the user is given the more restrictive access level for both databases. In such cases, a warning is sent to the Administrator who ran the migration and the information is logged in the AccessModifiedUsers_n.txt file, which is located in the ARBORPATH/bin directory.

Users and groups are migrated in the following order:

  1. Applications that are registered with Shared Services

  2. Groups

  3. Users

If a migration fails, the status of the migration depends on the point at which it fails. For example, if the migration fails at step 1, then the total migration fails. If a migration fails at step 2, the result depends on the reason for failure. If a migration fails at step 3, when one or more users fails to migrate, then applications and groups may have been migrated.

Users and groups that fail migration are listed in the essbase.sec file, which is located in the ARBORPATH/bin directory.

When you use Administration Services Externalize Users Wizard to migrate Administration Services users or to remigrate Essbase users that previously failed to be migrated, migration errors are logged in the file that you specify in the wizard, as well as in the Essbase Server log (EPM_ORACLE_HOME/logs/essbase/essbase.log).

If a group fails migration, all users in the group fail migration; you must repair and migrate the group in order for the users to migrate successfully.

If a group exists in both Essbase and Shared Services, the following conditions apply:

  • Shared Services cannot contain two groups at different levels in the same hierarchy (an ancestor-child relationship) when the groups exist in Essbase (see Example 2). If it does, the entire migration process fails.

  • The Shared Services group cannot contain a user that does not exist in the Essbase group of the same name. If it does, the Essbase group, and all users in the group, do not migrate.

  • The Essbase group cannot contain a user that exists in Shared Services, unless the Shared Services user belongs to the Shared Services group of the same name. If it does, the Essbase group, and all users in the group, do not migrate.

The following examples highlight group migration considerations:

Example 1: The groups in this example migrate successfully from Essbase to Shared Services.

Essbase has groups named group 1 and group 2:

   group 1, group 2

Shared Services has two identical groups and also has a group 3, which contains group 1 and group 2:

       group 3
          |
   group 1, group 2

The groups migrate successfully because group 1 and group 2 are at the same level as each other in Shared Services and because Essbase does not have a group 3.

Note:

If group 3 has Administrator (previously known as Supervisor) access to the Essbase Server instance and Essbase group 1 and group 2 have user access, the resulting group 1 and group 2 in Shared Services will have Administrator access.

Example 2: The migration in this example fails because Shared Services contains group 1 and group 2 at different levels.

Essbase has groups named group 1 and group 2:

   group 1, group 2

Shared Services has group 1 and group 2, but group 1 contains group 2:

   group 1
       |
   group 2

Example 3: The migration in this example fails because Essbase contains group 1, group 2, and group 3 and Shared Services contains group 3 at a different level from group 1 and group 2.

Essbase has groups named group 1, group 2, and group 3:

   group 1, group 2, group 3

Shared Services has group 1 and group 2, but has a group 3, which contains group 1 and group 2:

       group 3
          |
   group 1, group 2

User and Group Identities

Essbase, when in EPM System security mode, now enables user and group names to be non unique, if you specify the user or group's provider directory or unique identity attribute.

In MaxL, user and group names can be specified as name@provider or as a unique identity attribute.

The provider is the name of a user directory, such as LDAP or Active Directory, where the external user or group is hosted. The unique identity attribute, or "identity," is a unique string assigned to every user and group. The identity enables Essbase to distinguish between users and groups with the same name across providers.

For more information, see the MaxL topics for USER-NAME and GROUP-NAME in the Oracle Essbase Technical Reference.

Note:

If a user or group name includes the @ character, you must specify the provider as well, or else Shared Services considers the @ character as a delimiter indicating a provider name. For example, if you want to log in user admin@msad which is on a Native Directory provider, you must specify 'admin@msad@Native Directory'.

Security Information Recovery in EPM System Security Mode

If a discrepancy occurs between the security information in Shared Services and the security information in the Essbase security file, the type of discrepancy determines whether Shared Services information or the Essbase security file information takes precedence.

See:

User and Group Information

Shared Services takes precedence for user and group information. User and group information can be restored using Shared Services and external user directory backup and recovery procedures. See the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.

Note:

When recovering user and group information, any associations to filters, calculation scripts, and application access type are lost if the Shared Services backup does not have that information. If the Essbase security backup file does not have that information, the filters and calc scripts themselves are lost (not just the associations to the users or groups).

Application Information

Essbase takes precedence for application and database information. If an application is deleted from Shared Services, the application is still available in Essbase. You must reregister the application with Shared Services. If an application is deleted in Essbase, it is automatically deleted from Shared Services.

  To reregister an application with Shared Services, use a tool:

Tool

Topic

Location

Administration Services

Reregistering an Application With Shared Services

Oracle Essbase Administration Services Online Help

MaxL

alter application

Oracle Essbase Technical Reference