HYPERION
RELEASE 9.3.1
SECURITY ADMINISTRATION GUIDE
P/N: DH09993100
Hyperion Security Administration Guide, 9.3.1
Copyright © 2005-2007, Oracle and/or its affiliates. All rights reserved.
Authors: James Chacko
The Programs (which include both the software and documentation) contain proprietary information; they are provided
under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and
other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except
to the extent required to obtain interoperability with other independently created software or as specified by law, is
prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the
documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be
expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the
United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to
U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the
applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication,
disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject
to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional
rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500
Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous
applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures
to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any
damages caused by such use of the Programs.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their
respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is
not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with
the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly
between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b)
fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty
obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you
may incur from dealing with any third party.
Contents
Chapter 1. About Hyperion Security ..................................................... 11
Security Components .................................................. 11
User Authentication ................................................... 11
Authentication Components .......................................... 11
Security API ................................................... 12
Native Directory ................................................ 12
User Directories ................................................ 12
User Authentication Scenarios ......................................... 12
Single Sign-on Directly to Hyperion Products ........................... 12
Single Sign-on from External Systems ................................ 13
Provisioning (Role-Based Authorization) .................................... 14
Roles ........................................................... 15
Global Roles ................................................... 16
Predefined Roles ................................................ 17
Aggregated Roles ............................................... 17
Users ........................................................... 17
Groups .......................................................... 17
Chapter 2. Setting Up Authentication .................................................... 19
Setting Up Direct Authentication to Hyperion Products ......................... 19
Creating Users on the User Directory .................................... 19
Creating Groups ................................................... 20
Migrating Users and Groups to Shared Services Security ...................... 20
Installing and Deploying Shared Services ................................. 20
Identifying User Directories to Shared Services ............................. 20
Setting Up SSO with SAP Enterprise Portal ................................... 21
Nested SAP Groups ................................................. 22
Inheritance Policy for Nested Groups .................................... 23
Deployment Locations .............................................. 23
Prerequisites ...................................................... 23
Setting Up SSO from SiteMinder .......................................... 25
Special Considerations .............................................. 26
Contents
iii
Configuring the SiteMinder Policy Server ................................. 27
Configuring the SiteMinder Web Agent .................................. 27
Enabling SiteMinder Authentication in Shared Services ....................... 27
Other Procedures .................................................. 28
Using NTLM to Support SSO ............................................ 28
NTLM with UNIX Application Environments ............................. 29
Support for Multiple NTLM Domains ................................... 29
Chapter 3. User Management Console ................................................... 33
Launching User Management Console ...................................... 33
Overview of User Management Console ..................................... 34
Navigating in User Management Console .................................... 34
Searching for Users, Groups, Roles, and Delegated Lists .......................... 34
Chapter 4. Configuring User Directories .................................................. 37
Operations Related to User Directory Configuration ............................ 37
Using the Unique Identity Attribute to Handle Inter-OU Moves in LDAP-Enabled User
Directories .......................................................... 38
Planning the Migration to the Unique Identity Attribute ...................... 38
Back Up Native Directory and Hyperion Product Repositories ............... 39
Migration Sequence ............................................. 39
Behavior During Migration ........................................ 39
Important Considerations When Using the Unique Identity Attribute ......... 39
Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories .......................................................... 40
Configuring an SAP Provider ............................................. 46
Configuring an NTLM User Directory ...................................... 49
Configuring Relational Databases as User Directories ........................... 50
Testing User Directory Connections ........................................ 53
Editing User Directory Settings ........................................... 53
Deleting User Directory Configurations ..................................... 54
Managing User Directory Search Order ..................................... 54
Adding a User Directory to the Search Order .............................. 55
Changing the Search Order ........................................... 56
Removing a Search Order Assignment ................................... 56
Setting Global Parameters ............................................... 57
Overriding Cache Refresh Interval for MSAD and other LDAP-Enabled User
Directories .......................................................... 58
Setting Timeout to Resolve SAP Keystore File ................................. 59
Connection Pooling ................................................... 59
Contents
iv
Using Special Characters ................................................ 61
Chapter 5. Working with Applications and Projects ........................................... 65
Overview ........................................................... 65
Working with Projects .................................................. 65
Creating Projects .................................................. 66
Modifying Project Properties .......................................... 67
Deleting Projects .................................................. 67
Managing Applications ................................................. 67
Assigning Access Permissions to Applications ............................. 68
Moving Applications ............................................... 69
Copying Provisioning Information Across Applications ...................... 69
Deleting an Application .............................................. 69
Chapter 6. Delegated User Management .................................................. 71
About Delegated User Management ........................................ 71
Hierarchy of Administrators ............................................. 71
Shared Services Administrators ........................................ 71
Delegated Administrators ............................................ 72
Enabling Delegated User Management Mode ................................. 72
Creating Delegated Administrators ........................................ 72
Planning Steps .................................................... 73
User Accounts for Delegated Administrators ........................... 73
Create a Delegation Plan .......................................... 73
Provisioning Delegated Administrators .................................. 73
Creating Delegated Lists ............................................. 73
Modifying Delegated Lists ............................................ 75
Deleting Delegated Lists ............................................. 77
Viewing Delegated Reports ........................................... 77
Chapter 7. Managing Native Directory .................................................... 79
About Native Directory ................................................. 79
Installation Location ................................................ 79
Default Users and Groups ............................................ 80
Starting Native Directory ............................................. 80
Starting Native Directory in Normal Mode ............................. 80
Starting Native Directory in Debug Mode .............................. 80
Stopping Native Directory ......................................... 81
Managing Native Directory Users ......................................... 81
Creating Users .................................................... 81
Contents
v
Modifying User Accounts ............................................ 82
Deactivating User Accounts ........................................... 83
Activating Inactive User Accounts ...................................... 84
Deleting User Accounts ............................................. 84
Managing Native Directory Groups ........................................ 84
Creating Groups ................................................... 85
Modifying Groups ................................................. 86
Deleting Groups ................................................... 88
Managing Roles ...................................................... 88
Creating Aggregated Roles ............................................ 89
Modifying Aggregated Roles .......................................... 90
Deleting Aggregated Roles ............................................ 90
Changing Native Directory root User Password ............................... 91
Backing Up the Native Directory Database ................................... 91
Best Practices ..................................................... 91
Hot Backup ...................................................... 92
Cold Backup ...................................................... 92
Synchronizing Native Directory Database with the Shared Services Repository ......... 93
Recovering Native Directory Data ......................................... 93
Setting Up Native Directory for High Availability and Failover ..................... 94
Out of the Box Deployment ........................................... 94
Cold Standby Deployment ............................................ 96
Hot Standby Deployment ............................................ 98
Migrating Native Directory .............................................. 99
Chapter 8. Managing Provisioning ..................................................... 101
Provisioning Users and Groups .......................................... 101
Deprovisioning Users and Groups ........................................ 102
Generating Provisioning Reports ......................................... 102
Importing and Exporting Native Directory Data .............................. 103
Overview ....................................................... 104
Use Scenarios .................................................... 105
Move Provisioning Data Across Environments ......................... 105
Manage Users and Groups in Native Directory ......................... 105
Bulk Provision Users and Groups ................................... 105
Installing the Import/Export Utility .................................... 106
Before Starting Import/Export Operations ............................... 106
Sample importexport.properties File ................................... 106
Sequence of Operations ............................................. 107
Contents
vi
Preparing the Property File .......................................... 107
Product Codes ................................................... 111
Considerations for Setting Filters ...................................... 112
Prerequisites for Running Import/Export Utility from a Remote Host ........... 113
Running the Utility ................................................ 113
Import File format ................................................ 114
XML File Format .............................................. 114
CSV File Format ............................................... 118
Chapter 9. Using the Update Native Directory Utility to Clean Stale Native Directory Data ............... 125
About the Update Native Directory Utility .................................. 125
Installing the Update Native Directory Utility ................................ 126
Running the Update Native Directory Utility ................................ 126
Update Native Directory Utility Options ................................ 127
Update Native Directory Utility Log Files ................................ 128
Product-Specific Updates .............................................. 128
Essbase ......................................................... 129
Planning ....................................................... 129
Financial Management ............................................. 130
Reporting and Analysis ............................................. 131
Strategic Finance ................................................. 132
Chapter 10. Troubleshooting ......................................................... 133
Shared Services Log Files ............................................... 133
User Directory Error Codes ............................................. 134
Troubleshooting Tools and Utilities ....................................... 134
CSSSpy ........................................................ 134
WebDAV Browser ................................................ 134
Appendix A. Hyperion Product Roles .................................................... 135
Shared Services Roles ................................................. 135
Essbase Roles ....................................................... 137
Reporting and Analysis Roles ............................................ 137
Financial Management Roles ............................................ 139
Planning Roles ...................................................... 141
Business Rules Roles .................................................. 142
Business Modeling Roles ............................................... 143
Strategic Finance Roles ................................................ 143
Transaction Manager Roles ............................................. 144
Performance Scorecard Roles ............................................ 144
Contents
vii
Strategic Finance Roles ................................................ 144
Data Integration Management Roles ...................................... 145
Essbase Provider Services Roles .......................................... 145
Appendix B. Shared Services Roles and Permitted Tasks ...................................... 147
Appendix C. Essbase User Provisioning .................................................. 149
Launching User Management Console from Essbase ........................... 149
Essbase Projects, Applications, and Databases in Shared Services .................. 150
Essbase Users and Groups in Shared Services ................................ 151
Assigning Database Calculation and Filter Access ............................. 151
Setting Application Access Type .......................................... 153
Synchronizing Security Information Between Shared Services and Essbase ........... 154
Migrating Essbase Users to Shared Services Security ........................... 155
Backing Up Security Information ......................................... 155
Appendix D. Reporting and Analysis User Provisioning ....................................... 157
Launching User Management Console from Workspace ........................ 157
Reporting and Analysis Roles ............................................ 157
Reporting and Analysis Role Hierarchy .................................... 157
Content Manager Branch ........................................... 158
Scheduler Manager Branch .......................................... 158
Sample Role Combinations ............................................. 159
Appendix E. Financial Management User Provisioning ........................................ 161
Assigning Users and Groups to Financial Management Applications ............... 161
Assigning User Access to Security Classes ................................... 162
Setting Up E-mail Alerting ............................................. 163
Process Management Alerting ........................................ 164
Intercompany Transaction Alerting .................................... 165
Running Security Reports for Financial Management Applications ................. 165
Migrating Financial Management Users to Shared Services Security ................ 166
Appendix F. Planning User Provisioning .................................................. 167
Launching User Management Console From Planning ......................... 167
Returning to Planning From User Management Console ........................ 167
Updating Users and Groups in Planning .................................... 168
viii
Migrating User and Group Identities ................................... 168
Deprovisioning or Deleting Users and Groups ............................ 168
Updating Users With a Utility ........................................ 169
Roles in Planning .................................................... 170
Contents
Write Access to Data in Essbase ....................................... 170
Roles Between Planning and Business Rules .............................. 170
Access Permissions Between Planning and Essbase ......................... 170
About Connection Types and Planning .................................... 171
Migrating Users to Shared Services ........................................ 171
Appendix G. Business Rules User Provisioning ............................................. 173
About Business Rules Security ........................................... 173
Launching User Management Console ..................................... 174
Business Rules User Roles .............................................. 174
Migrating Business Rules Users to Shared Services Security ...................... 175
Appendix H. Performance Scorecard User Provisioning ....................................... 177
Launching User Management Console from Performance Scorecard ............... 177
Managing Permissions in Performance Scorecard .......................... 178
Creating and Provisioning Users and Groups over Shared Services ................. 178
Access Permissions ................................................ 179
Before You Begin ................................................. 179
Creating a New User or Group Using Shared Services ....................... 179
Assign Performance Scorecard Properties Individually ...................... 180
Assign Bulk Properties in Performance Scorecard .......................... 181
Migrating Performance Scorecard Users and Groups to Shared Services Security ...... 182
Appendix I. Business Modeling Roles and Tasks ............................................ 189
Administrator ....................................................... 189
Builder ............................................................ 190
End User .......................................................... 190
Appendix J. Essbase Provider Services User Provisioning ...................................... 191
Provisioning the Administrator Role in Shared Services ......................... 191
Migrating Analytic Provider Services Users to Shared Services .................... 192
Appendix K. Data Integration Management User Provisioning .................................. 193
Authentication Methods ............................................... 193
Data Integration Management User Roles ................................... 194
Glossary ........................................................... 195
Index ............................................................. 199
Contents
ix
Contents
x
1
In This Chapter
Security Components..............................................................................................................11
User Authentication................................................................................................................11
Provisioning (Role-Based Authorization).........................................................................................14
Security Components
Hyperion application security comprises two distinct and complementary layers that control
user access and permissions:
● “User Authentication” on page 11
● “Provisioning (Role-Based Authorization)” on page 14
About Hyperion Security
User Authentication
User authentication enables single sign-on functionality across Hyperion products by validating
the login information of each user to determine authenticated users. User authentication, along
with product-specific authorization, grants the user access to Hyperion products. Authorization
is granted through provisioning.
Single sign-on (SSO) is a session and user authentication process that permits a Hyperion
product user to enter credentials only once at the beginning of a session to access multiple
Hyperion products. SSO, which is requested at session initiation, eliminates the need to log in
separately to each Hyperion product to which the user has access.
Authentication Components
These components are used to support SSO:
● “Security API” on page 12
● “Native Directory” on page 12
● “User Directories” on page 12
Security Components
11
Security API
The Security Application Programming Interface (Security API) is the main interface to validate
users and interpret user access to Hyperion products. It is a Java API that enables Hyperion
products to authenticate users against user directories configured in Oracle's Hyperion® Shared
Services. It also allows integration with a security agents such as Netegrity SiteMinder, and
retrieval of users and groups based on names and identities. Each Hyperion application
implements the Security API to support user authentication.
Native Directory
Native Directory (OpenLDAP), an open source Lightweight Directory Access Protocol (LDAP)enabled user directory, is bundled and configured with Shared Services.
Native Directory functions:
● Used to maintain and manage the default Shared Services user accounts required by
Hyperion products
● Is the central storage for all Hyperion provisioning information because it stores the
relationships between users, groups, and roles.
Native Directory is accessed and managed using the User Management Console. Refer
toChapter 7, “Managing Native Directory” for more information on provisioning users.
User Directories
User directories refer to any corporate user and identity management system compatible with
Shared Services. Hyperion products are supported on a large number of user directories. These
include LDAP-enabled user directories, such as Sun Java System Directory Server (formerly
SunONE Directory Server) and Microsoft Active Directory, Windows NT LAN Manager
(NTLM); SAP Provider; and custom-built user directories that support LDAP version 3.
In addition to Native Directory, which is automatically configured for your environment, one
or more user directories can be configured as the user information provider for Hyperion
products.
User directories used with Hyperion products must contain an account for each user who
accesses Hyperion products. These users may be assigned to groups to facilitate provisioning.
User Authentication Scenarios
● “Single Sign-on Directly to Hyperion Products” on page 12
● “Single Sign-on from External Systems” on page 13
Single Sign-on Directly to Hyperion Products
About Hyperion Security
12
Direct authentication connects Hyperion products to available user directories to verify the user
name and password (credentials) entered on the Login screen.
1. Using a browser, users access the Hyperion product login screen. They enter user names
and passwords.
The Security API implemented on the Hyperion product queries the configured user
directories (including Native Directory) to verify user credentials. A search order is used to
establish the search sequence. On finding a matching user account in a user directory, the
search is terminated and the user's information is returned to the Hyperion product.
Access to Hyperion product is denied if a user account is not found in any of the user
directories.
2. Using the retrieved user information, the Hyperion product queries Shared Services to
obtain provisioning details for the user. Provisioning details are stored in Native Directory.
On receiving provisioning information from Shared Services, the appropriate Hyperion product
is made available to the user. At this point, SSO is enabled for all Hyperion products for which
that user is provisioned. Access permissions within Hyperion products are determined by the
provisioning information.
Single Sign-on from External Systems
Hyperion products can be configured to accept pre-authenticated users from external sources,
such as Netegrity SiteMinder and SAP Enterprise Portal, to enable SSO. In this scenario,
Hyperion products use the user information provided by a trusted external source to determine
access permissions of users.
SSO with SAP is supported by accepting an SAP logon ticket. In this scenario, users defined in
an SAP user directory can navigate between the SAP Portal and Hyperion products. If an SAP
provider is configured, users can also directly log on to Hyperion products using the user ID
and password stored in the SAP system. The SAP provider creates the SAP logon ticket to enable
SSO with SAP systems.
User Authentication
13
1. Using a browser, users access the login screen of a web identity management solution (for
example, SiteMinder) or SAP Enterprise Portal. They enter user names and passwords,
which are validated against configured user directories to verify user authenticity. Hyperion
products are also configured to work with these user directories.
When users navigate to a Hyperion product, information about the authenticated user is
passed to Hyperion product, which accepts the information as valid.
If the user logged on to SAP Portal, an SAP logon ticket is passed to Hyperion product. The
Security API implemented on Hyperion product decrypts the SAP logon ticket using a
specified SAP certificate.
If the user logged on to a web identity management solution, a custom
header is passed to Hyperion product.
2. To verify user credentials, Hyperion product tries to locate the user in one of the user
directories based on the search order. If a matching user account is found, user information
is returned to Hyperion product.
3. Using the retrieved user information, Hyperion product queries Shared Services to obtain
provisioning details for the user.
On receiving user provisioning information from Shared Services, the Hyperion product is
made available to the user. SSO is then enabled for all Hyperion products for which that
user is provisioned.
Provisioning (Role-Based Authorization)
Hyperion application security determines user access to products using the concept of roles. A
role is a set of permissions that determines user access to product functions.
Each Hyperion product provides several default roles tailored to suit various business needs.
Predefined roles from each Hyperion application registered with Shared Services are available
from User Management Console. These roles are used for provisioning. You may also create
additional roles that aggregate the default roles to suit specific requirements. The process of
HYPLOGIN HTTP
About Hyperion Security
14
granting users and groups specific access permissions to Hyperion resources is called
provisioning.
Native Directory and configured user directories are sources for user and group information for
the provisioning (authorization) process. You can browse and provision users and groups from
all configured user directories from User Management Console. Provisioning data is stored in
Native Directory. You can also use application-specific aggregated roles created in Native
Directory in the provisioning process.
This illustration depicts a broad overview of the authorization process:
1. After a user is authenticated, Hyperion product queries the user directories to determine
the user's groups.
2. Hyperion product uses the group and user information to retrieve the user's provisioning
data from Shared Services. The product uses this data to determine resources that a user can
access.
Product-specific provisioning tasks, such as setting product-specific access control, are
completed from each product. This data is combined with provisioning data to determine
the product access for users.
Role-based provisioning of Hyperion products uses these concepts.
Roles
A role is a construct (similar to access control list) that defines the access permissions granted
to users and groups to perform functions on Hyperion resources. It is a combination of resource
or resource types (what users can access; for example, a report) and actions that users can perform
on the resource (for example, view and edit).
Access to Hyperion application resources is restricted; users can access them only after a role
that provides access is assigned to the user or to the group to which the user belongs. Access
restrictions based on roles enable administrators to control and manage application access.
Provisioning (Role-Based Authorization)
15
Global Roles
Global roles are Shared Services roles that enable users to perform certain tasks within the User
Management Console. See Appendix B, “Shared Services Roles and Permitted Tasks” for a
complete list of Shared Services global roles.
Administrator
The Administrator role provides control over all products that integrate with Shared Services.
It enables more control over security than any other Hyperion product roles and should therefore
be assigned sparingly. Administrators can perform all administrative tasks in User Management
Console and can provision themselves.
This role grants broad access to all applications registered with Shared Services. The
Administrator role is, by default, assigned to the admin Native Directory user, which is the only
user available after you deploy Shared Services. This user account is initially used to create
accounts for other administrators. For example, the Shared Services Administrator assigns other
administrative users either the Directory Manager or Provisioning Manager role (a productspecific role assigned for individual applications). In turn, these users manage general user access
to applications.
Directory Manager
Users who are assigned the Directory Manager role can create and manage users and groups
within Native Directory.
Do not assign to Directory Managers the Provisioning Manager role because combining these
roles allows Directory Managers to provision themselves. If a user is assigned the Provisioning
Manager role for an Oracle's Hyperion® Essbase® – System 9 application as well as the Directory
Manager role, this user can create a new user, assign the user any role within the Essbase
application, and log in as the new user, thereby granting personal access to the Essbase
application.
The recommended practice is to grant one user the Directory Manager role and another user
the Provisioning Manager role.
Project Manager
Users who are assigned the Project Manager role can create and manage projects within Shared
Services.
LCM Manager
Users who are assigned the LCM Manager role can execute the Artifact Life Cycle Management
Utility to promote artifacts and data across product environments and operating systems.
About Hyperion Security
16
Predefined Roles
Predefined roles are built-in roles in Hyperion products. You cannot delete these roles from the
product. Predefined roles are registered with Shared Services during the application registration
process.
Aggregated Roles
Aggregated roles are custom roles that aggregate multiple product roles within a Hyperion
product. An aggregated role consists of multiple roles, including other aggregated roles. For
example, a Shared Services Administrator or Provisioning Manager can create a role for Planning
that combines the Planner and View User roles into an aggregated role. Aggregating roles can
simplify the administration of products that have a large number of granular roles.
You cannot create an aggregated role that spans products, and you cannot include global Shared
Services roles in aggregated roles. Aggregated roles are also known as custom roles.
Users
User directories store information about the users who can access Hyperion products. Both the
authentication and the authorization processes utilize user information. You can only create
and manage Native Directory users from User Management Console.
Users from all configured user directories are visible from User Management Console. These
users can be individually provisioned to grant access rights on the Hyperion products registered
with Shared Services. Hyperion does not recommend the provisioning of individual users.
Groups
Groups are containers for users or other groups. You can create and manage Native Directory
groups from User Management Console. Groups from all configured user directories are
displayed in User Management Console. You can provision these groups to grant permissions
for Hyperion products registered with Shared Services.
Provisioning (Role-Based Authorization)
17
About Hyperion Security
18
Setting Up Authentication
2
In This Chapter
Setting Up Direct Authentication to Hyperion Products ........................................................................19
Setting Up SSO with SAP Enterprise Portal......................................................................................21
Setting Up SSO from SiteMinder .................................................................................................25
Using NTLM to Support SSO ......................................................................................................28
Setting Up Direct Authentication to Hyperion Products
The security environment of Hyperion products comprises two complementary layers:
authentication and authorization.
Setting up Hyperion security to authenticate users directly involves several broad procedures.
See details in later sections.
● “Creating Users on the User Directory” on page 19
● “Creating Groups” on page 20
● “Migrating Users and Groups to Shared Services Security” on page 20
● “Installing and Deploying Shared Services” on page 20
● “Identifying User Directories to Shared Services” on page 20
Creating Users on the User Directory
The security environment of Hyperion products requires that user credentials be checked against
a user directory as a part of the authentication process. This requirement mandates that each
Hyperion application user have an account on the user directory. A unique user identifier
(typically the user name) defined on the user directory is the foundation on which Hyperion
application security is built.
In most deployment scenarios, existing user directories (with user accounts) are used to support
user authentication. For information on creating user accounts, see vendor documentation. See
“Creating Users” on page 81 for information on creating Native Directory users.
Setting Up Direct Authentication to Hyperion Products
19
Creating Groups
User accounts on user directories can be granted membership to groups based on common
characteristics such as the user function and geographical location. For example, users can be
categorized into groups such as Staff, Managers, Sales, and Western_Sales based on their function
within the organization. A user can belong to one or more groups on the user directory, which
is an important consideration in facilitating the provisioning process.
The procedures to create groups and assign group membership vary depending on the user
directory being used. For information on creating groups and assigning group membership, see
vendor documentation. See “Managing Native Directory Groups” on page 84 for information
on creating Native Directory groups.
Migrating Users and Groups to Shared Services Security
If you are upgrading Hyperion products from a release that did not support provisioning, you
must migrate users and groups from the products to Shared Services. You can migrate users who
were authenticated through native product security or through an external directory in that
release. Each product has a migration tool that enables you to migrate user, group, and role
information from Hyperion products to Shared Services. For migration information, see the
appropriate product appendix at the end of this guide.
After migrating users, you can provision users or groups as needed. See Chapter 8, “Managing
Provisioning” for details.
Installing and Deploying Shared Services
See Hyperion Shared Services Installation Guide for information about installing Shared Services
and deploying it to an appropriate application server.
Identifying User Directories to Shared Services
The Shared Services installation and deployment process sets up and configures Native Directory
as the default user directory for Hyperion products. Each additional user directory that you use
to support user authentication and SSO must be configured separately using User Management
Console.
During the user directory configuration process, you assign the search order for each user
directory. This order determines the sequence in which the authentication process searches
within configured user directories to locate the user account that matches the user login
credentials. By default, Hyperion application security is configured to terminate the search
process when a matching user account is found. If you are using multiple user directories,
Hyperion recommends that user accounts be normalized across user directories.
Setting Up Authentication
20
Information on configuring user directories:
● “Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
● “Configuring an SAP Provider” on page 46
● “Configuring an NTLM User Directory” on page 49
Setting Up SSO with SAP Enterprise Portal
Hyperion products handle SSO to SAP Enterprise Portal by issuing an SAP logon ticket. This
action enables users who log in to Hyperion products to navigate seamlessly to SAP applications.
The illustrated concept:
1. When a user logs in to Hyperion products, the Security API implemented on the product
authenticates the user against configured user directories, including Native Directory.
Hyperion pr oduct iss ues a Hype rion logon token, w hich enable s SSO to Hy perion pro ducts.
The Hyperion logon token contains an SAP logon ticket.
Note:
For SSO with SAP to work, you must configure SAP as valid provider on Shared Services.
2. When the user subsequently navigates to the SAP system or uses an SAP data source, the
SAP logon ticket contained in the Hyperion token is passed to SAP to enable SSO. At this
point, the SAP system assumes the responsibility to validate the credentials in the SAP logon
ticket.
Hyperion products handle SSO from SAP Enterprise Portal by accepting an SAP logon ticket.
This action enables users who log in to SAP Enterprise Portal to navigate seamlessly between
SAP and Hyperion products. The illustrated concept:
Setting Up SSO with SAP Enterprise Portal
21
1. When a user logs in to SAP Enterprise Portal, SAP authenticates the user against the SAP
provider and issues an SAP logon ticket. SSO to SAP is enabled at this time.
2. The user navigates to a Hyperion product. The SAP logon ticket is passed to the Hyperion
product, which decrypts the SAP logon ticket using a SAP certificate stored on the Shared
Services server machine to retrieve the user name.
3. Accepting the user name, retrieved from the SAP ticket, as a valid, the Hyperion product
queries user directories to determine the user's groups. The SAP provider must be configured
as a user directory in Shared Services for this process to work.
4. Using the group information, Hyperion product gets the provisioning information for the
user from Shared Services.
Assumptions in both scenarios:
● If using a non-SAP corporate directory, the corporate user directory used by SAP Enterprise
Portal is supported by Shared Services. See Hyperion Installation Start Here for a list of
supported user directories.
● Users accounts and groups are already defined on the corporate user directory.
● The corporate user directories are configured to work with Shared Services.
● Users and groups are provisioned to access Hyperion products.
Setting Up Authentication
22
Nested SAP Groups
After configuring an SAP user directory, available SAP users and groups are displayed in User
Management Console. Shared Services considers the SAP roles to be the equivalents of groups
created by any corporate directory server. Each role from the SAP user directory is displayed as
a distinct group in User Management Console. Shared Services, however, does not retrieve the
relationships that exist between simple and composite roles within the SAP user directory. If
needed, nested groups can be created in Native Directory to mimic the relationship that existed
between the simple and composite roles in the SAP user directory.
Inheritance Policy for Nested Groups
If you use nested groups from Native Directory to mimic nested SAP groups for provisioning,
the component groups inherit the roles assigned to the nested group. The illustrated concept:
In addition to the roles assigned directly to it, each component role (for example, Group2)
inherits all the roles assigned to the nested group (Role8 and Role9 in the illustration). For
example, the role assi gnment of Grou p1 in the ill ustratio n is Role1, Role 8, and Role9. T he nested
group does not inherit the groups assigned to component groups.
Deployment Locations
Deployment location conventions:
● <
Hyperion_Home
> denotes the root directory where Hyperion products are installed. The
location of this directory is specified during the installation process. For example:
C:\Hyperion (Windows)
/vol1/Hyperion (UNIX)
● <
HSS_Home
C:\Hyperion\deployments\<
/vol1/Hyperion/deployments/<
> denotes the Shared Services root directory. For example:
App_Server_Name
App_Server_Name
>\SharedServices9 (Windows)
>/SharedServices9 (UNIX)
Prerequisites
● All SAP systems within the SAP landscape must be set up for single sign-on with the SAP
login ticket. User names must be normalized across the SAP landscape so that a user name
in one SAP system refers to the same user across all SAP systems. See the SAP documentation
for more information.
● Copy or download the SAP JCo binaries (.dll files for Windows and shared libraries for
UNIX) into
<Hyperion_Home>
/common/SAP/bin directory. For example:
/vol1/Hyperion/common/SAP/bin(UNIX)
C:\Hyperion\common\SAP\bin (Windows).
These binaries are available in your SAP distribution. Registered SAP users may also
download them from the SAP Web site
https://service.sap.com/connectors.
Setting Up SSO with SAP Enterprise Portal
23
● Copy or download the SAP JCo archives (.jar files) into
SAP/lib
directory. For example:
<Hyperion_Home>
/vol1/Hyperion/common/SAP/lib (UNIX)
C:\Hyperion\common\SAP\lib (Windows)
These binaries are available in your SAP distribution. Registered SAP users may also
download them from the SAP Web site
https://service.sap.com/connectors.
/common/
● Copy or download the following SAP libraries into
lib
directory. For example,
<Hyperion_Home>
/common/SAP/
/vol1/Hyperion/common/SAP/lib (UNIX)
C:\Hyperion\common\SAP\lib (Windows)
These libraries are required to verify the SAP SSO logon ticket provided to Hyperion
products. You can extract these libraries from the file system of any SAP J2EE Engine 6.30
or later release. Or extract them from Enterprise Portal EP60 SP2 or later by searching
through the SDA files containing libraries. This step is required only if Hyperion products
are plugged into SAP Enterprise Portal.
❍ com.sap.security.core.jar
❍ com.sap.security.api.jar
❍ sapjco.jar
❍ sap.logging.jar
❍ iaik_jce.jar
❍ iaik_jce_export.jar (if using the export version of the IAIK-JCE libraries)
● Expand the contents of each of the SAP jar files by running the explodejar.bat
(Windows) or explodejar.sh (UNIX) file available in the
SAP/lib
directory.
<Hyperion_Home>
/common/
Setting Up Authentication
24
● Using User Management Console, configure the SAP provider for Shared Services. See
“Configuring an SAP Provider” on page 46 for detailed information.
● If you are providing SSO to Hyperion products from SAP Enterprise Portal, install the SAP
Digital Certificate (SAP X509 certificate) in a convenient location. Hyperion recommends
that this certificate be installed in the following directory where the
<HSS_Home>/config. For Example:
C:\Hyperion\deployments\WebLogic9\SharedServices9\config (Windows)
/vol1/Hyperion/deployments/WebLogic9/SharedServices9/config (UNIX)
● Using User Management Console, provision SAP users and groups to provide them
CSS.xml file is stored:
appropriate access rights to Hyperion products. See Chapter 8, “Managing Provisioning”
for detailed information.
Setting Up SSO from SiteMinder
Hyperion products can be integrated with Web access management solutions such as Netegrity
SiteMinder to provide SSO to Hyperion products. Where SSO from SiteMinder is accepted,
Hyperion products trust the authentication information sent by SiteMinder regarding the
protected resources on the user directory. The illustrated concept:
1. When a user logs in to SiteMinder to access Hyperion products, SiteMinder presents a login
screen. SiteMinder forwards the user credentials to the SiteMinder Policy Server, which
authenticates users against configured user directories.
2. If the user is authenticated, the SiteMinder Policy Server grants access to Hyperion products
and passes a SiteMinder token that has
HYPLOGIN is configured to SM_USERLOGINNAME parameter in SiteMinder.
Note:
In SiteMinder Version 6, configure HYPLOGIN to use SMUSER parameter. HYPLOGIN is a
header that you must create to support SiteMinder integration with Hyperion products. See
SiteMinder documentation for information on configuring
carry the user name of the authenticated user.
3. The Security API implemented on the Hyperion product parses the
and validates the user against the user directories configured on Shared Services.
4. Hyperion product checks Shared Services for the user's provisioning information. Based on
the provisioning information, the Hyperion product provides access to the user.
To enable SSO, SiteMinder and Shared Services must be configured to use the same set of user
directories. Also, the user directories configured in Shared Services must be set up to support
security agent for single sign on. See “Setting Global Parameters” on page 57 for details.
The SiteMinder–enabled SSO, general overview:
HYPLOGIN HTTP header appended to it.
HYPLOGIN HTTP header to
HYPLOGIN HTTP header
Setting Up SSO from SiteMinder
25
The following SiteMinder security agents are tested and supported for SSO with Hyperion
products:
● SiteMinder Policy Server 5.5 SP 2
● SiteMinder Web Agent 5.5 SP 2
Note:
The corporate user directories configured with Shared Services must be trusted when SSO from
SiteMinder is enabled. This is because Shared Services does not store a password in the token
when a security agent is used.
Special Considerations
SiteMinder is a Web only solution. Desktop applications and their addins (for example,
Microsoft Excel and Report Designer) cannot use authentication through SiteMinder.
Hyperion products are supported only on NTLM and LDAP-enabled user directories (including
MSAD).
Setting Up Authentication
26
Configuring the SiteMinder Policy Server
A SiteMinder administrator must configure the policy server to enable SSO to Hyperion
products.
The configuration process:
● Setting up protection for the Web resources of Hyperion products.
● Configuring a response that adds a custom HTTP header to make the user login name
available to Hyperion applications. The header must include the parameter
HYPLOGIN and
must contain the login name of the authenticated user.
See the “Responses and Response Groups” topic in the Netegrity Policy Design Guide for detailed
information. For example, if you use
attribute in the configuration file, the
cn from an LDAP–enabled user directory as the login name
HYPLOGIN parameter should carry the value of the cn
attribute, which is the login name of the authenticated user. SiteMinder administrators can also
configure the header to
SM_USERLOGINNAME (SMUSER for SiteMinder version 6), the user name
specified by the user during logon.
Configuring the SiteMinder Web Agent
The Web agent is installed on a Web server that intercepts requests for Hyperion application
Web resources, such as JSPs, ASPs, and HTML files on the application server. If these Web
resources are protected, the Web agent issues a challenge to unauthenticated users. When a user
is authenticated, the policy server adds
authenticated user. Thereafter, the HTTP request is passed on to the Web resources of the
Hyperion application, and the login name is extracted from headers.
HYPLOGIN, which carries the login name of the
SiteMinder supports SSO across Hyperion products running on heterogeneous Web server
platforms. If Hyperion products use different Web servers, you must ensure that the SiteMinder
cookie can be passed among Web servers within the same domain. You do this by specifying the
appropriate Hyperion application domain as the value of the
WebAgent.conf file of each Web server.
Cookiedomain property in the
See the “Configuring Web Agents” chapter in the Netegrity SiteMinder Agent Guide.
Note:
Because Shared Services uses basic authentication to protect its content, the Web server that
intercepts requests to Shared Services should enable basic authentication to support SSO with
SiteMinder.
Enabling SiteMinder Authentication in Shared Services
Integration with SiteMinder requires that you enable SiteMinder Authentication in Shared
Services. This can be done from User Management Console or by editing the
<
file is located in
C:\Hyperion\deployments\WebLogic9\SharedServices9\config (Windows)
HSS_Home
>/config. For example:
CSS.xml file. This
Setting Up SSO from SiteMinder
27
/vol1/Hyperion/deployments/WebLogic9/SharedServices9/config (UNIX)
➤ To enable SiteMinder authentication:
1 In Shared Services, configure the user directories that SiteMinder use to authenticate users. See the following
topics:
● “Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
● “Configuring an NTLM User Directory” on page 49
2 Select the Support for Security Agent for Single Sign-oncheck box to specify that the user directories are
used to support SSO from security agents such as SiteMinder. See “Setting Global Parameters” on page
57.
Other Procedures
You must perform these tasks, if not already completed:
● Using User Management Console, configure the corporate directories used by SiteMinder.
See Chapter 4, “Configuring User Directories.”
● Using User Management Console, provision the users and groups to grant appropriate
access to Hyperion products. See Chapter 8, “Managing Provisioning.”
Using NTLM to Support SSO
Shared Services allows you to configure Windows NT LAN Manager (NTLM) as a user directory
to support SSO. Refer to “Configuring an NTLM User Directory” on page 49 for information
on configuring the NTLM user directory.
Under these conditions, you must perform prerequisite steps to support SSO using NTLM:
● NTLM user directory is to be used to authenticate and provision users where Shared Services
and Hyperion products are running in a UNIX environment. In this scenario, Hyperion
Remote Authentication Module must be deployed on the Windows domain that contains
the user accounts.
● Shared Services and Hyperion products are running in a Windows environment, but users
are in Windows NTLM domains that are not trusted on the domain where the Shared
Services host machine is installed. The prerequisite for this scenario is that you deploy
Hyperion Remote Authentication Module on each domain that is not trusted by the domain
where Shared Services host machine is installed.
Do not implement Hyperion Remote Authentication Module if all users belong to the NTLM
domain where the Shared Services host machine is installed or if a trust relationship is established
between the domain where the Shared Services host machine is installed and the NTLM domains
to which users belong.
Setting Up Authentication
28
NTLM with UNIX Application Environments
The following illustration depicts how the Hyperion Remote Authentication Module enables
communication between NTLM and Shared Services running in a UNIX environment.
The Shared Services configuration file (CSS.xml) resides on the application server, as do the
Hyperion application binaries. For NTLM connectivity, you also need NTLM support library
css-9_3_0.dll) on the machine that hosts Hyperion Remote Authentication Module in
file (
the NTLM domain.
The NTLM Primary Domain Controller and the Hyperion Remote Authentication Module can
be on a Windows 2000 or Windows 2003 server. Hyperion does not recommend, however, that
you combine the Hyperion Remote Authentication Module with the NTLM Primary Domain
Controller on the same server. The Hyperion Remote Authentication Module host machine
needs to be in the same domain as the NTLM Primary Domain Controller.
Support for Multiple NTLM Domains
Hyperion Remote Authentication Module enables a Hyperion product to authenticate users
belonging to other NTLM domains that are not trusted by the domain on which Shared Services
is installed.
The following illustration depicts how users spread across multiple NTLM domains can be given
access to Hyperion products deployed in a Windows environment:
Using NTLM to Support SSO
29
Without the Hyperion Remote Authentication Module, the only way to use multiple NTLM
domains for Hyperion products is to establish trust relationships between the Shared Services
host machine's domain and the NTLM domains where user accounts are available.
Setting Up Authentication
30
Each NTLM domain is configured separately on Shared Services as a user provider. See
“Configuring an NTLM User Directory” on page 49 for detailed procedures.
Using NTLM to Support SSO
31
Setting Up Authentication
32
User Management Console
3
In This Chapter
Launching User Management Console...........................................................................................33
Overview of User Management Console .........................................................................................34
Navigating in User Management Console .......................................................................................34
Searching for Users, Groups, Roles, and Delegated Lists......................................................................34
Launching User Management Console
Launch User Management Console using one of the following methods:
● Using a browser and connecting to the User Management Console URL
● On Windows, navigating Start > All Programs > Hyperion > Foundation
Services > User Management Console
● From a Hyperion product interface
➤ To launch User Management Console by connecting to a URL:
1 Using a browser, access the following URL:
http://<server_name>:<port_number>
In the URL,
that hosts Shared Services is running and
Services is using; for example,
Note:
Pop-up blockers may prevent User Management Console from opening.
2 On the Logon screen, type your user name and password.
Initially, the only user who can access User Management Console is admin (default password
admin is password).
for
3 Click Log On.
Note:
<server_name>
indicates the name of the computer where the application server
http://myserver:58080/interop.
/interop
<port_number>
indicates the server port that Shared
Valid SAP users may get a CSSAuthenticationException error message during log on if the
SAP account is locked. Contact your SAP Administrator to unlock the account.
Launching User Management Console
33
If you receive Java Virtual Machine (JVM) errors in User Management Console while using
Microsoft Internet Explorer, ensure that your Internet Explorer installation includes Microsoft
XML parser (MSXML) version 4. MSXML is bundled with Internet Explorer 6.0.
To verify that you have the correct MSXML, check that the following file exists:
c:\winnt\system32\msxml4.dll
If this file is missing, install Internet Explorer 6.0 or later.
Overview of User Management Console
User Management Console comprises an Object Palette and task tabs. When you log in for the
first time, the User Management Console displays the Object Palette and a Browse tab.
The Object Palette is a navigation frame where you can choose objects (such as, user directories,
users, groups, projects, and applications). Typically, the details of your current selection in the
Object Palette are displayed in the Browse tab. Additional task tabs open as needed depending
on the task that you perform; for example, a Report tab when you generate a report, or a
Configure tab when you configure a user directory.
Depending on the current configuration, User Management Console lists your existing objects
—user directories, projects, and unassigned applications—on the Object Palette. You can
expand these object listings to view details. For example, you may expand the User Directories
object to view a list of all currently configured user directories. You may also search configured
user directories for users and groups.
A context-sensitive menu, accessible by right-clicking an object, is associated with some objects
on the Object Palette.
Navigating in User Management Console
When performing actions on objects in the Object Palette, you can right-click an object to access
a context-sensitive menu. These menu options change dynamically, depending on what you
select. The commands displayed on the right-click menu are also available on a menu from the
menu bar. Buttons representing currently enabled menu options are displayed on the toolbar.
Note:
Because Native Directory is administered from User Management Console, some menu options
available in the context-sensitive menu for Native Directory are not available for other user
directories.
Searching for Users, Groups, Roles, and Delegated Lists
User Management Console enables searching for users and groups from configured user
directories and for application roles registered with Native Directory.
User Management Console
34
When searching for users in Native Directory, you can search for all users, active users, or inactive
users. Search boxes that are displayed on the Browse tab reflect the search context based on the
selection in the Object Palette.
➤ To search for users, groups, roles or delegated lists:
1 In the Object Palette, expand User Directories.
2 Expand the user directory to search. Roles are available only in Native Directory.
3 To search for users:
a. Right-click Users.
b. Select a search context (All, Active, or Inactive).
Appropriate search boxes are displayed on the Browse tab.
Note:
You can select a search context only if you are searching within Native Directory.
c. Enter the search string and click Search. Use an asterisk (*) as the wildcard in pattern
searches. Alternatively, click Show All to list all users.
A list of users is displayed on the Browse tab.
4 To search for groups or roles:
a. Select Groups or Roles.
Appropriate search boxes are displayed on the Browse tab.
Note:
Shared Services considers Oracle and SQL Server roles as the equivalents of groups in user
directories. Oracle roles can contain other roles creating a hierarchy of roles. Shared
Services does not display the relationships between database roles in the search results but
honors them during the provisioning process. SQL Server roles cannot be nested. Because
DB2 does not support roles, Shared Services does not display groups if you select a DB2
database provider.
b. For Name, type the Search string and click Search. Use an asterisk (*) as the wildcard in
pattern searches. Alternatively, click Show All to list all groups or roles.
A list of groups or roles is displayed on the Browse tab.
5 To search for delegated lists:
a. Select Delegated Lists.
Appropriate search boxes are displayed on the Browse tab.
b. For List Name, type the Search string and click Search. Use an asterisk (*) as the wildcard
in pattern searches. Alternatively, click Show All to list all lists.
A list of matching delegated lists is displayed on the Browse tab.
Searching for Users, Groups, Roles, and Delegated Lists
35
User Management Console
36
4
In This Chapter
Configuring User Directories
Operations Related to User Directory Configuration............................................................................37
Using the Unique Identity Attribute to Handle Inter-OU Moves in LDAP-Enabled User Directories.........................38
Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User Directories...................................40
Configuring an SAP Provider......................................................................................................46
Configuring an NTLM User Directory..............................................................................................49
Configuring Relational Databases as User Directories .........................................................................50
Testing User Directory Connections ..............................................................................................53
Editing User Directory Settings....................................................................................................53
Deleting User Directory Configurations...........................................................................................54
Managing User Directory Search Order ..........................................................................................54
Setting Global Parameters ........................................................................................................57
Overriding Cache Refresh Interval for MSAD and other LDAP-Enabled User Directories....................................58
Setting Timeout to Resolve SAP Keystore File...................................................................................59
Connection Pooling ................................................................................................................59
Using Special Characters..........................................................................................................61
Operations Related to User Directory Configuration
Native Directory is configured automatically when you install and deploy Shared Services. You
can configure external user directories to support SSO and authorization.
From User Management Console, you can perform several tasks related to configuring and
managing user directories. These topics provide instructions:
● Configuring user directories
❍ “Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
❍ “Configuring an SAP Provider” on page 46
❍ “Configuring an NTLM User Directory” on page 49
❍ “Configuring Relational Databases as User Directories” on page 50
● “Testing User Directory Connections” on page 53
● “Editing User Directory Settings” on page 53
Operations Related to User Directory Configuration
37
● “Deleting User Directory Configurations” on page 54
● “Managing User Directory Search Order” on page 54
● “Setting Global Parameters” on page 57
Using the Unique Identity Attribute to Handle Inter-OU Moves in LDAP-Enabled User Directories
Native Directory, the default user directory for Hyperion products, maintains a link to
provisioned users and groups defined in external user directories. When the following actions
take place in an LDAP-based user directory including MSAD, these links are broken, creating
stale data in Native Directory and causing loss of access to Hyperionapplications.
● Users and groups are moved across Organizational Units (OU).
● Multiple users or groups are assigned identical common name (CN).
● CN of provisioned users or groups are modified.
Shared Services resolves this issue by using a unique identity attribute that identifies user
directory users and groups without reference to the location of their accounts.
Caution!
Before migrating to the unique identity attribute, you must clean the stale data, if any, in Native
Directory by running the Update Native Directory Utility utility. See Chapter 9, “Using the
Update Native Directory Utility to Clean Stale Native Directory Data” for detailed information.
Support for inter-OU moves can be implemented while you configure LDAP-enabled user
directories (see “Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40).
Planning the Migration to the Unique Identity Attribute
You must migrate users and groups to the new unique identity attribute only if you face any of
the following scenarios in your MSAD or other LDAP-based user directories, which create
broken links and stale data in Native Directory.
● You moved users and groups across OUs.
● You have multiple users or groups with identical CN.
● You modified the CN of users or groups.
Configuring User Directories
38
Because migrating to the new unique identity attribute affects all Hyperion products, plan the
migration to minimize application downtime.
Back Up Native Directory and Hyperion Product Repositories
After migrating users and groups to use the new identity attribute, you cannot revert to the
previously used identity attribute. Before starting the migration, create backups of Native
Directory database and the Hyperion product databases that store user and group information.
● Native Directory repository
● Shared Services repository
● Essbase (security file)
● Oracle's Hyperion® Planning – System 9 repository
● Oracle's Hyperion® Financial Management – System 9 repository
● Oracle's Hyperion® Reporting and Analysis – System 9 repository
Migration Sequence
Before migrating to the unique identity attribute, run the Update Native Directory Utility if
Native Directorycontain stale data. See Chapter 9, “Using the Update Native Directory Utility
to Clean Stale Native Directory Data.”
Begin by migrating Shared Services users and groups to the unique identity attribute. If you use
Essbase and Planning, migrate Essbase users and groups, and then migrate Planning users and
groups.
You can migrate Financial Management and Reporting and Analysis users and groups anytime
after migrating Shared Services users and groups.
See “Product-Specific Updates” on page 128 for more information.
Behavior During Migration
After you migrate Shared Services users and groups to the unique identity attribute,Hyperion
products stop working until the user and group information contained in product-specific
repositories is updated to reflect the unique identity attribute.
Shared Services and Hyperion product migration to the unique identity attribute can take
considerable time, depending on the number of users and groups involved. Because Hyperion
products will not be available during this time, Hyperion recommends that you schedule in a
way that minimizes downtime.
Important Considerations When Using the Unique Identity Attribute
● The unique identity attribute can be set only for MSAD and other LDAP-enabled user
directories.
● For migration to work, all similar user directories configured on Shared Services must be
migrated to the new unique identity attribute. All MSAD user directory configurations must
be updated with the unique identity attribute before Shared Services can migrate MSAD
users and groups to the new attribute. Similarly, the configuration of all LDAP-enabled user
Using the Unique Identity Attribute to Handle Inter-OU Moves in LDAP-Enabled User Directories
39
directories other than MSAD (SunONE, IBM Directory Server, Novell eDirectory, and
custom user directories) must be updated to the new identity attribute before Shared Services
can migrate users and groups from these user directories to the new attribute.
For example, assume that three MSAD user directories are configured on Shared Services.
Two are configured to use the new identity attribute
configured to use the old identity attribute (
DN). In this scenario, users and groups are not
migrated until the third configuration also uses a unique attribute other than
● Reverse migration is not supported. After migrating to the new unique identity attribute,
you cannot return to the previous identity attribute (
ObjectGUID, and the third is
DN.
DN).
Hyperion recommends that you back up Native Directory database before migrating to the
new unique identity attribute. If you return to
DN as the identity attribute, you can restore
data from the backup.
● If your Release 9.2.x user directory configuration uses an attribute other than DN, you must
upgrade to Shared Services Release 9.3.1.
● Do not migrate to the unique identity attribute by using the Update Native Directory Utility
if you changed the attribute identified as
User Configuration screen or by editing
loginAttribute (using the Login field of the
CSS.xml). If you run the utility, provisioning data
of the users whose accounts are defined on the user directory for which the
loginAttribute is changed is deleted from Native Directory. You cannot recover the
deleted data; however, you can restore it from the latest backup.
Configuring Oracle Internet Directory, MSAD, and Other LDAPEnabled User Directories
Use the procedures in this section to configure any LDAP-enabled corporate user directory, such
as Oracle Internet Directory, MSAD, Sun Java System Directory Server, IBM Tivoli Directory
Server, or a custom user directory.
Note:
Existing Oracle Virtual Directories that are configured to use a database can be configured in
Shared Services as external LDAP providers.
➤ To configure Oracle Internet Directory, MSAD and other LDAP-enabled user directories:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
The Defined User Directories screen opens. This screen lists all user directories, including Native
Directory, that are already configured.
3 Click Add.
4 In Directory Type, select an option:
Configuring User Directories
40
● Lightweight Directory Access Protocol (LDAP) to configure an LDAP-enabled user
directory other than MSAD.
● Microsoft Active Directory (MSAD) to configure MSAD.
5 Click Next.
The Connection Information screen for the selected user directory type opens.
6 Enter the required parameters.
Table 1 Connection Information Screen
Label
Directory Server The user directory product you are using. Select Other if you are using an LDAP Version 2 (or
Name A descriptive name for the user directory. Used to identify a specific user directory if multiple user
Host Name Name of the server that hosts the user directory. Use the fully qualified domain name if the user
Description
later) product other than those listed.
The ID Attribute value changes to the recommended unique identity attribute for the selected
product.
Note: To configure an existing Oracle Virtual Directory that is configured with an underlying
database, choose
Example:
Other.
Oracle Internet Directory
directories are configured.
Example:
MY_OID
directory is to be used to support SSO from SiteMinder.
Example:
MyServer
Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User Directories
41
Label Description
Port The server port number where the user directory is running.
Example:
389
Base DN The distinguished name (DN) of the container in the user directory hierarchy where the search for
users and groups should begin. You can also use the Fetch DNs button to list available Base DNs
and then select the appropriate Base DN from the list.
See “Using Special Characters” on page 61 for restrictions on the use of special characters.
Hyperion recommends that you be as specific as possible while identifying the Base DN.
Example:
dc=example,dc=com
ID Attribute The attribute that carries the identity of the user. The recommended value of this attribute, which
must uniquely identify a user in the user directory, is automatically set for Oracle Internet Directory
orclguid, SunONE (nsuniqueid), IBM Directory Server (Ibm-entryUuid), Novell
eDirectory (
GUID), and MSAD (ObjectGUID). You may change the default value if necessary.
See “Important Considerations When Using the Unique Identity Attribute” on page 39.
Maximum Size Maximum number of results that a search can return.
For LDAP-enabled user directories other than MSAD, leave this blank to retrieve all users and
groups that meet the search criteria. The maximum size entered in this screen is constrained by
the user directory settings.
For MSAD, set this value to
0 to retrieve all users and groups that meet the search criteria.
SSL Enabled The check box that enables the use of Secure Socket Layer (SSL) for communication with this
user directory.
Anonymous Bind The check box to indicate that Shared Services can bind anonymously to the user directory to
search for users and groups. If this option is not selected, you must specify in the User DN an
account with sufficient access permissions to search the directory where user information is stored.
Oracle Internet Directory connections do not support anonymous binds.
Note: Hyperion recommends that you do not bind anonymously with the user directory.
Trusted The check box to indicate that this provider is a trusted source. User credentials from trusted
sources are not validated during SSO. If this option is not set, the user credentials are validated
every time the user requests SSO to a different Hyperion product.
User DN This box is disabled if the Anonymous bind option is selected.
The user account that Shared Services should use to establish a connection with the user directory.
Typically, for LDAP-enabled user directories other than MSAD, you use the Directory Manager
cn=Directory Manager for this purpose. For MSAD, you use the Security Account
account
Manager name (
sAMAccountName).
You may use other accounts that have sufficient access permissions to search the directory where
user information is stored. Notice that this account must have proxy right to authenticate as a
different user.
Special characters are not allowed in the User DN value. See “Using Special Characters” on page
61 for restrictions on the use of special characters.
Example:
● cn=Directory Manager (user directories other than MSAD)
● sAMAccountName=pturner (MSAD)
Configuring User Directories
42
Label Description
Append Base DN The check box for appending the base DN (the distinguished name of the node where the search
for users and groups could begin) to the specified value. Do not append Base DN to the Directory
Manager account.
This check box is disabled if the Anonymous bind option is selected.
Password Password of the account specified in the User DN box.
This box is disabled if the Anonymous bind option is selected.
Example:
UserDNpassword
7 Click Next.
The User Configuration screen for the selected user directory type opens. Shared Services uses
the properties set in this screen to create a filter that is used to search for users in the user directory.
Using this filter speeds the search.
Hyperion recommends that you use the Auto C onfigure area of the screen to retrieve the required
information.
Note:
Data entry in the User Configuration screen is optional. If you do not specify the settings for the
filter, Shared Services searches the entire directory structure to locate users. This may have
performance implications, especially if the user directory contains accounts for many users.
Caution!
If the user URL is not set for user directories that contain / (slash) or \ (backslash) in its node
names, the search for users and groups fails. For example, any operation to list the user or group
fails if the user URL is not specified for a user directory where users and groups exist in a node
such as
OU=child\ou,OU=parent/ou, or OU=child/ou,OU=parent\ou.
8 In the text box in the Auto Configure area, enter a unique user identifier.
Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User Directories
43
The user identifier must be expressed in the format <attribute>=<identifier>; for
example,
uid=jdoe.
Attributes of the user are displayed in the User Configuration area.
If you are configuring Oracle Internet Directory as a user directory, you cannot automatically
configure the filter because the root DSE of Oracle Internet Directory does not contain entries
in the Naming Contexts attribute. See Oracle documentation for detailed information.
Note:
You can manually enter required user attributes into text boxes in the User Configuration area.
Table 2 User Configuration Screen
Label
User RDN The Relative DN of the user. Each component of a DN is called an RDN and represents a branch in
Login The attribute that stores the login name of the user. Users use the value of this attribute as the User
First Name The attribute that stores the first name of the user.
Last Name The attribute that stores the last name of the user.
Email The attribute that stores the e-mail address of the user (optional)
Object Class Object classes of the user (the mandatory and optional attributes that can be associated with the
Description
the directory tree. The RDN of a user is generally the equivalent of the
See “Using Special Characters” on page 61 for restrictions on the use of special characters.
Example:
Name while logging into Hyperion products.
Example:
Example:
Example:
Example:
user). Shared Services uses the object classes listed in this screen in the search filter. Using these
object classes, Shared Services should find all users who should be provisioned.
ou=People
uid
givenName
sn
mail
uid or cn.
9 Click Next.
Configuring User Directories
44
You can manually add additional object classes if needed. To add an object class, type the object
class name into the Object class box and click Add.
Delete object classes by selecting the object class and clicking Remove.
Example:
person, organizationalPerson, inetorgperson
Note:
Data entry in the Group Configuration screen is optional. If you do not enter the group filter
settings, Shared Services searches the entire directory structure to locate groups. This process
can negatively affect performance, especially if the user directory contains many groups.
The Group Configuration screen for the selected user directory type opens. Shared Services uses
the properties set in this screen to create a filter to search for groups in the user directory. Using
this filter speeds the search.
10 Clear Support Groups if you do not plan to provision groups or if users are not categorized into groups on
the user directory. Deselecting this option disables the fields on this screen.
If you are supporting groups, Hyperion recommends that you use the Auto Configure area to
retrieve the required information.
If you are configuring Oracle Internet Directory as a user directory, you cannot automatically
configure the filter because the root DSE of Oracle Internet Directory does not contain entries
in the Naming Contexts attribute. See Oracle documentation for detailed information.
11 In the Auto Configure area, enter a unique group identifier and click Go.
The group identifier must be expressed in <attribute>=<identifier> format; for example,
cn=western_region.
Attributes of the group are displayed in the Group Configuration area.
Note:
You can manually enter required group attributes into text boxes in the Group Configuration
area.
Caution!
If the group URL is not set for user directories that contain / (slash) or \ (backslash) in its node
names, the search for users and groups fails. For example, any operation to list the user or group
fails if the group URL is not specified for a user directory in which users and groups exist in a
node such as
OU=child\ou,OU=parent/ou or OU=child/ou,OU=parent \ ou.
Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User Directories
45
Table 3 Group Configuration Screen
Label
Group RDN The Relative DN of the group. Each component of a DN is called an RDN and represents a branch
Group Filter An LDAP query that retrieves only the groups that are to be provisioned with Hyperion product roles.
Description
in the directory tree. This value, which is relative to the Base DN, is used as the group URL.
Specify a Group RDN that identifies the lowest user directory node where all the groups that you
plan to provision are available.
The Group RDN has a significant impact on login and search performance. Because it is the starting
point for all group searches, you must identify the lowest possible node within which all groups for
Hyperion products are available. To ensure optimum performance, the number of groups present
within the Group RDN should not exceed 10,000. If more groups are present, use an appropriate
group filter to retrieve only the groups you want to provision.
Note: Shared Services displays a warning if the number of available groups within the Group URL
exceeds 10,000.
See “Using Special Characters” on page 61 for restrictions on the use of special characters.
Example:
For example, the LDAP query
Hyp.
The group filter is used to limit the number of groups returned during a query. Group filters are
especially important if the node identified by the Group RDN contains groups that need not be
provisioned. Filters can be designed to exclude the groups that are not to be provisioned, thereby
improving performance.
ou=Groups
(cn=Hyp*) retrieves only groups whose names start with the prefix
Name Attribute The attribute that stores the name of the group.
Example:
Object class Object classes of the group (the mandatory and optional attributes that can be associated with the
group). Shared Services uses the object classes listed in this screen in the search filter. Using these
object classes, Shared Services should find all the groups associated with the user.
You can manually add additional object classes if needed. To add an object class, type the object
class name into the Object class text box and click Add.
To delete object classes, select the object class and click Remove.
Example:
cn
groupofuniquenames?uniquemember
12 Click Finish.
Shared Services saves the configuration and returns to the Defined User Directories screen, which
now lists the user directory that you configured.
13 Test the configuration. See “Testing User Directory Connections” on page 53.
14 Add the user directory to the search order used by Shared Services. See “Adding a User Directory to the
Search Order” on page 55 for details.
15 Specify global parameters if needed. See “Setting Global Parameters” on page 57 for details.
Configuring an SAP Provider
Before starting these procedures, meet all prerequisites in “Prerequisites” on page 23.
Configuring User Directories
46
By default, the timeout for resolving SAP keystore file is set to 10 seconds. After configuring an
SAP provider, you can manually edit the
CSS.xml file to set a different timeout. See “Setting
Timeout to Resolve SAP Keystore File” on page 59 for details.
➤ To configure an SAP provider:
1 Launch User Management Console. See “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
The Defined User Directories screen that lists all configured user directories, including Native
Directory, opens.
3 Click Add.
4 In the Directory Type screen, select SAP and click Next.
The SAP Connection Information screen opens.
5 In the SAP Connection Information screen, enter the appropriate configuration parameters.
Table 4 SAP Connection Information Screen
Label
Name A unique configuration name for the SAP provider. You use this name to identify
Description
the SAP provider in situations where multiple SAP providers are defined in Shared
Services.
Example:
MY_SAP_DIRECTORY
Configuring an SAP Provider
47
Label Description
SAP Server Name The host name (or the IP address) of the computer where the SAP Server is
running, or the SAP router address.
Example:
myserver
Client Number The client number of the SAP system to which you want to connect.
Example:
001
System Number The system number of the SAP System to which you want to connect.
Example:
00
User ID The user name that Shared Services should use to access SAP. This user must
have access permissions to use Remote Function Calls (RFC) to connect to SAP
and to access user, activity groups, and their relationship data.
Example:
my_sap_user
Password The password of the user identified in the User ID box.
Example:
my_sap_password
Max Entries The maximum entries that a query to the SAP provider can return.
Example:
100
Pool Size JCo connection pool size.
Example:
10
Pool Name A unique name for the connection pool that should be used to establish a link
between Shared Services and SAP.
Example:
HYPERION_SAP_POOL
Language Language for messages, for example error messages, from SAP. By default, this
is read from the system locale of the server hosting Shared Services.
Example:
EN
Location of SAP Digital Certificate The location of SAP X509 certificate. Hyperion products use this certificate to
parse the SAP login ticket and to extract the user ID needed to support SSO.
Required only if Hyperion products are plugged into SAP Enterprise Portal.
Example:
Hyperion/common/SAP/bin
C:\Hyperion\common\SAP\bin (Windows) or /app/
(UNIX).
SSL Enabled Check box that enables you to use Secure Socket Layer (SSL) to communicate
between Shared Services and the SAP provider.
Trusted Check box that enables you to specify that this provider is a trusted source. User
credentials from trusted sources are not validated during SSO. If you do not select
this option, user credentials are validated every time user requests SSO to a
different Hyperion product.
6 Click Save.
Shared Services saves the configuration and returns to the Defined User Directories screen, which
now lists the SAP provider that you configured.
Configuring User Directories
48
7 Test the SAP provider configuration. See “Testing User Directory Connections” on page 53.
8 Add the SAP provider to the search order used by Shared Services. See “Adding a User Directory to the
Search Order” on page 55 for details.
9 Specify global settings if needed. See “Setting Global Parameters” on page 57 for details.
Configuring an NTLM User Directory
Before starting these procedures, meet all the prerequisites in “Using NTLM to Support SSO”
on page 28.
➤ To configure an NTLM user directory:
1 Launch the User Management Console. See “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
The Defined User Directories screen that lists all the configured user directories, including Native
Directory, opens.
3 Click Add.
4 In Directory Type select NT LAN Manager (NTLM) and click Next.
The NTLM Connection Information screen opens.
5 Enter the required configuration parameters in the NTLM Connection Information screen.
Table 5 NTLM Connection Information Screen
Label
Name A unique configuration name for the NTLM user directory. You use this name to identify the directory
Description
in situations where multiple NTLM directories are configured with Shared Services.
Example:
MY_NTLM_DIRECTORY
Configuring an NTLM User Directory
49
Label Description
Domain The name of the NTLM domain. You may use the Fetch Domain button to retrieve the domain name.
If the domain is not specified, Shared Services, at run time, detects and uses all visible domains.
This may affect performance. The search order is: local computer, domain of local computer, and
trusted domains visible to the local computer.
Note: Because Shared Services does not detect domains when NTLM is used with Hyperion Remote
Authentication Module (HRAM), you must specify the domain if HRAM is used.
Example:
Trusted Check box to indicate that this provider is a trusted source. User credentials from trusted sources
are not validated during SSO. If this option is not selected, Hyperion products validate user
credentials every time the user switches between Hyperion products.
Maximum Size Maximum number of entries that a query to the NTLM user directory can return.
Example:
Hostname Name of the Windows server where HRAM is installed to support SSO to Hyperion products running
in a UNIX environment. Required only if Hyperion products are running in a UNIX environment.
Example:
Port The port number where HRAM is running.
Example:
MY_DOMAIN
100
MyHRAMServer
3891
6 Click Finish.
Shared Services saves the configuration and returns to the Defined User Directories screen, which
now lists the NTLM provider that you configured.
7 Test the configuration. See “Testing User Directory Connections” on page 53.
8 Add the user directory to the search order used by Shared Services. See “Adding a User Directory to the
Search Order” on page 55 for details.
9 Specify additional parameters, if needed, for the NTLM user directory. See “Setting Global Parameters” on
page 57 for details.
Configuring Relational Databases as User Directories
User and group information from the system tables of Oracle, SQL Server, and IBM DB2
relational databases can be used to support provisioning. If group information cannot be derived
from the database's system schema, Shared Services does not support the provisioning of groups
from that database provider. For example, Shared Services cannot extract group information
from IBM DB2, because the database uses groups defined on the operating system. You can,
however, add these users to groups in Native Directory and provision those groups.
You must configure Shared Services to connect to the database as the database administrator;
SYSTEM user, to retrieve the list of users and groups.
Configuring User Directories
50
for example, Oracle
Note:
Shared Services can retrieve only active database users for provisioning. Inactive and locked
database user accounts are ignored.
➤ To configure database providers:
1 Launch User Management Console. See “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
The Defined User Directories screen, which lists all configured user directories, including Native
Directory, opens.
3 Click Add.
4 In the Directory Type screen, select Relational Database (Oracle, DB2, SQL Server).
5 Click Next.
6 In the Database Configuration tab, enter configuration parameters.
Table 6 DB Connection Information Screen
Label
Database Type The relational database vendor. Shared Services supports only Oracle, IBM
Name A unique configuration name for the database provider. You use this name
Server The host name (or the IP address) of the computer where the database server
Description
DB2, and SQL Server databases as database providers.
Example:
to identify the database provider in situations where multiple providers are
defined in Shared Services.
Example:
is running.
Example:
Oracle 9i, 10g
Oracle_DB_FINANCE
myserver
Configuring Relational Databases as User Directories
51
Label Description
Port The port where the database server is available to accept requests.
Example:
Service/SID (Oracle only) The system identifier (default is orcl).
Example:
Database (SQL Server and DB2 only) The database to which Shared Services should connect.
Example:
User Name The user name that Shared Services should use to access the database. This
user must have access privileges to database system tables. Hyperion
recommends that you use the database Administrator's user name for SQL
Server and IBM DB2 databases, and the
databases.
Example:
Password The password of the user identified in the User Name box.
Example:
Trusted Check box that enables you to specify that this provider is a trusted source.
User credentials from trusted sources are not validated during SSO. If you do
not select this option, user credentials are validated every time a user
requests SSO to a different Hyperion product.
1521
orcl
master
system account for Oracle
SYSTEM
system_password
7 Optional: To define the maximum database connection pool size (default is 10), click Next.
The Advanced Database Configuration screen opens.
8 In Max ConnectionPool Size, enter the maximum number of connections in the database connection pool
created for this provider.
9 Click Finish.
10 Click OK to return to the Defined User Directories screen.
11 Test the database provider configuration. See “Testing User Directory Connections” on page 53.
12 Add the database provider to the search order used by Shared Services. See “Adding a User Directory to the
Search Order” on page 55 for details.
13 Specify global settings if needed. See “Setting Global Parameters” on page 57 for details.
14 Restart Shared Services.
Configuring User Directories
52
Testing User Directory Connections
After configuring a user directory, test the connection to ensure that Shared Services can
successfully connect to the user directory using the current settings.
Note:
Establishing a successful test connection does not mean that Shared Services will use the
directory. Shared Services uses only the directories that have been assigned a search order.
➤ To test user directory connection:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Administration > Configure User Directories.
The Defined User Directories screen that lists all the configured user directories, including Native
Directory, opens.
3 From the list of user directories, select the directory to test.
4 Click Test.
A status message indicating the results of the test is displayed.
5 Click OK.
Editing User Directory Settings
You can modify any of the parameters of an existing user directory configuration. Hyperion
recommends not editing the configuration data of user directories that have been used for
provisioning.
Caution!
Editing some settings, for example, the Base DN, in the user directory configuration invalidates
provisioning data. Exercise extreme care when modifying the settings of a user directory that
has already been provisioned.
➤ To edit a user directory configuration:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Administration > Configure User Directories.
3 From Defined User Directories screen, select the user directory to edit.
4 Click Edit.
5 Modify the configuration settings as needed.
Testing User Directory Connections
53
For explanation of the parameters you can edit, see the following tables:
● MSAD and other LDAP-enabled user directories:
❍ Table 1, “ Connection Information Screen,” on page 41
❍ Table 2, “ User Configuration Screen,” on page 44
❍ Table 3, “ Group Configuration Screen,” on page 46
● SAP providers: Table 4, “ SAP Connection Information Screen,” on page 47
● NTLM user directories: Table 5, “NTLM Connection Information Screen,” on page 49
● Database providers: Table 6, “ DB Connection Information Screen,” on page 51
6 Click Finish to save the changes.
Deleting User Directory Configurations
You can delete a user directory configuration at any time. Deleting a directory configuration
invalidates all the provisioning information for the users and groups derived from the user
directory. It also removes the directory from the search order.
Tip:
If you do not want to use a configured user directory that was used for provisioning, remove it
from the search order so that the user directory is not searched for users and groups. This action
maintains the integrity of provisioning information. It also enables you to use the user directory
at a later time, if needed.
➤ To delete a user directory configuration:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Administration > Configure User Directories.
3 From Defined User Directories screen, select the directory to delete.
4 Click Delete.
Managing User Directory Search Order
The search order associated with a configured user directory determines the position of the
directory in the search order that Shared Services uses to retrieve user and group information.
Shared Services ignores user directories that are not included in the search order. Consequently,
these user directories are not used to support authentication and provisioning.
Configuring User Directories
54
Note:
Shared Services terminates the search for the user or group when it first encounters the specified
user account. If a user has multiple accounts across user directories, Shared Services retrieves
the account from the user directory that is listed first in the search order.
By default, Native Directory is set as the first directory in the search order. Additional user
directories are given the next available sequence number in the search order. You can perform
these tasks to manage the search order:
● “Adding a User Directory to the Search Order” on page 55
● “Changing the Search Order” on page 56
● “Removing a Search Order Assignment” on page 56
Adding a User Directory to the Search Order
The order in which you add a user directory to the search order is retained as the default search
order. You must have already configured the user directory that you want to include in the search
order. To configure a user directory, see these topics:
● “Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
● “Configuring an SAP Provider” on page 46
● “Configuring an NTLM User Directory” on page 49
● “Configuring Relational Databases as User Directories” on page 50
➤ To add a user directory to the search order:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
3 From Defined User Directories screen, select the directory to add to the search order.
4 Click Add.
This button is available only if you have selected a user directory that is not already used in the
search order.
Note:
If you have NTLM and MSAD user directories configured, ensure that the MSAD user directory
comes after NTLM in the search order.
Shared Services assigns a default search order, which you may change. For more information,
see “Changing the Search Order” on page 56.
Managing User Directory Search Order
55
Changing the Search Order
The default search order assigned to each user directory, including Native Directory, is based
on the sequence in which the directory was added to the search order.
➤ To change the search order:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Administration > Configure User Directories.
3 From Defined User Directories screen, select the directory whose search order you want to change.
4 Click Move Up or Move Down as needed.
Note:
If you have NTLM and MSAD user directories configured, ensure that the MSAD user directory
comes after NTLM in the search order.
Shared Services displays a message indicating that the search order was updated.
5 Click OK.
The Defined User Directories screen is displayed, which lists the user directories in the updated
order.
Removing a Search Order Assignment
Deleting a user directory from the search order does not invalidate the directory configuration.
It merely removes the user directory from the list of directories that are searched for
authenticating users. A directory that is not included in the search order is set to
status. When you remove a user directory from the search order, the search sequence assigned
to the other user directories is automatically updated.
Note:
You cannot remove Native Directory from the search order.
➤ To delete a user directory from the search order:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
3 From Defined User Directories screen, select the directory to remove from the search order.
Not Used
4 Click Remove.
5 Click OK.
Configuring User Directories
56
Shared Services displays a confirmation dialog box.
Shared Services displays a message indicating that the search order was updated.
6 Click OK to return to the Defined User Directories screen, which lists the status of the user directory as
Not Used.
Setting Global Parameters
These global parameters are applicable to all user directories included in the search order.
● Token timeout–Specifies the time, in minutes, after which the SSO token issued by Hyperion
products or the security agent will expire. Users are forced to log in again after this period.
Note:
Token timeout is not the same as session timeout.
● Logging level–Sets the level at which security issues are recorded in the Shared Services
security log file.
Administrators can change the Shared Services log level on-the-fly to capture relevant
information to debug Shared Services issues. Shared Services application server restart is not
required to activate log level change.
Log files belonging to Hyperion products are stored in <
Hyperion_Home
>/logs, allowing
administrators to easily locate log files to monitor the applications and troubleshoot issues.
Product log files are created in a product-specific folder. For example, Shared Services logs
are in <
Hyperion_Home
>/logs/SharedServices9. Existing log files are not moved to
the new location.
● Delegated User Management Mode–Supports the distributed management of provisioning
activities.
● Support for Security Agent for Single Sign-on–Indicates whether user directories are used
to support SSO from security agents such as SiteMinder.
➤ To set global parameters:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Select Administration > Configure User Directories.
3 In Defined User Directories, set global parameters.
Table 7 Global Parameters for User Directories
Parameter
Token Timeout Time limit (in minutes) after which the SSO token issued by Hyperion
Description
products/security agent becomes invalid. Users will be logged out
after token timeout period. Token timeout is set based on the server's
system clock.
Example:
480
Setting Global Parameters
57
Parameter Description
Logging level Level at which user directory related issues are recorded in the Shared
Services security log files.
Example:
Support for Security Agent for Single Sign-on Option enabling support for SSO from security agents such as
SiteMinder.
Enable Delegated User Management Mode Option enabling delegated user management of Hyperion products.
See Chapter 6, “Delegated User Management.”
WARN
4 Click OK.
Overriding Cache Refresh Interval for MSAD and other LDAPEnabled User Directories
By default, Shared Services uses 60 minutes as the cache refresh interval; the period after which
Shared Services refreshes its internal cache of information retrieved from each LDAP-enabled
user directory configured with Shared Services.
Provisioning information for newly added users and groups in LDAP-enabled user directories
is available to Shared Services only after the next cache refresh. This may result in new users and
members of new groups not getting their provisioned roles for up to 60 minutes.
➤ To change the cache refresh interval:
1 Using a text editor, open CSS.xml file.
This file is located in <
\WebLogic9\SharedServices9\config
Hyperion/deployments/WebLogic9/SharedServices9/config
HSS_home
>/config. For example, C:\Hyperion\deployments
(WebLogic 9.1 on Windows) and /vol1/
(WebLogic 9.1 on
UNIX).
2 Insert the following code into the definition of the LDAP-enabled user directory for which you want to modify
cache refresh interval. This line must be placed immediately after the
authType>
<cacheRefreshInterval>
Be sure to replace
<cacheRefreshInterval>10</cacheRefreshInterval> to set the interval to 10 minutes.
You can set the interval to
code line.
<interval>
<interval>
</cacheRefreshInterval>
with the desired cache refresh interval in minutes. For example,
0 if you want to refresh the cache for every call. This affects
<authType>simple</
performance.
Note:
Cache refresh interval must be set separately for each LDAP-enabled user directory.
3 Save and close the CSS.xml file.
4 Restart the application server if it is running.
Configuring User Directories
58
Setting Timeout to Resolve SAP Keystore File
By default, Shared Services uses 10 seconds as the timeout for resolving the SAP keystore file.
You can override this value in the Shared Services configuration file.
➤ To change the timeout for resolving the SAP keystore file:
1 Using a text editor, open CSS.xml.
This file is in <
\SharedServices9\config
deployments/WebLogic9/SharedServices9/config
HSS_home
2 Insert the following code into the SAP provider definition. This code must be placed immediately after the
token timeout declaration.
<keystore>
<timeout><interval></timeout>
</keystore>
Be sure to replace
example,
<timeout>22</timeout> to set the interval to 22 seconds.
3 Save and close CSS.xml.
4 Restart the application server if it is running.
Connection Pooling
Previous releases of Hyperion products created connection threads to external user directories
on a need-to-use basis. To improve performance, Shared Services allows connection pooling
where user directory connections use a common connection pool.
>/config. For example, C:\Hyperion\deployments\WebLogic9
<interval>
(WebLogic 9.1 on Windows) and /vol1/Hyperion/
(WebLogic 9.1 on UNIX).
with the desired keystore timeout interval in seconds. For
Shared Services uses a default connection pool setting that is used for all configured user
directories. Default connection pool settings are not recorded in
connection pool settings for a user directory, you must update the configuration settings of the
user directory in
do not contain a connection pool definition use the default connection pool.
CSS.xml with a connection pool definition. User directory configurations that
CSS.xml. To use custom
➤ To define connection pool for a user directory configuration:
1 Using a text editor, open CSS.xml.
This file is in <
\SharedServices9\config
deployments/WebLogic9/SharedServices9/config
HSS_home
>/config. For example, C:\Hyperion\deployments\WebLogic9
(WebLogic 9.1 on Windows) and /vol1/Hyperion/
(WebLogic 9.1 on UNIX).
2 In each of the user directory configuration definitions, include a connection pool definition similar to the
following:
<connectionPool>
<maxSize>100</maxSize>
Setting Timeout to Resolve SAP Keystore File
59
<timeout>90000</timeout>
<evictInterval>60</evictInterval>
<allowedIdleConnTime>120</allowedIdleConnTime>
<growConnections>false</growConnections>
</connectionPool>
See Table 8 for an explanation of these attributes.
A sample
CSS.xml containing a connection pool definition:
<ldap name="ExampleLDAP">
<trusted>true</trusted>
<url>ldap://myServer:390/dc=example,dc=com</url>
<userDN>cn=Directory Manager</userDN>
<password>{CSS}haGFq18Y1357xXN2b0u+ZQ==</password>
<authType>simple</authType>
<connectionPool>
<maxSize>100</maxSize>
<timeout>90000</timeout>
<evictInterval>60</evictInterval>
<allowedIdleConnTime>120</allowedIdleConnTime>
<growConnections>false</growConnections>
</connectionPool>
<user>
<url>ou=People</url>
</user>
<group>
<url>ou=Groups</url>
</group>
</ldap>
Table 8 Connection Pool Attributes
Element
Attribute Description
<connectionPool> Connection pool definition
<maxSize> Maximum number of connections in the pool. Default is
100 for LDAP-enabled directories, including MSAD, and
300 for Native Directory.
<timeout> Timeout (in milliseconds) to get the connection from the
pool. An exception is thrown after this period. Default is
300000 milliseconds (5 minutes).
<evictInterval> Optional: The interval (in minutes) for running the eviction
process to clean up the pool. The eviction process cleans
up idle connections that have exceeded the
allowedIdleConnTime. Default is 60 minutes.
<allowedIdleConnTime> Optional: The time (in minutes) after which idle
connections in the pool are cleaned up by the eviction
process. Default is 120 minutes.
<growConnections> This option indicates whether the connection pool can
grow beyond
<maxSize>. Default is false. If you do not
allow the connection pool to grow, the system throws an
error if a connection is not available within the time set for
<timeout>.
Configuring User Directories
60
3 Verify that each user directory configuration contains a connection pool definition.
4 Optional: Define socket connection timeout for user directories by including the <socketTimeOut>
parameter in the Native Directory user directory definition. For example, the following setting specifies a
socket timeout of 5 seconds.
<socketTimeOut>60000</socketTimeOut>
Note:
Socket timeout set for Native Directory applies to all configured user directories.
Use a high socket timeout value in the following scenarios:
● A large number of users and groups are defined in the user directory.
● The machines that host the user directories are geographically distant from the machine that
hosts Shared Services.
● A low-bandwidth network connection exists between the machine that hosts Shared Services
and the machine that hosts the user directory.
A sample Native Directory definition containing socket timeout definition:
<native name="Native Directory">
<startupRetryInterval>5</startupRetryInterval>
<startupRetryLimit>5</startupRetryLimit>
<socketTimeOut>60000</socketTimeOut>
<connectionPool>
<maxSize>600</maxSize>
<timeout>1000</timeout>
<growConnections>true</growConnections>
</connectionPool>
</native>
5 Save and close CSS.xml.
6 Restart Shared Services and all Hyperion products.
Using Special Characters
MSAD and other LDAP-enabled user directories allow special characters in entities such as DNs,
user names, roles, and group names. Special handling may be required for Shared Services to
understand such characters.
Generally, you must use escape characters while specifying any special character used in user
directory settings for LDAP-enabled user directories, including MSAD; for example, user and
group URLs and Base DN. Native Directory and NTLM do not require special handling of
characters.
Table 9 lists the special characters that can be used in user names, group names, user URLs,
group URLs, and in the value of OU in user DN. Native Directory and NTLM do not require
special handling of characters.
Using Special Characters
61
Table 9 Supported Special Characters
Character
Name or Meaning Character Name or Meaning
( open parenthesis $ dollar
) close parenthesis + plus
“ quotation mark / slash
' single quotation mark \ backslash
, comma ^ caret
& ampersand ; semicolon
= equal to # pound
< less than @ at
> greater than
Table 10 Special Characters that Should not Be Used in Application IDs
Character
Name or Meaning Character Name or Meaning
, comma ; semicolon
< less than + plus
> greater than = equal to
& ampersand
Table 11 Special Characters that Should not Be Used in Application Names
Character
Name or Meaning
[ open bracket
] close bracket
( open parenthesis
) close parenthesis
● Special characters are not permitted in the value set for the Login User attribute.
● Asterisk (*) is not supported in user names, group names, user and group URLs, and in the
name of the OU in UserDN.
● Attribute values containing a combination of special characters are not supported.
● Ampersand (&) can be used without an escape character. For MSAD settings, & must be
specified as
&.
Configuring User Directories
62
● User and group names cannot contain both a backslash (\) and slash (/). For example, names
such as
test/\user and new\test/user are not supported.
● Space is not supported as a special character in Base DN.
Table 12 Characters that Need not Be Escaped
Character
Name or Meaning Character Name or Meaning
( open parenthesis ' single quote
) close parenthesis ^ caret
$ dollar @ at
These characters must be escaped if you use them in user directory settings (user names, group
names, user URLs, group URLs and User DN).
Table 13 Escape for Special Characters
Special Character
comma (,)
slash (/)
plus sign (+)
equal to (=)
pound (#)
semicolon (;)
less than (<) \< ou=test<ou ou=test\<ou
Escape Sample Setting Escaped Example
backslash (\) ou=test,ou
ou=test/ou
ou=test+ou
ou=test=ou
ou=test#ou
ou=test;ou
ou=test\,ou
ou=test\/ou
ou=test\+ou
ou=test\=ou
ou=test\#ou
ou=test\;ou
greater than (>) \> ou=test>ou ou=test\>ou
“ (quotation mark) \\ (two backslashes) ou=test”ou ou=test\\”ou
\ (backslash) \\\ (three backslashes) ou=test\ou ou=test\\\\ou
Caution!
If the user URL is not specified, users created within the RDN root must not contain / (slash)
or \ (backslash). Similarly, these characters should not be used in the names of groups created
within the RDN root if a group URL is not specified. For example, group names such as
OU=child\ou,OU=parent/ou or OU=child/ou,OU=parent\ou are not supported. This
issue does not apply if you are using a unique attribute as the
ID Attribute in the user directory
configuration.
Using Special Characters
63
Configuring User Directories
64
Working with Applications and
5
In This Chapter
Overview
Projects
Overview ............................................................................................................................65
Working with Projects..............................................................................................................65
Managing Applications............................................................................................................67
Applications and projects are two important Shared Services concepts. An application is a
reference to a single instance of a Hyperion application that is registered with Shared Services.
The registration process makes Shared Services aware of the existence of the Hyperion
application. All provisioning activities are performed against an application.
In User Management Console, Hyperion applications are organized into projects. A project is
a container for applications. For example, a project may consist of a Reporting and Analysis
application and a Planning application. To provision users to an application, the application
must belong to a project.
This chapter contains information on creating and managing projects. It also provides
information on working with applications.
Working with Projects
A project is a container for Hyperion applications. For example, a project may contain a Planning
application and one or more Reporting and Analysis applications. An application can belong to
only one project.
Applications that are registered withShared Services but do not yet belong to a project are listed
under Unassigned Applications in User Management Console.
The applications that are registered with Shared Services but have not been assigned to a project
are listed under the Unassigned Applications node within User Management Console.
Applications assigned to a project are listed under the Projects node of User Management
Console.
An application can belong to only one project, but a project may contain multiple applications.
You can start the provisioning process only after applications are assigned to projects.
Topics covering project management tasks:
Overview
65
● “Creating Projects ” on page 66
● “Modifying Project Properties” on page 67
● “Deleting Projects ” on page 67
Note:
You must be a Shared Services Administrator or Project Manager to create and manage projects.
Shared Services Administrators can work with all registered applications but a Project Manager
can work only with the application for which that person is the project manager.
Creating Projects
During the project creation process, you can also assign applications to the new project.
➤ To create a project:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Right-click Projects in the Object Palette, and select New.
3 Enter a unique project name in Name text box and enter an optional description in Description box.
Note:
Project names that start with the less than symbol (<), for example <my_project do not appear
in the Provisioning screen. Hyperion recommends that you create project names that start with
a character other than the less than symbol.
4 To assign applications to this project:
a. From List Applications in Project, select<Unassigned Applications> or an existing
project that contains applications that you want to assign to the project.
b. Click Update List to list the applications in the Available Applications list.
c. From Available Applications, select the applications to assign to the project and click
Add.
The selected applications appear in the Assigned Applications list.
d. To remove an assigned application, from Assigned Applications, select the application to
remove from the project and click Remove. To remove all applications from the Assigned
Applications list, click Reset.
5 Click Finish.
6 Click Create Another to create another project, or OK to close the status screen.
Working with Applications and Projects
66
Modifying Project Properties
You can modify all properties and settings of an existing project, including application
assignments.
Note:
You can also add applications to projects by moving them from another project or from the
Unassigned Applications node. Refer to “Moving Applications ” on page 69.
➤ To modify a project:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Projects from the Object Palette.
3 On the Browse tab, right-click the project to modify and select Open.
4 Modify the project properties as needed. See step 4 on page 66 for information on assigning or removing
applications.
5 Click Save.
Deleting Projects
Deleting a project removes the association of applications with the project, removes provisioning
assignments from applications within the project, and deletes the project container. Applications
from deleted projects are moved to the Unassigned Applications node.
➤ To delete a project:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 Select Projects from the Object Palette.
3 In the Browse tab, right-click the project and select Delete.
4 Click OK in the confirmation screen.
Managing Applications
User Management Console keeps track of all Hyperion applications that are registered with
Shared Services. The registration process is completed from individual Hyperion applications
and not from Shared Services.
All registered applications, initially, are listed under the Unassigned Applications node on User
Management Console because the registration process does not automatically assign
applications to a project. Applications must be assigned to a project before users and groups can
Managing Applications
67
be provisioned against the roles belonging to those applications. Applications that have been
assigned to a project are listed under the Project node of User Management Console.
Topics covering application management tasks:
● “Assigning Access Permissions to Applications ” on page 68
● “Moving Applications ” on page 69
● “Copying Provisioning Information Across Applications” on page 69
● “Deleting an Application” on page 69
Assigning Access Permissions to Applications
User Management Console enables application administrators to perform provisioning tasks,
such as assigning access permissions to application-specific objects; for example, reports and
calculation scripts. For example, for Essbase applications, users with the appropriate Oracle's
Essbase® Administration Services permissions can assign filter and calculation script access to
selected users and groups.
Some products require that certain security tasks be performed in the product interface itself,
not through User Management Console. For example, using the Administration Services
interface, you must create filters and calculation scripts. You can then provision these objects
by assigning specific users or groups from User Management Console. Likewise, you must assign
access permission on repository content of Reporting and Analysis from within that product,
not from User Management Console.
You must either be a Shared Services administrator or be provisioned with the appropriate
product role (Planning Manager, for example) to assign access permission from the User
Management Console. See the appropriate product appendix at the end of this guide for
instructions on assigning access permission for specific products.
Before starting this procedure, ensure that the required servers and applications are running.
➤ To assign application-specific access permissions:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From the Projects node in the Object Palette, expand the project containing the application.
3 Right-click the application and select the appropriate menu item for that application. An application-specific
tab is displayed.
Note:
If the application is not running, an error message is displayed when you select the application.
Restart the product server and refresh the Object Palette by clicking View > Refresh to access
the application.
4 Assign access permissions as needed. Refer to the appropriate product appendix at the end of this guide
for details.
Working with Applications and Projects
68
Moving Applications
You can move assigned applications from one project to another and from unassigned
applications to existing projects. Moving an application removes the association between the
application and the project but does not affect provisioning assignments for the application.
➤ To move an application:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Right-click the application and select Move To.
3 On the Move To tab, select the destination project for the application.
4 Click Save.
Copying Provisioning Information Across Applications
If you have multiple products of the same type (product and product version), you can copy
provisioning information from one application to another. When you copy provisioning
information, all user, group, and role information is copied to the target application. Productspecific access control settings are not copied.
➤ To copy provisioning information across applications:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From Projects in the Object Palette, right-click the application from which you want to copy provisioning
information and select Copy Provisioning.
The Copy Provisioning tab opens. This tab lists the target application to which you can copy
provisioning information.
3 Select the destination project.
4 Click Save.
Deleting an Application
Shared Services administrators can delete applications from projects or from available
unassigned applications.
Deleting an application from a project moves it from the project to the Unassigned Applications
node on the Object Palette. You may now assign this application to a different project. When
you delete an application from a project, all provisioning information for that application is
removed.
Deleting an application from the Unassigned Applications node on the Object Palette deregisters
the application and removes all meta data information for that application. Perform this process
only if there is no other way to deregister or delete the application.
Managing Applications
69
➤ To delete an application:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From existing projects or from unassigned applications, locate the application to delete.
3 Right-click the application and select Delete.
4 Click OK in the confirmation dialog box.
Working with Applications and Projects
70
Delegated User Management
6
In This Chapter
About Delegated User Management.............................................................................................71
Hierarchy of Administrators .......................................................................................................71
Enabling Delegated User Management Mode...................................................................................72
Creating Delegated Administrators...............................................................................................72
About Delegated User Management
Delegated user management enables creating a hierarchy of administrator users for Hyperion
products focusing on the expertise and access needs of such users. This feature allows the Shared
Services Administrator to delegate the responsibility of managing users and groups to other
administrators who are granted restricted access to manage users and groups for which they are
responsible.
In delegated administration mode, a search for users and groups retrieves only the users and
groups for which an administrator is responsible. Only the admin or users with the Administrator
Shared Services role can view all the users and groups across delegated administrators.
Hierarchy of Administrators
The default Shared Services Administrator account (admin) is the most powerful account in
Hyperion products. Hyperion recommends that you change the password of this account after
you first access Shared Services.
Two tiers of administrators exist in delegated administration mode:
● “Shared Services Administrators” on page 71
● “Delegated Administrators” on page 72
Shared Services Administrators
Hyperion recommends that you create Shared Services Administrator accounts similar to the
default admin account to administer Shared Services and other Hyperion applications.
About Delegated User Management
71
You can create Shared Services Administrator accounts by provisioning users and groups with
the Shared Services Administrator role, which provides unfettered access to all Shared Services
functions.
Delegated Administrators
In contrast to Shared Services Administrators, Delegated Administrators have limited
administrator-level access to Shared Services and Hyperion products. Delegated Administrators
can access only the users and groups for which they are granted Administrator access, dividing
user and group management tasks across multiple administrators.
The permissions of Delegated Administrators on Hyperion products are controlled by the access
rights that a Shared Services Administrator has granted them through provisioning. For example,
assume that a Delegated Administrator is granted the Directory Manager global role in Shared
Services, enabling the user to create new users and groups in Native Directory. Without
additional roles, this Delegated Administrator cannot view a list of users and groups that other
administrators created.
If they have the permission to provision users (granted through the Provisioning Manager role),
Delegated Administrators can create other Delegated Administrators and provision them to
further delegate administrative tasks.
Enabling Delegated User Management Mode
You must enable Delegated User Management mode for Shared Services before you can create
delegated administrators. The default Shared Services deployment does not support delegated
administration.
Additional screens and menu options become available after you switch to Delegated User
Management mode.
➤ To enable Delegated User Management mode:
1 Launch the Oracle's Hyperion® Shared Services User Management Console, as explained in “Launching User
Management Console” on page 33.
2 From Administration, select Configure User Directories.
3 From Defined User Directories, select Enable Delegated User Management Mode.
4 Click OK.
5 Restart Shared Services.
Creating Delegated Administrators
Delegated User Management
72
● “Planning Steps” on page 73
● “Provisioning Delegated Administrators” on page 73
● “Creating Delegated Lists” on page 73
● “Viewing Delegated Reports” on page 77
Planning Steps
User Accounts for Delegated Administrators
Shared Services Administrators create Delegated Administrators from existing user accounts in
the user directories configured on Shared Services. Unlike in the provisioning process, delegated
administration capabilities cannot be assigned to groups. Before starting the process of
delegating Shared Services administration, verify that Delegated Administrators are created as
users in a configured user directory.
Create a Delegation Plan
The delegation plan should identify the levels of Delegated Administrators needed to effectively
administer Hyperion products. The plan should identify:
● Users and groups that each Delegated Administrator should manage. This list can be used
while creating Delegated Lists. See “Creating Delegated Lists” on page 73.
● Shared Services and Hyperion product roles that each Delegated Administrator should be
granted.
Provisioning Delegated Administrators
Shared Services Administrators provision Delegated Administrators to grant them roles based
on the delegation plan.
Delegated Administrators must be granted Shared Services roles depending on the activities they
should perform. See “Shared Services Roles” on page 135 for a list of Shared Services roles.
Delegated Administrators can be granted roles from Hyperion products; for example,
Provisioning Manager from Planning, to allow them to perform administrative tasks in
Hyperion products.
Creating Delegated Lists
Delegated lists identify the users and groups that a Delegated Administrator can manage. Each
list is assigned to one or more Delegated Administrators. Delegated Administrators can:
● View only the users and groups assigned to them through delegated lists. All other users and
groups remain hidden from their view.
● Create delegated lists for other users they manage.
● Search and retrieve only the users and groups that are included in their delegated lists.
Creating Delegated Administrators
73
Note:
Shared Services displays the Delegated List node only if the current user is assigned to manage
delegated lists.
The users and groups that a Delegated Administrator creates are not automatically assigned to
the administrator who created them. A Shared Services Administrator must add these users and
groups to delegated lists before Delegated Administrators can access them. Delegated
Administrators, however, can assign these users and groups to the delegated lists that they create.
➤ To create delegated lists:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In Native Directory in Object Palette, right-click Delegated List, and select New.
The Create Delegated List screen opens.
3 In Name, enter a unique name for the delegated list.
4 Optional: In Description, type a description of the list.
5 Optional: To add groups to the list, click Next.
a. In Search for Groups, enter the name of the group to assign to the list. Leave this field
empty to retrieve all groups. Use * as the wildcard for pattern searches. If you are a
Delegated Administrator, only groups assigned to you are displayed.
b. In Directory, select the user directory from which groups are to be displayed.
c. Click Go.
d. From Available Groups, select one or more groups.
e. Click Add.
The selected groups are listed in Assigned Groups.
Note:
Shared Services considers Oracle and SQL Server database roles as the equivalents of groups
in user directories. Oracle database roles can be hierarchical. SQL Server database roles
cannot be nested. Because DB2 does not support roles, Shared Services does not display
groups if you select a DB2 database provider.
f. Optional: To unassign a group, from Assigned Groups, select a group and click Remove.
To unassign all groups, click Reset.
6 Optional: To add users to the list, click Next.
a. In Search for Users, type the name of the user to assign to the list. Leave this field blank
to retrieve all users. Use * as the wildcard for pattern searches. If you are a Delegated
Administrator, only users assigned to you are displayed.
Delegated User Management
74
b. In Directory, select the user directory from which users are to be displayed.
c. Click Go.
d. From Available Users, select one or more users.
e. Click Add.
The selected users are listed in Assigned Users.
f. Optional: To unassign a user, from Assigned Users, select a user and click Remove. To
unassign all users, click Reset.
Note:
The Delegated Administrator of the list is automatically added as a user.
7 Optional: To assign Delegated Administrators for this list, click Next.
The Managed By tab opens.
a. In Search for Users, enter the name of the user to assign as the Delegated Administrator
of the list. Leave this field blank to retrieve all users. Use * as the wildcard for pattern
searches. If you are a Delegated Administrator, only users assigned to you are displayed.
b. In Directory, select the user directory from which users are to be displayed.
c. Click Go.
d. From Available Users, select one or more users.
e. Click Add.
The selected users are listed in Assigned Users.
f. Optional: To unassign a user, from Assigned Users list, select the user and click Remove.
To unassign all users, click Reset.
Note:
The user who creates the list is automatically added as a Delegated Administrator of the list.
8 Click Finish.
Modifying Delegated Lists
Delegated Administrators can modify only the lists assigned to them. Users with Shared Services
Administrator role can modify all delegated lists.
➤ To modify delegated lists:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node in the Object Palette, select Delegated Lists.
3 Search for the delegated list to modify. See “Searching for Users, Groups, Roles, and Delegated Lists” on
page 34.
Delegated lists that meet the search criterion are listed on the Browse tab.
4 Right-click the delegated list and select Properties.
Creating Delegated Administrators
75
The Delegated List Properties screen opens.
5 Optional: On General, modify the list name and description.
6 Optional: To add groups, click Group Members.
a. In Search for Groups, enter the name of the group to assign to the list. Leave this field
empty to retrieve all groups. Use * as the wildcard for pattern searches. If you are a
Delegated Administrator, only groups assigned to you are displayed.
b. In Directory, select the user directory from which groups are to be displayed.
c. Click Go.
d. From Available Groups, select one or more groups.
e. Click Add.
The selected groups are listed in Assigned Groups.
f. Optional: To unassign a group, from Assigned Groups, select the group and click
Remove. To unassign all groups, click Reset.
7 Optional: To add users to the list, click User Members.
a. In Search for Users, enter the name of the user to assign to the list. Leave this field blank
to retrieve all users. Use * as the wildcard for pattern searches. If you are a Delegated
Administrator, only users assigned to you are displayed.
b. In Directory, select the user directory from which users are to be displayed.
c. Click Go.
d. From Available Users, select one or more users.
e. Click Add.
The selected users are listed in Assigned Users.
f. Optional: To unassign a user, from Assigned Users list, select the user and click Remove.
To unassign all users, click Reset.
Note:
The Delegated Administrator of the list is automatically added as a user.
8 Optional: To modify Delegated Administrator assignment, click Managed By.
The Managed By page opens.
a. In Search for Users, enter the name of the user to assign as the Delegated Administrator
of the list. Leave this field blank to retrieve all users. Use * as the wildcard for pattern
searches. If you are a Delegated Administrator, the users assigned to you are displayed.
b. In Directory, select the user directory from which users are to be displayed.
c. Click Go.
Delegated User Management
76
d. From Available Users, select one or more users.
e. Click Add.
The selected users are listed in Assigned Users.
f. Optional: To unassign a user, from Assigned Users list, select the user and click Remove.
To unassign all users, click Reset.
Note:
The user who creates the list is automatically added as a Delegated Administrator of the list.
9 Click Save.
Deleting Delegated Lists
➤ To delete delegated lists:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node in the Object Palette, select Delegated Lists.
3 Search for the delegated list to modify. See “Searching for Users, Groups, Roles, and Delegated Lists” on
page 34.
Delegated lists that meet the search criterion are listed on the Browse tab.
4 Right-click the delegated list and select Delete.
5 Click OK in the confirmation dialog box.
Viewing Delegated Reports
Delegated reports contain information about the users and groups assigned to the selected
delegated lists and the delegated administrators to whom the list is assigned.
Shared Services Administrators can generate and view delegated reports on all delegated lists.
Delegated Administrators can generate reports on the delegated lists they created and the
delegated lists assigned to them.
➤ To view delegated reports:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In Native Directory in Object Palette, right-click Delegated List, and select View Delegated Reports.
The View Delegated Report screen opens.
3 In Delegated List Name, enter the name of the list for which the report is to be generated. Use * as wildcard
for pattern searches.
4 In Managed By, enter the user ID of the Delegated Administrator whose assignments in the specified list
are to be reported. Use * as wildcard for pattern searches.
5 Click Create Report.
6 Click Cancel to close the report or Print Preview to preview the report.
If you preview the report:
Creating Delegated Administrators
77
a. Click Print to print the report.
b. Click Close to close the View Report window.
Delegated User Management
78
7
In This Chapter
Managing Native Directory
About Native Directory.............................................................................................................79
Managing Native Directory Users.................................................................................................81
Managing Native Directory Groups...............................................................................................84
Managing Roles....................................................................................................................88
Changing Native Directory root User Password..................................................................................91
Backing Up the Native Directory Database......................................................................................91
Synchronizing Native Directory Database with the Shared Services Repository .............................................93
Recovering Native Directory Data.................................................................................................93
Setting Up Native Directory for High Availability and Failover .................................................................94
Migrating Native Directory.........................................................................................................99
About Native Directory
Shared Services uses Native Directory to store user provisioning data and a relational database
to store product registration data.
After the initial logon to a Hyperion product, the product directly queries Native Directory for
user provisioning information. Hyperion products can function normally only if Native
Directory is running.
User Management Console displays a list of users and groups for each configured user directory,
including Native Directory. These lists are used to provision users and groups against application
roles.
User Management Console is the central administration point for Native Directory, the default
user directory that is installed with Shared Services. Other user directories are administered
through their own administration screens.
Installation Location
By default, Native Directory is installed to
<HSS_version>
Examples:
/openLDAP.
<Hyperion_Home>/SharedServices/
● C:\Hyperion\SharedServices\9.3.1\openLDAP (Windows)
About Native Directory
79
● /vol1/Hyperion/SharedServices/9.3.1/openLDAP (UNIX)
The install location of Native Directory is referred to as
<
openLDAP_Home
> throughout this
document.
Native Directory data is stored in
<
stored in
openLDAP_Home
>/bdb/bin.
openLDAP_Home
>/var/openldap-data, and utilities are
<
By default, Native Directory is deployed to port 58089 as a process (UNIX) or a service
(Windows).
Default Users and Groups
Native Directory, by default, contains one user account (admin, with password as the default
password). Using this account, you can perform all Native Directory and Shared Services
administration tasks.
All Shared Services users belong to the WORLD group, the only default Native Directory group.
WORLD is a logical group. All Shared Services users inherit any role assigned to this group. A
user gets the sum of all permissions assigned directly to that user as well as those assigned to the
user's groups (including WORLD group).
If Shared Services is deployed in delegated mode, the WORLD group contains groups as well as
users. If the delegated list of a user contains the WORLD group, then the user can retrieve all
users and groups during search operations.
Starting Native Directory
By default, Native Directory is installed as a Windows service or UNIX process.
Starting Native Directory in Normal Mode
On Windows, you can start Native Directory by starting Hyperion S9 OpenLDAP service from
<
the Services window, or by executing
On UNIX systems, run
<
openLDAP_Home
openLDAP_Home
Starting Native Directory in Debug Mode
➤ To start Native Directory in debug mode:
1 Using a command prompt window, navigate to <
2 Execute the following command:
slapd —d 1.
>/startOpenLDAP script to start the process.
openLDAP_Home
>startService.bat.
>.
Managing Native Directory
80
Stopping Native Directory
On Windows, you can stop Native Directory by stopping Hyperion S9 OpenLDAP service from
<
the Services window, or by executing
openLDAP_Home
>stopService.bat.
On UNIX systems, run
<
openLDAP_Home
process.
Managing Native Directory Users
Shared Services Administrators or Directory Managers can perform the following tasks to
manage Native Directory user accounts:
● “Creating Users” on page 81
● “Modifying User Accounts” on page 82
● “Deactivating User Accounts” on page 83
● “Deleting User Accounts ” on page 84
● “Provisioning Users and Groups” on page 101
● “Deprovisioning Users and Groups” on page 102
● “Generating Provisioning Reports” on page 102
Note:
Users in external user directories cannot be managed from User Management Console.
>/stopOpenLDAP script to stop the Native Directory
Creating Users
➤ To create users:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node in the Object Palette, right-click Users, and select New.
3 In the Create User screen, enter the required information.
Table 14 Create User Screen
Label
User Name A unique user identifier as per the naming conventions of your organization (for example, first
First Name First name of the user (optional)
Description
name initial followed by last name, as in jyoung)
User names can contain any number or combination of characters.
You cannot create identical user names, including names that are differentiated only by number
of spaces. For example, you cannot create user names
user and 1) and user 1 (with two spaces between user and 1).
user 1 (with one space between
Managing Native Directory Users
81
Label Description
Last Name Last name of the user (optional)
Description Description of the user (optional)
Email Address Email address of the user (optional)
Password The password for this user account. Passwords are case-sensitive and can contain any
combination of characters.
Confirm Password The entry in the Password text box
4 Optional: To add the user to one or more groups, click Next.
a. On the Group Membership page, in Search for Groups, type the name of the group to
assign to the user (type * to list all available groups).
b. Click Go.
c. From Available Groups, select one or more groups.
d. Click Add.
The selected groups are listed in Assigned Groups list.
e. Optional: To unassign a group, from Assigned Groups list, select the group and click
Remove. To unassign all groups, click Reset.
5 Click Finish.
6 Click Create Another to create another user or OK to close the Create User screen.
Modifying User Accounts
For the default admin account, you can only modify e-mail address, password, and group
membership. For all other user accounts, you can modify any property.
➤ To modify user accounts:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node in the Object Palette, select Users.
3 Search for user account. See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
A list of users that meet the search criterion is displayed on the Browse tab.
4 Right-click the user account and select Properties.
The User Properties screen opens.
Note:
Managing Native Directory
82
The User Properties screen displays the Managed By tab if Shared Services is deployed in
Delegated Administration mode.
5 On the General tab, modify one or more user properties.
See Table 14 for descriptions of the properties that you can modify.
6 Optional: Modify the user's associations with Native Directory groups.
a. In Search for Groups box on the Member Of tab, type the name of the group to assign to
this user (type * to list all available groups), and click Go.
b. From Available Groups, select one or more groups to assign to the user, and click Add.
The selected groups are listed in Assigned Groups.
To remove an assigned group, from Assigned Groups, select the group to remove, and
click Remove.
7 To view the delegated administrators assigned to the user, open the Managed By tab, which is available only
if Shared Services is deployed in Delegated Administration mode.
8 Click Save.
Deactivating User Accounts
You can deactivate user accounts that should not have access to Hyperion applications. Account
deactivations are, typically, temporary suspensions where the Native Directory administrator
hopes to reactivate the accounts in the future.
● Inactive user accounts cannot be used to log on to Hyperion applications, including User
Management Console.
● Group associations of inactive accounts are maintained and remain visible to Native
Directory administrators.
● Role associations of inactive accounts are maintained.
● Inactive user accounts are not displayed on the product-specific access-control screens of
items for which access is disabled.
● Inactive user accounts are not deleted from Native Directory.
Note:
The admin account cannot be deactivated.
➤ To deactivate user accounts:
1 Launch the User Management Console, as explained in “Launching User Management Console” on page
33.
2 In the Native Directory node in the Object Palette, right-click Users, and select Show Active to list all user
accounts you can deactivate.
To search for a specific user account to deactivate, see “Searching for Users, Groups, Roles, and
Delegated Lists” on page 34.
3 Right-click the user account, and select Deactivate.
Managing Native Directory Users
83
Activating Inactive User Accounts
Activating inactive user accounts reinstates all associations that existed before the accounts were
deactivated. If a group of which the inactive user account was a member was deleted, the roles
granted through the deleted group are not reinstated.
➤ To activate deactivated user accounts:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node of the Object Palette, right-click Users, and select Show Inactive to list all
inactive user accounts you can activate.
To search for a specific user account to activate see “Searching for Users, Groups, Roles, and
Delegated Lists” on page 34.
3 Right-click the user account, and select Activate.
Deleting User Accounts
Deleting a user account removes the user’s associations with Native Directory groups, the role
assignments of the user, and the user account from Native Directory.
Note:
The admin account cannot be deleted.
➤ To delete user accounts:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From the Native Directory node of the Object Palette, click Users.
3 Search for a user account. See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
A list of users that meet the search criterion is displayed on the Browse tab.
4 Right-click the user account, and select Delete.
Managing Native Directory Groups
Native Directory users can be grouped based on common characteristics. For example, users
can be categorized into groups such as staff, managers, and sales based on function, and
Sales_West and Managers_HQ, based on location. A user can belong to one or more groups.
Native Directory groups can contain other groups and users from user directories configured
on Shared Services.
Managing Native Directory
84
Group affiliations of a user are important considerations in the authorization process. Typically,
groups, rather than individual user accounts, are used to facilitate the provisioning process.
Tasks performed by Shared Services administrators or directory managers:
● “Creating Groups” on page 85
● “Modifying Groups” on page 86
● “Deleting Groups” on page 88
● “Provisioning Users and Groups” on page 101
● “Deprovisioning Users and Groups” on page 102
● “Generating Provisioning Reports” on page 102
Note:
Groups on external user directories cannot be managed from User Management Console.
Creating Groups
Native Directory groups can contain users and groups from any user directories configured on
Shared Services, including Native Directory. Groups that contain other groups are known as
nested groups.
Each component group of a nested group used in provisioning inherits all roles assigned to the
nested group. Similarly, users assigned to a group inherit the roles assigned to the group.
When a group from an external user directory is added to a Native Directory group, Shared
Services creates a reference in the database to establish the relationship.
➤ To create Native Directory groups:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Object Palette, right-click Groups, and select New.
3 For Name in the Create Group screen, enter a unique group name.
Group names are not case-sensitive.
4 Optional: Enter a group description.
5 Perform an action:
● To create the group without adding groups or users, click Finish, and go to step 10.
● To create a nested group or assign users to the group, click Next.
The Group Members tab is displayed.
6 Create a nested group. To skip this step, click Next.
a. In Search for Groups, enter the criterion for retrieving groups. Use * (asterisk) as the
wildcard to retrieve all available groups.
b. In Directory, select the user directory from which to retrieve groups.
All configured user directories are listed in the Directory list.
c. Click Go.
Groups that match the search criterion are listed under Available Groups.
Managing Native Directory Groups
85
d. From Available Groups, select the groups to nest within the new group.
e. Click Add.
The selected groups are listed under Assigned Groups list.
To remove an assigned g rou p, from Assigned Gro ups , select the group to remove and click
Remove. To remove all assigned groups, click Reset.
f. Optional: To retrieve and assign groups from other user directories, repeat Steps a-e.
7 To create the group without adding users, click Finish. To add uses to the group, click Next.
The User Members tab is displayed.
8 To assign users to the group:
a. In Search for Users, enter the search criterion. Use * (asterisk) as the wildcard to retrieve
all users.
b. In Directory, select the user directory from which to retrieve users.
All configured user directories are listed under Directory.
c. Click Go.
User accounts matching the search criterion are listed under Available Users.
d. From Available Users, select one or more users to add to the group.
e. Click Add.
The selected user accounts are listed under Assigned Users. To remove a selected user,
from Assigned Users, select the user to remove and click Remove. To remove all selected
users, click Reset.
f. Optional: To retrieve and assign users from other user directories, repeat Steps a-e .
9 Click Finish.
10 From the confirmation screen, select Create Another (to create another group) or select OK (to return to
the Browse tab).
Modifying Groups
You can modify the properties of all Native Directory groups except WORLD (the container for
all users and groups within Native Directory). If you remove a subgroup from a nested group,
the role inheritance of the subgroup is updated. Similarly, if you remove a user from a group,
the role inheritance of the user is updated.
Note:
You cannot modify the settings of the WORLD group.
Managing Native Directory
86
➤ To modify groups:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Native Directory node of the Object Palette, select Groups.
3 Search for a group. See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
A list of groups that meet the search criterion is displayed on the Browse tab.
4 Right-click a group, and select Properties.
The Group Properties screen is displayed.
Note:
The Group Properties screen displays the Managed By tab if Shared Services is deployed in
Delegated Administration mode.
5 If you want to modify general properties of the group, on the General tab, edit the name and description.
6 If you want to modify group assignments, open the Group Members tab and perform one or both actions:
a. To add groups to the group:
● In Search for Groups, enter the search criterion. Use * (asterisk) as the wildcard to
retrieve all groups.
● In Directory, select the user directory from which to retrieve groups.
● Click Go.
● From Available Groups, select one or more groups, and click Add.
Selected groups are listed in the Assigned Groups list. To remove a selected group,
from Assigned Groups, choose the group and click Remove. To undo all your actions
in this tab, click Reset.
● Optional: To retrieve and assign groups from other user directories, repeat this
procedure.
b. To remove groups from the group:
● From Assigned Groups, select one or more groups.
● Click Remove.
Removed groups are listed in the Available Groups list.
7 If you want to modify user assignments, open the User Members tab and perform one or both actions:
a. To add users to group:
● In Search for Users, enter the search criterion. Use * (asterisk) as the wildcard to
retrieve all available user accounts.
● In Directory, select the user directory from which to retrieve user accounts.
All configured user directories are listed in the Directory list.
● Click Go.
● From Available Users, select one or more users to assign to the group.
● Click Add.
The selected users are listed in Assigned Users list.
Managing Native Directory Groups
87
To remove an assigned user, from Assigned Users, select the user and click Remove.
To undo all your actions in this tab, click Reset.
● Optional: To retrieve and assign users from other user directories, repeat this
procedure.
b. To remove users from the group:
● From Assigned Users, select one or more users.
● Click Remove.
8 To view the delegated administrators assigned to the group, open the Managed By tab, which is available
only if Shared Services is deployed in Delegated Administration mode.
9 Click Save.
Deleting Groups
Deleting a group removes the group’s associations with users and roles and removes the group’s
information from Native Directory but does not delete the users or subgroups assigned to the
deleted group.
➤ To delete groups:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From the Object Palette, select Groups.
3 Search for the group to delete. See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
A list of groups that meets the search criterion is displayed on the Browse tab.
4 Right-click the group, and select Delete.
Managing Roles
Roles define the operations that users can perform in specific applications.
Application roles from all registered Hyperion applications can be viewed but not updated or
deleted from User Management Console. Tasks performed by Shared Services Administrators:
● “Creating Aggregated Roles” on page 89
● “Modifying Aggregated Roles” on page 90
● “Deleting Aggregated Roles” on page 90
● “Generating Provisioning Reports” on page 102
Managing Native Directory
88
Note:
You can provision newly created users and groups from LDAP-enabled user directories,
including MSAD. However, the roles provisioned to the new users and groups are available to
the users (become effective) only after Shared Services refreshes its cache. By default, the cache
refresh interval is set to 60 minutes, which can be modified. See “Overriding Cache Refresh
Interval for MSAD and other LDAP-Enabled User Directories” on page 58.
Creating Aggregated Roles
To facilitate administration and provisioning, Shared Services Administrators can create
aggregated roles that associate multiple product-specific roles with a custom Shared Services
role. Users with Shared Services Provisioning Manager role can create aggregated roles for the
product for which they are Provisioning Managers. Shared Services Administrators can create
aggregated roles for all Hyperion products.
For information on aggregated roles, see “Aggregated Roles” on page 17.
Note:
You can create roles only after at least one Hyperion application has been registered with Shared
Services.
➤ To create aggregated roles:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From the Object Palette, right-click Roles, and select New.
The Create Role screen is displayed.
3 For Name, enter a role name. Role names that contain special characters are not supported. Role names
should not start or end with a \ (backslash). See “Using Special Characters” on page 61 for more information.
4 Optional: For Description, enter a role description.
5 From Product Name, select the product for which to create the role.
This list includes all Hyperion applications registered with Shared Services.
6 Click Next.
7 On the Role Members tab, find the roles to add.
● To retrieve all roles from the selected application, click Go.
● To search for a role, enter the role name in Search for Roles and click Go. Use * (asterisk)
as the wildcard in pattern searches.
8 From Available Roles, select the application roles to assign.
9 Click Add.
The selected roles are listed in Assigned Roles list.
To remove a selected role, from Assigned Roles, select the role and click Remove. To undo all
your actions in this tab, click Reset.
10 Click Finish.
Managing Roles
89
Modifying Aggregated Roles
You can modify only aggregated roles; default application-specific roles cannot be modified
from Shared Services. You may change all role properties except the product name.
➤ To modify aggregated roles:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Object Palette, select Roles.
3 Retrieve an aggregated role. See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
4 Right-click the role, and select Properties.
The Role Properties screen is displayed.
5 If you want to modify general properties of the role, on the General tab, edit the name and description.
6 If you want to modify role member assignments, open the Role Members tab, and perform one or both
actions:
a. To add role members:
● Retrieve the roles to add.
❍ To retrieve all roles, click Go.
❍ To retrieve a specific role, enter the role name in Search for Roles and click Go.
Use * (asterisk) as the wildcard in pattern searches.
● From Available Roles, select one or more roles.
● Click Add. The selected roles are listed under Assigned Roles.
To remove a selected role, from Assigned Roles, select one or more roles and click
Remove. To undo your actions in this tab, click Reset.
b. To remove role assignments:
● From Assigned Roles, select one or more roles to remove.
● Click Remove.
7 Click Save.
Deleting Aggregated Roles
You can delete aggregated roles that are created from Shared Services. You cannot delete
application-specific roles.
➤ To delete aggregated roles:
Managing Native Directory
90
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 In the Object Palette, select Roles.
3 Retrieve an aggregated role.
See “Searching for Users, Groups, Roles, and Delegated Lists” on page 34.
A list of roles that meet the search criterion is displayed on the Browse tab.
4 Right-click a role, and select Delete.
5 In the confirmation dialog box, click OK.
Changing Native Directory root User Password
Shared Services Administrators can change the password of the Native Directory root user
account, which provides complete control over Native Directory. The default
hard-coded in a file and is not visible to users.
root, the most powerful Native Directory user account, provides complete control over Native
Directory. The password of the
provide an interface to change this password. To improve security, Shared Services provides a
screen to change the
encrypted version of the password in
restart Native Directory and Shared Services.
Note:
Only a user provisioned with Shared Services Administrator role can change the root password.
root password. If you update the password, Shared Services stores an
root user account is stored in a file. Native Directory does not
CSS.xml. The updated password takes effect after you
root password is
➤ To update Native Directory root password:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 From Administration, select Change Native Directory Password.
3 In Current Password, enter the existing root account password. This field is automatically populated if
the default password has not been changed previously.
4 In New Password and Confirm Password, enter the new password for root account.
5 Click Finish.
6 Restart Native Directory by restarting the Hyperion S9 OpenLDAP Windows service or UNIX process.
7 Restart Shared Services.
Backing Up the Native Directory Database
The Native Directory database must be backed up periodically to recover from loss of
provisioning data due to media failures, user errors, and unforeseen circumstances. Hyperion
recommends that you regularly back up this database.
Best Practices
Hyperion recommends monthly cold backups of the Native Directory database and Shared
Services repository. Perform hot backups daily to supplement the cold backups.
Changing Native Directory root User Password
91
● Schedule hot backups when database usage is at its lowest.
● Back up the Shared Services repository and Native Directory database at the same time so
that backup is in sync.
● Store backup for disaster recovery.
● Test backup and recovery procedures to ensure that the process works.
Hot Backup
Regular incremental backups of the Native Directory database can be performed without
shutting down Native Directory. Known as hot backups, they do not interfere with the
availability of Shared Services.
backup.bat (Windows) or backup.sh (UNIX) to schedule daily hot backups. This
Use
<
Hyperion-supplied backup file is stored in
<hss_version>
\server\scripts
scripts
(UNIX).
/server/scripts; for example C:\Hyperion\SharedServices\9.3.1
(Windows) or /vol1/Hyperion/SharedServices/9.3.1/server/
Hyperion_Home
See Hyperion Shared Services Installation Guide for information on the files and directories that
are backed up.
>/SharedServices/
Note:
This procedure backs up Shared Services configuration files and Native Directory.
➤ To run a hot backup:
1 Using a command prompt window, navigate to <
<hss_version>
/server/scripts.
Hyperion_Home
>/SharedServices/
2 Execute the following command.
● Windows: backup.bat <
● UNIX: backup.sh <
where
backup_directory
backup_directory
backup_directory
>
>
indicates the path of the directory where the backup is to be
stored.
3 Monitor the backup process to ensure that it runs successfully.
Cold Backup
Cold backups are performed after shutting down Native Directory.
Managing Native Directory
92
Note:
Data in the Native Directory database is synchronized with the data available in the Shared
Services repository. Hyperion recommends that you back up the Shared Services repository
along with the Native Directory database.
➤ To back up Native Directory database:
1 Stop Native Directory service or process.
2 Copy <openLDAP_Home> into a secure location.
Synchronizing Native Directory Database with the Shared Services Repository
The database configured with Shared Services stores information related to product registration.
The Native Directory database contains provisioning data for all products. These databases work
in tandem to support Hyperion products.
Data inconsistencies between the databases impact normal operations. Inconsistencies could
occur during manual database update or database upgrades or in replicated Native Directory
environments in which the Native Directory slave has taken over for a failed Native Directory
master. (See “Setting Up Native Directory for High Availability and Failover” on page 94 for
detailed information on Native Directory replication.)
To remove inconsistencies, the Native Directory database must be synchronized with the Shared
Services database. The synchronization process uses the Shared Services database as the master
database to resolve data inconsistencies.
Messages (errors as well as information) related to the operation are recorded in the
SharedServices_syncOpenLDAP.log file. See Chapter 10, “Troubleshooting.”
➤ To synchronize the Native Directory database with the Shared Services repository:
1 Launch User Management Console, as explained in “Launching User Management Console” on page 33.
2 Select Administration > Sync Native Directory.
The Sync Native Directory tab displays the status of the synchronization operation.
3 Optional: Click Refresh to update the status.
4 Optional: Click View Log to display a log file that details the operations that were performed during the
synchronization process.
Recovering Native Directory Data
To enable SSO and provisioning, Native Directory must be running. If Native Directory service
(Windows) or process (UNIX) fails, causing Native Directory to crash, you must recover the
provisioning data before users can access Hyperion products, including Shared Services.
Synchronizing Native Directory Database with the Shared Services Repository
93
➤ To recover provisioning data after a Native Directory crash:
1 Verify that the Native Directory service (Windows) or process (UNIX) is not running.
2 Open a command prompt (Windows) or console (UNIX) window.
3 Navigate to
\<HSS_version>
<HSS_version>/openLDAP/bdb/bin
<openLDAP_Home>\bdb\bin
\openLDAP\bdb\bin (Windows) or <Hyperion_Home>/SharedServices/
. For example,
(UNIX)
<Hyperion_Home>\SharedServices
4 Run the db_recover utility, using the following command:
db_recover –h <
Path_Native_Directory_data_file
>
For example, db_recover –h ../../var/openldap-data
Where openldap-data indicates the name of Native Directory data file.
5 Monitor the utility to ensure that it runs successfully.
6 Restart the Hyperion S9 OpenLDAP service or process.
7 On the application server, restart Shared Services.
Setting Up Native Directory for High Availability and Failover
Native Directory high availability and failover can be achieved through various scenarios.
● “Out of the Box Deployment” on page 94
● “Cold Standby Deployment” on page 96
● “Hot Standby Deployment” on page 98
Out of the Box Deployment
The out of the box failover scenario involves establishing a master-slave relationship between
two fully synchronized installations of Native Directory running on separate machines.
➤ To set up a replicated Native Directory environment:
1 Install and configure Shared Services on two server machines (for example, machine1 and machine2).
Managing Native Directory
94
See the Hyperion Shared Services Installation Guide for instructions.
2 On the server machines, stop the Hyperion S9 OpenLDAP service or process.
3 On the master server (for example, machine1), create a directory (for example, C:\OpenLDAP\logs
in Windows or /apps/OpenLDAP/logs in UNIX) to store the replication log files.
4 On the master server, update the <
● replica directive.
replica uri=ldap://<
binddn= “cn=Replicator,dc=css,dc=hyperion,dc=com”
bindmethod=simple credentials=security
Where
machine2). You can use the IP address of the slave host instead of the DNS name. You must
<slave_host_name>
specify one replica directive for each slave.
Caution!
The second and third lines of the replica directive must be preceded by at least one white
space, to denote that the line is a continuation of the previous line.
● replogfile directive:
replogfile
<path_to_sldap.replog>
Examples:
❍ replogfile C:\\OpenLDAP\\logs\\sldap.replog (Windows)
openLDAP_Home
slave_host_name
>\slapd.conf file with the following directives.
>:58089
is the name of the slave host machine (for example,
❍ replogfile /apps/OpenLDAP/logs/sldap.replog (UNIX)
5 On the slave server (for example, machine2), update the
<HSS_home>
\openLDAP\slapd.conf file:
a. Add an updatedn entry.
The values and the
Example:
updatedn=”cn=Replicator,dc=css,dc=hyperion,dc=com”
binddn entry (in the master slapd.conf file) must be the same.
b. Add the following updateref entry that provides the URI to the Native Directory master.
updateref “ldap://
<master_host_name>
”
For example, updateref “ldap://machine1”.
You can use IP address instead of the DNS name; for example,
192.168.167.166”
updateref “ldap://
c. Update the rootdn value to be identical to the updatedn (replicator) value:
rootdn “cn=Replicator,dc=css,dc=hyperion,dc-com”
6 Copy Native Directory data from the master server to the slave server .
The default location of Native Directory data is <
7 On the master server, update the CSS.xml file, which is located in the
openLDAP_Home
<HSS_home>
>/var/OpenLdap-data.
\config.
Setting Up Native Directory for High Availability and Failover
95
You should include the following slave definition immediately after the <native
name=”Native Directory”>
<slaves>
<slave>
declaration:
<url>ldap://
<type>failover</type>
</slave>
</slaves>
Where
<slave_host_name>
<slave_host_name>
is the name of the slave server machine and 58089 is the Native
:58089</url>
Directory port.
8 On the master server and then on the slave server, start the Hyperion S9 OpenLDAP service or process.
9 On the master server, start the slurpd replication service or process by performing an action:
● On Windows, execute the following command from a command prompt window.
<
openLDAP_Home
>\slurpd -f
<master_slapd_config_file>
Example: C:\Hyperion\SharedServices\9.3.1\OpenLdap\slurpd -f
slapd.conf
● On UNIX, execute the following command after navigating to <
local/libexec
./slurpd -f <
<openLDAP_Home>
:
openLDAP_Home
/usr/local/var/openldap-slurp —d 1
>/usr/local/etc/openldap/slapd.conf -t
openLDAP_Home
>/usr/
Example: ./slurpd -f /var/Hyperion/SharedServices/9.3.1/openLDAP/ usr/
local/etc/openldap/slapd.conf -t /app/Hyperion/SharedServices/9.3.1/
openLDAP/usr/local/var/openldap-slurp —d 1
Managing Native Directory
96
Note:
slurpd
must always be running to synchronize data between the master and slave servers.
Cold Standby Deployment
In cold standby deployment (see following illustration), the primary environment consists of
Shared Services (1) including Native Directory (2) and one or more Hyperion products (3). The
standby environment consists of an inactive Native Directory (5) instance. The instances in
primary and standby environments connect to a Native Directory database (6) hosted on the
same physical hard drive that is dual attached to the primary and standby environments.
This deployment uses a hardware load balancer (4) to perform these tasks:
● Detect the failure of the Native Directory instance in the primary environment
● Start the Native Directory service (Windows) or process (UNIX) in the standby environment
● Route all requests to the standby Native Directory instance
Note:
Native Directory in the standby environment handles all calls until the primary environment is
brought back online and the load balancer is configured to route calls to the primary
environment.
➤ To deploy Native Directory for failover in cold standby mode:
1 Install Shared Services in the primary and standby environments. Refer to the Hyperion Shared Services
Installation Guide for instructions.
2 Configure and deploy Shared Services in the primary environment.
You need not configure or deploy Shared Services in the standby environment.
3 Verify that Hyperion S9 OpenLDAP service or process is running in the primary and secondary
environments.
4 Stop the Hyperion S9 OpenLDAP service or process in the secondary environment.
5 Move Native Directory data to the shared drive or volume. This drive or volume must be visible to the computers
hosting Native Directory instances in primary and secondary environments.
a. Create the var/openldap-data directory structure to store Native Directory data.
<
b. Move the contents of
environment to the
openLDAP_Home
var/openldap-data directory on the shared drive or volume.
>/var/openldap-data from the primary
6 Modify slapd.conf in both primary and secondary environments.
a. Using a text editor, open <
b. Modify the
directory parameter so that it points to the directory where Native Directory
openLDAP_Home
>/slapd.conf.
data is stored on the shared drive.
c. Save and close the files.
7 Configure the load balancer and monitoring application.
Setting Up Native Directory for High Availability and Failover
97
The load balancer must host a monitoring application capable of checking if Native Directory
is running in the primary environment. This can be achieved by using the LDAP ping mechanism
or by using corporate process monitoring tools (for example, Tivoli and UniCenter).
a. Configure the monitoring application to perform these tasks:
● Use the following directive (embedded in a batch or shell file) to look for an active
Native Directory instance in the primary environment.
ldapsearch –H
myserver:58089/dc=css,dc=example,dc=com cn=*
● Using the following command, start Native Directory in the standby environment if
ldapurl
cn=*. For example, ldapsearch –H ldap://
Native Directory is not active in the primary environment. You must create custom
scripts to start Native Directory.
net start “Hyperion S9 OpenLDAP” (Windows).
b. Configure the load balancer to reroute all requests to the standby environment upon
detecting a failure in the primary environment. You can use DNS name or IP address
redirection for this purpose. See documentation from the load balancer vendor for
information on how to complete this step.
8 Start Hyperion S9 OpenLDAP service or process on primary and standby environments.
9 Test your deployment.
A simple test would be to stop the Hyperion S9 OpenLDAP service or process in the primary
environment. The monitoring application on the load balancer should restart the process or
service in the standby environment.
Hot Standby Deployment
In hot standby deployment (see following illustration), the primary environment consists of
Shared Services (1) including Native Directory (2), and one or more Hyperion products (3).
The standby environment consists of an active Native Directory (5) instance. Each Native
Directory instance connects to its own database (6). A sync agent (7) backs up Native Directory
in the primary environment and updates it in the standby environment to synchronize the
databases at scheduled intervals.
The sync agent is not a part of Hyperion software distribution. The sync agent is similar to a
corporate scheduling agent or workflow tool that enables executing and monitoring jobs.
Customers must use their own sync agent to initiate backup and restore processes.
Hot Standby Deployment uses a hardware load balancer (4) to perform these tasks:
● Detect the failure of the Native Directory instance in the primary environment
● Route all requests to the standby Native Directory instance upon detecting a failed instance
in the primary environment.
Managing Native Directory
98
Note:
Native Directory in the standby environment handles all calls until the primary environment is
brought back online and the load balancer is configured to route calls to the primary
environment.
➤ To deploy Native Directory for failover in hot standby mode:
1 Install Shared Services in the primary and standby environments.
Refer to the Hyperion Shared Services Installation Guide for instructions.
2 Configure and deploy Shared Services in the primary environment.
You need not configure or deploy Shared Services in the standby environment.
3 Verify that Hyperion S9 OpenLDAP service or process is running in the primary and secondary
environments.
4 Configure the process monitoring application with the following directive to check if Native Directory service
(Windows) or process (UNIX) is running in the primary environment:
ldapsearch –H
58089/dc=css,dc=example,dc=com cn=*
ldapurl
cn=*. For example, ldapsearch –H ldap://myserver:
5 Configure the load balancer to reroute all requests to the standby environment on detecting a failure in the
primary environment.
You can use DNS name or IP address redirection for this purpose. See documentation from the
load balancer vendor for information on how to complete this step.
6 Configure the sync agent (scheduler) to back up Native Directory data from the primary environment and to
update the standby environment.
7 Test the configuration.
Migrating Native Directory
The Native Directory database stores security-related data. You must migrate Native Directory
data as a part of migrating Shared Services. See Hyperion Shared Services Installation Guide for
Migrating Native Directory
99
details. Migration is the process of copying an application instance from one operating
environment to another; for example, from development to testing or from testing to
production.
You use the Import/Export utility to migrate Native Directory.
➤ To migrate Native Directory:
1 On the computer that hosts the source Shared Services server, perform the following actions:
a. Install the Import/Export utility. See “Installing the Import/Export Utility” on page 106.
b. Create the
importexport.properties file. “Preparing the Property File” on page
107.
c. Execute the Import/Export utility to export Native Directory data into an export file. See
“Running the Utility” on page 113.
d. Verify that the export file has been created.
2 On the computer that hosts the target Shared Services server, perform the following actions:
a. Stop Hyperion Shared Services OpenLDAP service or process.
b. Back up
\opneLDAP
openLDAP_Home
(Windows) or /app/Hyperion/SharedServices/9.3.1/openLDAP
>, for example, C:\Hyperion\SharedServices\9.3.1
<
(UNIX).
c. Back up the Shared Services repository.
d. Copy the export file from the computer that hosts the source Shared Services server.
e. Install the Import/Export utility. See “Installing the Import/Export Utility” on page 106.
f. Create the
importexport.properties file or copy it from the computer that hosts the
source Shared Services server. Ensure that the export file name matches the value of
import.file property. See “Preparing the Property File” on page 107.
g. Validate the export file. If any errors are indicated, fix them and validate the export file
again until it is error free.
Managing Native Directory
100
h. Execute the Import/Export utility to import Native Directory data from the export file.
See “Running the Utility” on page 113.
Loading...