Novell IDENTITY MANAGER Installation Guide
Novell®
www.novell.com
Installation Guide
Identity Manager
novdocx (en) 17 September 2009
AUTHORIZED DOCUMENTATION
3.6.1
January 05, 2010
Identity Manager 3.6.1 Installation Guide
Legal Notices
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities
on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export
laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses.
Please refer to the International Trade Services (http://www.novell.com/company/policies/trade_services) for more
information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary
export approvals.
novdocx (en) 17 September 2009
Copyright © 2007-2010 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or
more additional patents or pending patent applications in the U.S. and in other countries.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the latest online documentation for this and other Novell products, see
the Novell Documentation Web page (http://www.novell.com/documentation).
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/
trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
novdocx (en) 17 September 2009
novdocx (en) 17 September 2009
4 Identity Manager 3.6.1 Installation Guide
Contents
About This Guide 9
Part I Planning 11
1 Setting Up a Development Environment 13
2 Creating a Project Plan 15
2.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Defining Current Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Defining How the Identity Manager Solution Affects the Current Business
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Identifying the Key Business and Technical Stakeholders . . . . . . . . . . . . . . . . . . . . 18
2.1.4 Interviewing All Stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5 Creating a High-level Strategy and an Agreed Execution Path . . . . . . . . . . . . . . . . . 18
2.2 Requirements and Design Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Define the Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Analyze Your Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.3 Design an Enterprise Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Data Validation and Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Production Pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Production Rollout Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Production Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
novdocx (en) 17 September 2009
3 Technical Guidelines 27
3.1 Management Tools Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.1 Designer Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.2 iManager Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Metadirectory Server Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 eDirectory Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Identity Manager Objects in eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Replicating the Objects that Identity Manager Needs on the Server . . . . . . . . . . . . . 31
3.3.3 Using Scope Filtering to Manage Users on Different Servers . . . . . . . . . . . . . . . . . 32
3.4 User Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Auditing and Reporting Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Part II Installation 37
4 Basic Identity Manager System Checklist 39
4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Driver Configuration with the Remote Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Driver Configuration without the Remote Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Additional Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Contents 5
5 Where to Get Identity Manager 43
6 System Requirements 45
6.1 eDirectory and iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Metadirectory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1 Supported Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.2 Server Operating Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Remote Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4 User Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5 Auditing and Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.6 Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.1 Workstation Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6.2 iManager and Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7 Installing Identity Manager 55
7.1 Installing Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Installing the Metadirectory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2.1 Nonroot Installation of the Metadirectory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2.2 Silent Installation of the Metadirectory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Installing the Remote Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.2 Supported Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.3 Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3.4 Silent Installation of the Remote Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.5 Installing the Java Remote Loader on UNIX, Linux, or AIX . . . . . . . . . . . . . . . . . . . . 63
7.4 Installing the Roles Based Provisioning Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.5 Installing a Custom Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.6 Installing Identity Audit or Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.7 Installing Identity Manager in Clustering Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
novdocx (en) 17 September 2009
8 Activating Novell Identity Manager Products 65
8.1 Purchasing an Identity Manager Product License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.2 Installing a Product Activation Credential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3 Viewing Product Activations for Identity Manager and for Drivers . . . . . . . . . . . . . . . . . . . . . . 66
9 Troubleshooting Identity Manager 67
Part III Upgrading 69
10 What’s New 71
10.1 Support for 64-Bit Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.2 Support for 32-Bit Remote Loader Installation on 64-Bit Operating Systems . . . . . . . . . . . . . 71
10.3 Identity Manager Driver for SAP Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.4 Updated Identity Manager Driver for SAP HR and Identity Manager Driver for SAP User
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
11 Supported Versions for Upgrades and System Requirements 73
11.1 Supported Versions for Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Identity Manager 3.6.1 Installation Guide
11.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12 In-place Upgrade Versus Migration 75
12.1 In-place Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.2 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.3 Multiple Servers Associated with a Single Driver Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
13 Performing an In-place Upgrade 77
13.1 Creating a Backup of the Current Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1.1 Ensuring that Your Designer Project is Current. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1.2 Creating an Export of the Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.2 Stopping the Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.2.1 Using Designer to Stop the Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.2.2 Using iManager to Stop the Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.3 Adding Files to the Correct Location on Linux/UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . 82
13.4 Upgrading Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.5 Upgrading the Metadirectory Engine and Driver Configuration Files . . . . . . . . . . . . . . . . . . . . 83
13.6 Upgrading the Remote Loader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.7 Overlaying the New Driver Configuration File over the Existing Driver . . . . . . . . . . . . . . . . . . 84
13.7.1 Using Designer to Overlay the New Driver Configuration File over the Existing
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7.2 Using iManager to Overlay the New Driver Configuration File over the Existing
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.8 Restoring Custom Policies and Rules to the Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.8.1 Using Designer to Restore Custom Policies and Rules to the Driver . . . . . . . . . . . . 85
13.8.2 Using iManager to Restore Custom Policies and Rules to the Driver . . . . . . . . . . . . 86
13.9 Deploying the Converted Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.10 Starting the Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.10.1 Using Designer to Start the Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.10.2 Using iManager to Start the Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
novdocx (en) 17 September 2009
14 Performing a Migration 89
14.1 Adding the New Server to the Driver Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.2 Changing Server-Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.2.1 Changing the Server-Specific Information in Designer . . . . . . . . . . . . . . . . . . . . . . . 91
14.2.2 Changing the Server-Specific Information in iManager . . . . . . . . . . . . . . . . . . . . . . . 91
14.3 Removing the Old Server from the Driver Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.3.1 Using Designer to Remove the Old Server from the Driver Set. . . . . . . . . . . . . . . . . 92
14.3.2 Using iManager to Remove the Old Server from the Driver Set . . . . . . . . . . . . . . . . 92
14.3.3 Decommissioning the Old Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Part IV Uninstalling Identity Manager 95
15 Removing Objects from eDirectory 97
16 Uninstalling the Metadirectory Server and Drivers 99
16.1 Uninstalling on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
16.2 Uninstalling on Linux/UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Contents 7
17 Uninstalling Designer 101
A Documentation Updates 103
A.1 July 31, 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.1.1 What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
novdocx (en) 17 September 2009
8 Identity Manager 3.6.1 Installation Guide
About This Guide
Novell® Identity Manager is a data sharing and synchronization service that enables applications,
directories, and databases to share information. It links scattered information and enables you to
establish policies that govern automatic updates to designated systems when identity changes occur.
Identity Manager provides the foundation for account provisioning, security, single sign-on, user
self-service, authentication, authorization, automated workflow, and Web services. It allows you to
integrate, manage, and control your distributed identity information so you can securely deliver the
right resources to the right people.
This guide contains information about how to plan, install, or upgrade an Identity Manager system
that is useful for your environment.
Part I, “Planning,” on page 11
Chapter 2, “Creating a Project Plan,” on page 15
Chapter 3, “Technical Guidelines,” on page 27
Part II, “Installation,” on page 37
novdocx (en) 17 September 2009
Chapter 4, “Basic Identity Manager System Checklist,” on page 39
Chapter 5, “Where to Get Identity Manager,” on page 43
Chapter 6, “System Requirements,” on page 45
Chapter 7, “Installing Identity Manager,” on page 55
Chapter 8, “Activating Novell Identity Manager Products,” on page 65
Part III, “Upgrading,” on page 69
Chapter 10, “What’s New,” on page 71
Chapter 11, “Supported Versions for Upgrades and System Requirements,” on page 73
Chapter 12, “In-place Upgrade Versus Migration,” on page 75
Chapter 13, “Performing an In-place Upgrade,” on page 77
Chapter 14, “Performing a Migration,” on page 89
Part IV, “Uninstalling Identity Manager,” on page 95
Chapter 15, “Removing Objects from eDirectory,” on page 97
Chapter 16, “Uninstalling the Metadirectory Server and Drivers,” on page 99
Audience
This guide is intended for administrators, consultants, and network engineers who plan and
implement Identity Manager in a network environment.
Documentation Updates
For the most recent version of this document, see the Identity Manager Documentation Web site
(http://www.novell.com/documentation/idm361/index.html).
About This Guide 9
Additional Documentation
For additional Identity Manager documentation, see the Identity Manager Documentation Web site
(http://www.novell.com/documentation/idm361/index.html).
For User Application documentation, see the Identity Manager Roles Based Provisioning Module
Documentation Web site (http://www.novell.com/documentation/idmrbpm361/index.html).
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.
®
A trademark symbol (
, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.
When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux* or UNIX*, should use forward slashes as required by your software.
novdocx (en) 17 September 2009
10 Identity Manager 3.6.1 Installation Guide
I
Planning
Identity Manager helps you manage the identities and resources in your business. It also automates
many business processes for you that are currently manual tasks.
If you have any questions about the different components that make up an Identity Manager
solution, see the Identity Manager 3.6.1 Overview guide for more information about each
component.
To create an effective Identity Manager solution for your environment, you first must take time to
plan and design your Identity Manager solution. There are two major aspects to planning: setting up
a test lab to become familiar with the products and creating a project plan to implement an Identity
Manager solution. When you create a project plan, you define your business process and create an
implementation plan. Most companies have many different business processes that are managed by
many different people. A complete Identity Manager solution affects most of these processes. It is
extremely important to take the time to plan an Identity Manager solution, so that it can be
effectively implemented in your environment.
novdocx (en) 17 September 2009
We strongly recommend that an Identity Manager expert be engaged to assist in each phase of your
Identity Manager implementation. For more information about partnership options, see the Novell
®
Solution Partner Web site (http://www.novell.com/partners/). Novell Education also offers courses
that address Identity Manager implementation.
Chapter 1, “Setting Up a Development Environment,” on page 13
Chapter 2, “Creating a Project Plan,” on page 15
Chapter 3, “Technical Guidelines,” on page 27
PlanningI11
novdocx (en) 17 September 2009
12 Identity Manager 3.6.1 Installation Guide
1
Setting Up a Development
novdocx (en) 17 September 2009
Environment
Before you begin the planning phase of the Identity Manager deployment, you must be familiar with
the Identity Manager products so you can create a useful plan. Setting up a development
environment where you can test, analyze, and develop your Identity Manager solution allows you to
learn about each component of Identity Manager and find unforeseen issues and complications that
can arise.
For example, when you synchronize information between different systems, the information is
presented differently for each system. Changing the data to synchronize between these two systems,
allows you to see if this change affects other systems that use this same information.
The other major reason to set up a development environment is to make sure your solutions work,
without affecting live data. Identity Manager manipulates data, which includes deleting data. Having
the test environment allows you to make changes without any loss to the data in your production
environment.
You should set up a development environment for each deployment of Identity Manager. Each
deployment is different. There are different systems, business policies, and procedures that need to
be included in the Identity Manager solution. The development environment allows you to create the
solution that is best for each situation.
The most important tool to use when you are developing your Identity Manager solution is Designer.
It allows you to capture all of the information about your environment and then use that information
to create an Identity Manager solution that fits your needs. Use Designer during all aspects of the
planning to capture all of the information. Designer makes it much easier to create a project plan that
includes the business information as well as the technical information. For more information about
Designer, see Designer 3.5 for Identity Manager 3.6 Administration Guide.
1
To set up your development environment, use the information in Chapter 4, “Basic Identity Manager
System Checklist,” on page 39. It is an installation checklist of all of the Identity Manager
components. Use this to make sure you have installed and configured all components for Identity
Manager that you can use to develop a project plan. Use the information in Chapter 3, “Technical
Guidelines,” on page 27 as you set up your development environment, so you can learn about the
technical considerations as you install and configure each component of Identity Manager.
After your development environment is created, the next step is to create the project plan to
implement the Identity Manager solution. Use the information in Chapter 2, “Creating a Project
Plan,” on page 15 to create the project plan.
Setting Up a Development Environment
13
novdocx (en) 17 September 2009
14 Identity Manager 3.6.1 Installation Guide
2
Creating a Project Plan
This planning material provides an overview of the type of activities that are usually part of an
Identity Manager project, from its inception to its full production deployment. Implementing an
identity management strategy requires you to discover what all of your current business processes
are, what are the needs for these processes, who the stakeholders are in your environment, and then
design a solution, get buy-in from stakeholders, and test and roll out the solution. This section is
intended to provide you with sufficient understanding of the process so that you can maximize the
benefit from working with Identity Manager.
This section is not exhaustive; it is not intended to address all possible configurations, nor is it
intended to be rigid in its execution. Each environment is different and requires flexibility in the type
of activities to be used.
Section 2.1, “Discovery Phase,” on page 15
Section 2.2, “Requirements and Design Analysis Phase,” on page 19
Section 2.3, “Proof of Concept,” on page 23
novdocx (en) 17 September 2009
2
Section 2.4, “Data Validation and Preparation,” on page 23
Section 2.5, “Production Pilot,” on page 24
Section 2.6, “Production Rollout Planning,” on page 24
Section 2.7, “Production Deployment,” on page 25
2.1 Discovery Phase
The Identity Manager solution affects many aspects of your business. In order to create an effective
solution, you must take time to define all of your current business processes, then identify how an
implementation of Identity Manager changes these processes, who these changes affect, and how the
changes are implemented.
The discovery phase provides a common understanding of the issues and solutions for all
stakeholders. It creates a plan or road map that contains the key business and systems information
that are affected by the Identity Manager solution. It also allows all stakeholders to participate in the
creation of the Identity Manager solution so they understand how it can affect their area of the
business.
The following list indicates the steps needed to have a successful discovery phase. There might be
additional items you find that you need to add to the list as you proceed through the discovery and
design phases.
Section 2.1.1, “Defining Current Business Processes,” on page 16
Section 2.1.2, “Defining How the Identity Manager Solution Affects the Current Business
Processes,” on page 17
Section 2.1.3, “Identifying the Key Business and Technical Stakeholders,” on page 18
Section 2.1.4, “Interviewing All Stakeholders,” on page 18
Section 2.1.5, “Creating a High-level Strategy and an Agreed Execution Path,” on page 18
Creating a Project Plan
15
2.1.1 Defining Current Business Processes
Identity Manager automates business processes to easily manage identities in your environment. If
you do not know what the current business processes are, you cannot design an Identity Manager
solution that automates those processes. You can use the Architecture mode of Designer to capture
your current business processes and display them graphically. For more information, see the
“Architect Mode” in Designer 3.5 for Identity Manager 3.6 Administration Guide.
Here are a few business process examples:
When an employee is terminated, the user account in the e-mail system is deleted, but the
user’s account in all other systems is disabled, not deleted.
The format for a user’s e-mail address.
What systems or resources sales employees can access.
What systems or resources managers can access.
What systems generate new accounts? Is it the human resource system or is it through a
workflow request?
A password policy for the company that defines how often a password changes, how complex
the password is, and which systems are synchronizing the password.
novdocx (en) 17 September 2009
As you define your business processes, use the following list of items to help you understand all of
the processes:
Define or clarify the current business issues.
Determine what initiatives are required to address these issues.
Determine which services and systems are affected by these initiatives.
This step allows you to create a high-level overview of what your business is currently doing and
what processes need to be improved. For example, Figure 2-1 is from Designer it shows that new
user accounts are generated from the PeopleSoft* system. They are synchronized into the Identity
Vault and then synchronized into Lotus Notes* and Active Directory*. Passwords are being
synchronized between Active Directory and the Identity Vault. Accounts are synchronizing into the
Notes system, but no accounts are synchronizing back to the Identity Vault.
16 Identity Manager 3.6.1 Installation Guide
Figure 2-1 Example of Business Processes
novdocx (en) 17 September 2009
The next step is in Section 2.1.2, “Defining How the Identity Manager Solution Affects the Current
Business Processes,” on page 17.
2.1.2 Defining How the Identity Manager Solution Affects the Current Business Processes
After you have defined your current business processes, you need to decide which processes you
want to incorporate into an Identity Manager solution.
It is best to look at the entire solution and then prioritize which processes should be implemented.
Identity Manager encompasses so many aspects of your business, it is easier to plan the entire
solution rather than approach each business process as its own solution.
Create a list of which business processes are a priority to automate, then identify which systems
these changes will affect. The next step is in Section 2.1.3, “Identifying the Key Business and
Technical Stakeholders,” on page 18.
Creating a Project Plan 17
2.1.3 Identifying the Key Business and Technical Stakeholders
Identifying all stakeholders involved in the Identity Manager solution is important for the success of
the solution. In most companies, there is not just one person you can contact who understands all
business and technical aspects of the business processes. You must identify which services and
systems are going to be affected by the Identity Manager solution, and you must also identify the
person who is responsible for that service or system.
For example, if you are integrating an e-mail system into your solution, you would need to list what
the e-mail system is, who the e-mail system administrator is, and what the contact information is.
You can add all of this information into the Designer project. Each application icon has a place
where you can store information about the system and the system administrator. For more
information, see “Configuring Application Properties” in Designer 3.5 for Identity Manager 3.6
Administration Guide.
After you have identified all of the people involved in each business process, the next step is in
Section 2.1.4, “Interviewing All Stakeholders,” on page 18.
2.1.4 Interviewing All Stakeholders
novdocx (en) 17 September 2009
Interviews with key business and technical stakeholders allow you to gather information needed for
a complete design of the Identity Manager solution. The interviews also allow you to educate each
stakeholder about the Identity Manager solution and how the solution affects them. Here is a list of
items to cover when you do the interviews:
Define or clarify the business processes being addressed by the Identity Manager solution. The
person you are interviewing might have information that can change the current plan.
Determine how the solution will impact the stakeholders and address any concerns they have.
Also ask the stakeholders how much time their part of the solution might take. They might or
might not have an estimate, but gathering this information helps to determine the scope of the
solution.
Capture key business and systems information from the stakeholders. Sometimes a proposed
plan might adversely affect a business process or a system. By capturing this information, you
can make educated decisions about the Identity Manager solution.
After you have interviewed the key stakeholders, the next step is in Section 2.1.5, “Creating a High-
level Strategy and an Agreed Execution Path,” on page 18.
2.1.5 Creating a High-level Strategy and an Agreed Execution Path
After all of the information is gathered, you need to create a high-level strategy or road map for the
Identity Manager solution. Add all of the features you want to be included in the Identity Manager
solution. For example, new user accounts are generated from a request through a workflow, but the
type of user depends upon the resources the user is given access to.
Present this high-level strategy to all of the stakeholders in the same meeting, if possible. This
allows you to:
Verify that the included initiatives are the most correct and identify which ones have the
highest priority.
18 Identity Manager 3.6.1 Installation Guide
Identify planning activities in preparation for a requirements and design phase
Determine what it would take to carry out one or more of these initiatives.
Create an agreed execution path for the Identity Manager solution.
Define additional education for stakeholders.
Discovery provides a common understanding of the issues and solutions for all stakeholders. It
provides an excellent primer for the analysis phase-- a phase that requires stakeholders to have a
basic knowledge of directories, Novell
integration in general.
After you have completed the discovery phase, proceed to the Section 2.2, “Requirements and
Design Analysis Phase,” on page 19.
®
eDirectoryTM, Novell Identity Manager, and XML
2.2 Requirements and Design Analysis Phase
Take the high-level road map that was created in the discovery phase as a starting point for this
analysis phase. The document and the Designer project both need technical and business details
added. This produces the data model and high-level Identity Manager architecture design used to
implement the Identity Manager solution.
novdocx (en) 17 September 2009
The focus of the design should be specifically on identity management; however, many of the
elements traditionally associated with a resource management directory, such as file and print, can
also be addressed. Identity Manager synchronizes user accounts to directories that do not have direct
access to the operating system’s file system. For example, you can have a user account in Active
Directory, but that does not grant you access to the file system on the Active Directory server.
Using the information gathered in the discovery phase, answer the following sample questions to see
what other information needs to be gathered. This might require additional interviews with
stakeholders.
What versions of system software are being used?
Is the eDirectory design appropriate? For example, does the Identity Manager server contain a
Master or Read/Write replica of the user objects that are synchronizing? If it does not, the
eDirectory design is not appropriate.
Is the quality of the data in all systems appropriate? (If the data is not of usable quality, the
business policy might not be implemented as desired.) For example, there might be duplicate
accounts for the users in the systems that are synchronizing, or the format of the data might not
be consistent throughout each system. Each system’s data must be evaluated before
information is synchronized.
Is data manipulation required for your environment? For example, a user’s hire date format in
the human resource system can only be 2008/02/23 and the hire date in the Identity Vault is 0223-2008. This requires that the date be manipulated for synchronization to occur.
Review the information in Chapter 3, “Technical Guidelines,” on page 27 to help make the correct
decisions for your environment.
Creating a Project Plan 19
After the requirements analysis, you can establish the scope and project plan for the implementation,
and determine if any prerequisite activities need to occur. To avoid costly mistakes, be as complete
as possible in gathering information and documenting requirements. Here is a list of possible
requirements:
Data model showing all systems, authoritative data sources, events, information flow, data
format standards, and mapping relationships between connected systems and attributes within
Identity Manager.
Appropriate Identity Manager architecture for the solution.
Details for additional system connection requirements.
Strategies for data validation and record matching.
Directory design to support the Identity Manager infrastructure.
The following tasks should be completed during the requirements and design assessment:
“Define the Business Requirements” on page 20
“Analyze Your Business Processes” on page 21
“Design an Enterprise Data Model” on page 22
novdocx (en) 17 September 2009
2.2.1 Define the Business Requirements
In the discovery phase, you gathered your organization’s business processes and the business
requirements that define these business processes. Create a list of these business requirements and
then start mapping these processes in Designer by completing the following tasks:
Create a list of the business requirements and determine which systems are affected by this
process. For example, a business requirement for terminating an employee might be that the
employee’s network and e-mail account access must be removed the same day the employee is
terminated. The e-mail system and the Identity Vault are affected by this termination process.
Establish the process flows, process triggers, and data mapping relationships.
For example, if something is going to happen in a certain process, what will happen because of
that process? What other processes are triggered?
Map data flows between applications. Designer allows you to see this information. For more
information, see “Managing the Flow of Data” in Designer 3.5 for Identity Manager 3.6
Administration Guide.
Identify data transformations that need to take place from one format to another, such as 2/25/
2007 to 25 Feb 2007.
Document the data dependencies that exist.
If a certain value is changed, it is important to know if there is a dependency on that value. If a
particular process is changed, it is important to know if there is a dependency on that process.
For example, selecting a “temporary” employee status value in a human resources system
might mean that the IT department needs to create a user object in eDirectory with restricted
rights and access to the network during certain hours.
List the priorities.
Not every requirement, wish, or desire of every party can be immediately fulfilled. Priorities
for designing and deploying the provisioning system will help plan a road map.
20 Identity Manager 3.6.1 Installation Guide
It might be advantageous to divide the deployment into phases that enable implementation of a
portion of the deployment earlier and other portions of the deployment later. You can do a
phased deployment approach as well. It should be based on groups of people within the
organization.
Define the prerequisites.
The prerequisites required for implementing a particular phase of the deployment should be
documented. This includes access to the connected systems that you are wanting to interface
with Identity Manager.
Identify authoritative data sources.
Learning early on which items of information system administrators and managers feel belong
to them can help in obtaining and keeping buy-in from all parties.
For example, the account administrator might want ownership over granting rights to specific
files and directories for an employee. This can be accommodated by implementing local trustee
assignments in the account system.
After you have defined your business requirements, proceed to Section 2.2.2, “Analyze Your
Business Processes,” on page 21.
novdocx (en) 17 September 2009
2.2.2 Analyze Your Business Processes
After completing the analysis of your business requirements, there is more information you need to
gather to help focus the Identity Manager solution. You need to interview essential individuals such
as managers, administrators, and employees who actually use the application or system. Issues to be
addressed include:
Where does the data originate?
Where does the data go?
Who is responsible for the data?
Who has ownership for the business function to which the data belongs?
Who needs to be contacted to change the data?
What are all the implications of the data being changed?
What work practices exist for data handling (gathering and/or editing)?
What types of operations take place?
What methods are used to ensure data quality and integrity?
Where do the systems reside (on what servers, in which departments)?
What processes are not suitable for automated handling?
For example, questions that might be posed to an administrator for a PeopleSoft system in Human
Resources could include:
What data are stored in the PeopleSoft database?
What appears in the various panels for an employee account?
What actions are required to be reflected across the provisioning system (such as add, modify,
or delete)?
Which of these are required? Which are optional?
What actions need to be triggered based on actions taken in PeopleSoft?
Creating a Project Plan 21
What operations/events/actions are to be ignored?
How is the data to be transformed and mapped to Identity Manager?
Interviewing key people can lead to other areas of the organization that can provide a more clear
picture of the entire process.
After you have gathered all of this information, you can design a correct enterprise data model for
your environment. Proceed to Section 2.2.3, “Design an Enterprise Data Model,” on page 22 to start
the design.
2.2.3 Design an Enterprise Data Model
After your business processes have been defined, you can use Designer to begin to design a data
model that reflects your current business processes.
The model in Designer illustrates where data originates, where it moves to, and where it can’t move.
It can also account for how critical events affect the data flow. For example, Figure 2-2 shows that
the data flows from the PeopleSoft, but no data synchronizes back into PeopleSoft.
Figure 2-2 Data Flow through Designer
novdocx (en) 17 September 2009
You might also want to develop a diagram that illustrates the proposed business process and the
advantages of implementing automated provisioning in that process.
22 Identity Manager 3.6.1 Installation Guide
The development of this model begins by answering questions such as the following:
What types of objects (users, groups, etc.) are being moved?
Which events are of interest?
Which attributes need to be synchronized?
What data is stored throughout your business for the various types of objects being managed?
Is the synchronization one-way or two-way?
Which system is the authoritative source for which attributes?
It is also important to consider the interrelationships of different values between systems.
For example, an employee status field in PeopleSoft might have three set values: employee,
contractor, and intern. However, the Active Directory system might have only two values:
permanent and temporary. In this situation, the relationship between the “contractor” status in
PeopleSoft and the “permanent” and “temporary” values in Active Directory needs to be
determined.
The focus of this work should be to understand each directory system, how they relate to each other,
and what objects and attributes need to be synchronized across the systems. After the design is
complete, the next step is to create a proof of concept. Proceed to Section 2.3, “Proof of Concept,”
on page 23.
novdocx (en) 17 September 2009
2.3 Proof of Concept
The outcome of this activity is to have a sample implementation in a lab environment that reflects
your company’s business policy and data flow. It is based on the design of the data model developed
during the requirement analysis and design and is a final step before the production pilot.
NOTE: This step is often beneficial in gaining management support and funding for a final
implementation effort.
Chapter 3, “Technical Guidelines,” on page 27 contains information that can help you validate your
proof of concept. It contains technical guidelines to help make your Identity Manager deployment
successful.
As you create the proof of concept, you need to also create a plan to validate the data that you have
in your systems. This step helps you make sure that conflicts don’t occur between systems. Proceed
to Section 2.4, “Data Validation and Preparation,” on page 23 to make sure these conflicts do not
occur.
2.4 Data Validation and Preparation
The data in production systems can be of varying quality and consistency and therefore might
introduce inconsistencies when synchronizing systems. This phase presents an obvious point of
separation between the resources implementation team and the business units or groups who “own”
or manage the data in the systems to be integrated. At times, the associated risk and cost factors
might not belong in a provisioning project.
Creating a Project Plan 23
You need to have the data model that you completed in the analysis and design phases. You should
also have a proposed record matching and data format strategy defined in order to prepare the data
correctly. With the data model and format strategy defined, you can:
Create production data sets appropriate for loading into the Identity Vault (as identified in the
analysis and design activities). This includes the likely method of loading (either bulk load or
via connectors). The requirement for data that is validated or otherwise formatted is also
identified.
Identify performance factors and validate these factors against equipment being used and the
overall distributed architecture of the deployment of Identity Manager.
After the data is prepared, proceed to Section 2.5, “Production Pilot,” on page 24.
2.5 Production Pilot
The purpose of this activity is to begin the migration into a production environment. During this
phase, there might be additional customization that occurs. In this limited introduction, the desired
outcomes of the preceding activities can be confirmed and agreement obtained for the production
rollout. The pilot validates the plan that has been created to this point in the process.
novdocx (en) 17 September 2009
NOTE: This phase might provide the acceptance criteria for the solution and the necessary
milestone en route to full production.
The pilot solution provides live proof of concept and validation for the data model and desired
process outcomes. After the pilot is completed, proceed to Section 2.6, “Production Rollout
Planning,” on page 24.
2.6 Production Rollout Planning
This phase is where the production deployment is planned. The plan should:
Confirm server platforms, software revisions, and service packs
Confirm the general environment
Confirm the design of the Identity Vault in a mixed coexistence
Confirm that the business logic is correct
Confirm that the data synchronization is occurring as planned
Plan the legacy process cutover
Plan a rollback contingency strategy
The plan needs to contain implementation and completion dates for each step in the rollout. Each
stakeholder provides input for these dates and agrees that these dates work for them. This allows
each person involved in the rollout to know when the changes are coming and when they should be
completed.
With the production rollout plan completed, proceed to the Section 2.7, “Production Deployment,”
on page 25.
24 Identity Manager 3.6.1 Installation Guide
2.7 Production Deployment
The production deployment phase puts all of the plans into action and the Identity Manager solution
is created in the live environment. Use the production rollout plan to put the different pieces of the
Identity Manager solution into place. This might take one night or it might be spread across a longer
period of time. It depends upon what your plan contains.
novdocx (en) 17 September 2009
Creating a Project Plan 25
novdocx (en) 17 September 2009
26 Identity Manager 3.6.1 Installation Guide
3
Designer iManager
Metadirectory
Server with
eDirectory
iManager
Server
Administration
Workstation
User
Application
Server
Novell
Sentinel Server
Technical Guidelines
The information that you gather in Designer allows you to make the technical decisions such as
installation location and configuration options, about each component of Identity Manager. For an
introduction to each component, see the Identity Manager 3.6.1 Overview guide. Figure 3-1 is one
possible configuration of an Identity Manager solution.
Figure 3-1 Identity Manager Components
novdocx (en) 17 September 2009
3
Identity Manager is very customizable. The following sections contain technical best practices
guidelines to help set up and configure the Identity Manager solution that works best for your
environment. Variables that affect how these guidelines apply to your environment include the type
of hardware you have for your servers, how your WAN is configured, and how many objects are
being synchronized.
Section 3.1, “Management Tools Guidelines,” on page 28
Section 3.2, “Metadirectory Server Guidelines,” on page 29
Section 3.3, “eDirectory Guidelines,” on page 30
Section 3.4, “User Application,” on page 34
Section 3.5, “Auditing and Reporting Guidelines,” on page 35
Technical Guidelines
27
3.1 Management Tools Guidelines
Designer iManager
iManager
Server
Administration
Workstation
U
A
S
Novell
Sentinel Server
M
y
eDi
y
The two main management tools for the Identity Manager solution are Designer and iManager, as
illustrated in Figure 3-2. Designer is used during the planning and creation of the Identity Manager
solution, and iManager is used for daily management tasks of the Identity Manager solution.
Figure 3-2 Identity Manager Management Tools
ser
pplication
erver
etadirector
Server with
rector
novdocx (en) 17 September 2009
This document contains information only about Designer and iManager. The User Application uses
a Web-based administration page that is not discussed here. For more information about the User
Application, see “Administering the User Application” (http://www.novell.com/documentation/
idmrbpm361/agpro/data/agpropartadminapp.html) in the User Application Administration Guide.
Section 3.1.1, “Designer Guidelines,” on page 28
Section 3.1.2, “iManager Guidelines,” on page 29
3.1.1 Designer Guidelines
Designer is a thick client that is installed on a workstation. Designer is used to design, test,
document, and then deploy your Identity Manager solution. Using Designer throughout the planning
phase helps you capture information in one place. It also helps you see issues you might not be
aware of as you look at all of the components of the solution together.
There are no major considerations for using Designer, unless you have multiple people working on
the same project. Designer allows for version control of the project. For more information, see
“Version Control” in Designer 3.5 for Identity Manager 3.6 Administration Guide.
28 Identity Manager 3.6.1 Installation Guide
3.1.2 iManager Guidelines
Designer iManager
iManager
Server
Administration
Workstation
U
A
S
Novell
Sentinel Server
Metadirectory
Server with
eDirectory
novdocx (en) 17 September 2009
iManager is the administration tool for Identity Manager. When you install Identity Manager, the
TM
installation expects that you already have an iManager server installed in your eDirectory
tree.
If you have more than 10 administrators constantly working in iManager at one time, you should
have a server that hosts only iManager. Figure 3-2 represents this configuration of your Identity
Manager solution. If you have only one administrator, you can run iManager on your Metadirectory
server without complications.
3.2 Metadirectory Server Guidelines
You can have one or more Metadirectory servers in your Identity Manager solution, depending on
the server workload. The Metadirectory server requires that eDirectory be installed as shown in
Figure 3-3. You can add a Remote Loader server, not represented in the figure, to help with the
workload or configuration of your environment.
Drivers must run on the same server as the connected application. For example, to configure the
Active Directory driver, the server in Figure 3-3 must be a Member server or a Domain controller. If
you do not want to install eDirectory and Identity Manager on a Member server or Domain
controller, then you would install the Remote Loader on a Member Server or a Domain controller.
The Remote Loader sends all of the events from Active Directory to the Metadirectory server. The
Remote Loader receives any information from the Metadirectory server and passes that to the
connected application.
The Remote Loader provides added flexibility for your Identity Manager solution. For more
information, see the Identity Manager 3.6.1 Remote Loader Guide.
Figure 3-3 Metadirectory Sever
ser
pplication
erver
Technical Guidelines 29
There are many variables that affect the performance of the server. The standard recommendation is
that you have no more than ten drivers running on a Metadirectory server. However, if you are
synchronizing millions of objects with each driver, you might not be able to run ten drivers on a
server. On the other hand, if you are synchronizing 100 objects per driver, you can probably run
more than ten drivers on one server.
Setting up the Identity Manager solution in a lab environment gives you the opportunity to test how
the servers will perform. You can use the health monitoring tools in iManager to obtain a baseline
and then be able to make the best decisions for your environment. For more information about the
health monitoring tools, see “Monitoring Driver Health” in the Identity Manager 3.6.1 Common
Driver Administration Guide.
For considerations for each driver, see the Identity Manager Drivers documentation Web site (http://
www.novell.com/documentation/idm36drivers/index.html). Driver-specific information is provided
in each driver guide.
3.3 eDirectory Guidelines
eDirectory is the Identity Vault that stores the objects that are synchronized through the Identity
Manager solution. The follow sections contain guidelines that help you plan your deployment of
eDirectory.
novdocx (en) 17 September 2009
Section 3.3.1, “Identity Manager Objects in eDirectory,” on page 30
Section 3.3.2, “Replicating the Objects that Identity Manager Needs on the Server,” on page 31
Section 3.3.3, “Using Scope Filtering to Manage Users on Different Servers,” on page 32
3.3.1 Identity Manager Objects in eDirectory
The following list indicates the major Identity Manager objects that are stored in eDirectory and
how they relate to each other. No objects are created during the installation of Identity Manager. The
Identity Manager objects are created during the configuration of the Identity Manager solution.
Driver Set: A driver set is a container that holds Identity Manager drivers and library objects.
Only one driver set can be active on a server at a time. However, more than one server might be
associated to one driver set. Also, a driver can be associated with more than one server at a
time. However, the driver should only be running on one server at a time. The driver should be
in a disabled state on the other servers. Any server that is associated with a driver set must have
the Metadirectory engine installed on it.
Library: The Library object is a repository of commonly used policies that can be referenced
from multiple locations. The library is stored in the driver set. You can place a policy in the
library that every driver in the driver set can reference.
Driver: A driver provides the connection between an application and the Identity Vault. The
driver is the connector that enables data synchronization and sharing between systems. The
driver is stored in the driver set.
Job: The purpose of a job is to complete a task that occurs many times. For example, a job can
configure a system to disable an account on a specific day, or to initiate a workflow to request
an extension of a person’s access to a corporate resource. The job is stored in the driver set.
30 Identity Manager 3.6.1 Installation Guide
Loading...