Upgrading to Identity Manager 2 (IdM formerly DirXML) David Lee SME, Senior Business Manager Novell, Inc. Stuart Proffitt Senior Architect Novell, Inc

Upgrading to Identity Manager 2 (IdM formerly DirXML)

David LeeSME, Senior Business ManagerNovell, Inc.

Stuart ProffittSenior ArchitectNovell, Inc.

© March 21, 2004 Novell Inc.2

one Net: Information without boundaries…where the right people are connected with the right information at the right time to make the right decisions.

The one Net vision

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


The one Net vision

Novell Nsure solutions take identity management to a whole new level. Novell Nsure gives you the power to control access so you can confidently deliver the right resources to the right people — securely, efficiently, and best of all, affordably.

Novell Nsure™

Novell exteNd™

Novell Nsure™

Novell Nterprise™

Novell NgageSM

:

:

:

:


Leveraging Identity –Services Oriented Architecture

Basis for a Global Identity Management solution to deliver shared business services between areas of the organization and provide a foundation for rolling out value creating web services and automated business processes between networked clients.


Why Service Based Solutions?

Service based computing provides greater flexibility and lower cost in the construction and integration of application functionality

Service orientation supports Utility or on-demand computing and more efficient use of IT resources

Services can be sourced both internally and externally depending upon specific business needs

Services can be closely associated with business processes and assist in determining their relative value and contribution to the business


Service Oriented Architecture

Loosely Coupled• Dynamically configurable components

Standards Based• J2EE, Web Services, XML

Process Driven• Discretely invocable business processes

Identity Centric and Directory Enabled• Management, Security and provisioning

Network Aware• Execution and orchestration

7

Authoritative Sources

HR

ERP

CONTRACTOR/VENDOR

PBX

Auth Sources

8

Services and Consumers

AuthenticationLDAP/RADIUS

Service Directorie

s

Consumers

Platforms

W2K

xNIX

NW

WhitePagesFile & Print

Domain

JDBC

PA

M w

/ LD

AP

Radius

SQL-BasedPrograms

Messaging Server

iFolder/iPrint

WebServer

Dial-up/VPN

AD-Based Programs

9

Identity Vault ties it all together

AuthenticationLDAP/RADIUS

HR

ERP

CONTRACTOR/VENDOR

PBX

Auth Sources

Identity Vault

Service Directorie

s

Consumers

Platforms

W2K

xNIX

NW

Identity Vault

WhitePagesFile & Print

Domain

JDBC

PA

M w

/ LD

AP

Radius

SQL-BasedPrograms

Messaging Server

iFolder/iPrint

WebServer

Dial-up/VPN

AD-Based Programs


New Features in IdM 2

Many new features that simplify implementation and maintenance

For a detailed discussion of IdM 2 features and functionality attend - TUT384 Understanding the Architecture of Identity Manager 2


New JVM

The way the JVM is used for IdM drivers • JVM is 1.4.2• Each driver running on a DirXML® 1.x NetWare

server runs in its own JVM. This also means that the DirXML Engine code is duplicated for each driver

• In IdM 2 all drivers on a NetWare server run in the same JVM

• All Engine platforms now behave the same as far as the JVM is concerned

• Verify custom extensions are 1.4 compliant


New Cache Functionality

IdM 2 introduces some driver cache advancements• New cache file format that is much more space

efficient• Synthetic transaction boundaries• Cache content inspection• Removal of transactions from cache now possible

(dxcmd)


1 Suppression of automatic resync when re-enabling a disabled driver

2 Specification of a starting time for the search window for a manual resync

New ReSync Options

IdM 2 introduces two new driver resynchronization functions


Move Operation Enhancements

Significant changes to the way IdM performs object moves in eDirectory

• Eliminate the need for MoveProxy driver• Will eliminate almost all instances of local changes

being overwritten when a IdM-initiated move replicates to the local non-master replica

• Move operations and their associated events are deciphered and reported better

• Recommendation remains to run IdM on a master replica when possible


Engine controls

Engine controls provide a way of customizing some aspects of DirXML Engine behavior. There are currently three controls implemented

Subscriber-channel retry interval only matters if shim Subscriber returns status="retry" for a command

● Specifies the time to wait before resubmitting the transaction on the Subscriber channel

● Value is in seconds● Default is 30 seconds● Minimum 1 second, maximum 231 seconds (68 years)

DN format for referential attribute values ● Referential attributes such as manager, Members● Default is unqualified slash format (e.g., \IDM2TREE\novell\bjones)

Qualified slash form (e.g., O=novell\CN=bjones) may be specified

Maximum replication wait time● DirXML 2 Engine waits for replication to and from a master replica to occur in certain

circumstances related to eDirectory object moves● This control specifies the wait timeout value in seconds

Default is 180 secondsMinimum is 1 second, maximum is 231 seconds


Command line interface to certain DirXML functions

dxcmd• Java, requires JClient• Runs on Win32, NetWare, Solaris, Linux• Command-line mode• Interactive mode• Designed primarily to test DirXML verbs• Useful for customer applications where scripting is

required• Also works with DirXML 1.x• Also used to set Named Passwords


Persistent Event Identification

No more event-id hackCommand payload element

• In DirXML 1.x concatenating information to the event-id string is the easiest way to preserve information between a command and its status.

• In IdM 2 an <operation-data> element is available to avoid the concatenation hack

• The <operation-data> element may be placed as content in any event or command element

• The <operation-data> element from a command is placed under the <status> element that is the result of the command


Enhanced Trace Functionality

Cache subsystem tracing (dxevent) controlled by trace level

Thread identification in trace

Driver trace "nickname"

Per-driver trace file

Per-driver trace level


Trace File Management

Limit on amount of trace file data written to disk

Engine trace files

Remote Loader trace files

Uses a 10-file roll-over method

Default is unlimited size


Error and Warning codes

Each error and warning reported by the DirXML engine, including the cache system has a code

Primarily useful for logging with NSure Audit

Each error and warning has message detailing what has happened


Nsure Audit Integration

NSure Audit is Novell's standard for event notification and reporting

Events to be reported from IdM can be specified

User-defined events may be reported from Policies

Events include• Status (error, warning, success)• Operations (add, modify, delete, etc.)• Certain driver events such as driver start, driver

stop


Universal Password Support

Support for Universal Password and Distribution PasswordnspmDistributionPassword may be reported on Subscriber channel

Default password sync configurations change the add-attr and modify-attr events for the distribution password into password and modify-password commands

Default password sync configurations change Publisher-channel password and modify-password events into add-attr and modify-attr commands for the nspmDistributionPassword element


What's in a Name?

1.x Terminology was confusing – • A Rule could mean 3 different things• 1.x Rules and Style Sheets are now Policy Sets• Policies Sets can group mulitple Policies or XSLT

Stylesheets• Each Policy can have multiple rules.• Rules are made of DirXML Script built by Policy Builder


Policy Builder

Make complex policies simple to express• Make policy creation a "point and click" experience

Consistency1.x Terminology was confusing

• Rule meant 3 different things• Policy Set – A collection of 0 or more policies at a particular control

point• eg. Placement Rule --> Placement Policies• Policy – An individual instance of a Mapping Table, DirXML Script, or

XSLT• Rule – A set of conditions and associated actions within a DirXML

ScriptDirXML Script is the primary method of implementing policies in IDM 2

• Replaces replaces the simplified forms of the Matching, Create, and Placement Rules in DirXML 1.x

• Can be used in place of Schema Mapping Table• Can be used anywhere and XSLT transformation can be performed• Consists of an ordered set of rules• A rule is a set of actions and a set of conditions under which those

actions are performedRobust lexicon available

• Can almost do any function in DIRXML Script that you can do in XSLTTo apply complex business functions you can mix Polices and XSLT in a Policy Set


Policies

Filter

Input/Output

Transformation

Schema Mapping

Event Transformation

Match, Create, Placement

Command Tranformation


What does a Filter do?

A Filter specifies the classes of objects and the attributes of those objects for which DirXML will process events.

A single Filter is specified for both channels.

Filters only pass events on objects whose effective class matches one of those classes specified by the filter.

Filters do not pass events on objects that are a subclass of a class specified in the filter unless the subclass is also specified.

Filters can now control Merge Authority

Filters can setup Notification of changes to non-synching attributes


What does the InputTransformation Policy do?

The Input Transformation Rule is referenced by the driver object and applies to both the Subscriber channel and to the Publisher channel.

A common application is performing data format mapping.

Schema names will always be in the application namespace

The purpose of the Input Transformation Rule is to perform any preliminary transformation on all XML documents sent to IdM2 by the driver and returned to DirXML from the driver.

The Input Transformation Rule is applied to the XML document sent to xmlCommandProcessor.execute() and xmlQueryProcessor.query() (when called by the driver) and to the XML document returned from SubscriptionShim.execute(), and xmlQueryProcessor.query() (when called by DirXML).

It is possible to use the Input Transformation Rule to transform an arbitrary XML format native to the target application to the format expected by DirXML, but this is discouraged because it makes it harder for administrators to customize the rule for site-specific needs. It is usually wiser if the driver performs this transformation itself, possibly by calling the Novell XSLT processor directly.


What does the OutputTransformation Policy do?

The Output Transformation Rule is referenced by the driver object and applies to both the Subscriber channel and to the Publisher channel.

A common application is performing data format mapping.

Note that schema names will always be in the application namespace.

The purpose of the Output Transformation Rule is to perform any final transformation necessary on the XML documents sent to the driver by DirXML and returned to the driver by DirXML.

The Output Transformation Rule is applied to the XML document sent to SubscriptionShim.execute() and xmlQueryProcessor.query() (when called by DirXML) and to XML returned from xmlCommandProcessor.execute() and xmlQueryProcessor.query() (when called by the driver).

It is possible to use the Output Transformation Rule to transform between DirXML format and an arbitrary XML format native to the target application, but this is discouraged because it makes it harder for administrators to customize the rule for site-specific needs. It is usually wiser if driver performs this transformation itself, possibly by calling the Novell XSLT processor directly.


What does the Schema Mapping Policy do?

The Schema Mapping Rule is referenced by the driver object and applies to both the Subscriber channel and to the Publisher channel.

The purpose of the Schema Mapping Rule is to map schema names (particularly attribute names and class names) between the NDS namespace and the application namespace.

The Schema Mapping Rule is applied to the XML documents sent to and returned from SubscriptionShim.execute(), xmlQueryProcessor.query(), and xmlCommandProcessor().execute().

The Schema Mapping Rule is also applied to XML sent to (but not to XML returned from) SubscriptionShim.init() and PublicationShim().init().


What does the Event Transformation Policy do?

The purpose of an Event Transformation Rule is to perform preliminary transformations on events.

• due to add-->modify do not act upon add events• due to modify-->add do not act upon modify

events• generating additional events (disable on delete,

etc)• transforming the event directly into a custom

command to be passed to the application• custom event filtering (scope events)• get rid of “pending” state on Subscriber channel


What does the Matching Policy do?

The Matching Policy is only applied to <add> events.

The purpose of the Matching Policy is to

automatically associate objects in eDir with objects

in the application.

Typically only used: • during initial load where object exist in both systems • environments where eDir and the application can

have new objects created in both systems and one system does not automatically create in the other.


What does the Create Policy do?

The Create Rule is only applied to <add> events for which no matches for the corresponding object were found by the Matching Rule.

The purpose of the Create Rule is to decide whether or not to create a new object (required attributes/scoping) if a suitable association could not be automatically generated by the Matching Rule.

A Create Rule also can perform other modifications to the <add> event such as providing default values for attributes (including passwords) and/or specifying an object to use as a template for creating the new object.


What does the Placement Policy do?

The Placement Rule is only applied to <add> events which were not vetoed by the Create Rule.

The purpose of the Placement Rule is to determine where in the storage hierarchy to place an object that is to be created and to determine the name for the new object.

For eDir and other directory applications this means generating a distinguished name for the new object.


What does the CommandTransformation Policy do?

The purpose of the Command Transformation Policy is to provide final processing on commands before the commands are sent to eDirectory or the application.

Note that the Command Transformation Rule did not exist in DirXML 1.0; the Command Transformation Rule was added in DirXML 1.1.

The Command Transformation Rule on the Publisher channel is executed after all other rules and is executed directly before the IdM 2 engine applies the commands in the command document to eDirectory. It is the "last chance" to modify a command before the command is applied to eDirectory.Many applications that had to be performed in the Event Transformation Rule in DirXML 1.0 can be more easily performed in the Command Transformation Rule in DirXML 1.1. This is because all event to command processing (Add-->Modify, Modify-->Add) performed by the IdM 2 Engine has already been performed.

Some other possible applications for the Command Transformation Rule include:• changing the command type (for example, an object delete command might be

transformed into a modification that will cause the object to be archived)• blocking commands• generating additional events• adding additional commands• controlling the output of the DirXML Engine's "merge" process


When to Use XSLT

Legacy Rule support (existing code)

Complex Logic that involves multiple queries

Searches for multiple attribute values


Upgrade to IdM 2

Review the changes and what they mean to your implementation

Meet the pre-requisites

Follow the proper upgrade procedures

Test, Test, Test… did we mention Test..


Differences

Engine

Drivers

Remote Loader


Engine

Policy Sets instead of Rules

TAO File

1.0 to 1.1a or 2.0 • More strict for code variable re-use• Put into stylesheet and verify engine will accept

Filters• Auth Source• Notify• Optimize Notify

Event-ID

NSure Audit hooks


Drivers

Import Differences• xlf for localization needed on iManager server for

import


Remote Loader

New Certification Process Availble• Open SSL

Backwards compatible but not supported

Improved interface • Configuration• Monitoring


Proper Upgrade procedures

Upgrades Process• Stop all Drivers• Install IdM• Select Drivers• Restart to use new drivers (.jar and .dll changes)

Post Upgrade• Using iManager, Click on Driver to

– Convert Simple Rules to Policies– StyleSheets remain Stylesheets– Re-activate DriverTake advantage of new

features however...Test...Test...Test...More testing..


PreReqs

eDir• 8.6.2sp5

JVM• 1.4.x

Supported Platforms• NW 6+ (patch NW6.0 to JVM 1.4.x first)• Solaris 8, 9• Linux (SUSE and RedHat)• Windows NT,2000 (2003 soon)• AIX


Pre-Requisites for Universal Password

• eDir– 8.7.1.1 and higher recommend 8.7.3.1

• Client– NetWare Client 4.9sp1a– Or No client


Test

Lab• Unit• Integration• User acceptance


Test

Business procedures and policies

Conservative• Don't Roll in new changes

Living on the edge• Roll out new features at the same time


Additional Driver Upgrade Steps

AD/NT • Read upgrading from Password Synchronization 1.0

to 2.0 before procedding– password sync policy to maintain existing or – Upgrade agents/filters

• If using matching rule. Edit the XML and find all instances of the string "um-src-dn-extra" and replace with "um-src-dn"


Additional Driver Upgrade Steps

Notes • Manual copy of dsrepcfg.ntf • movecfg.exe createsdsrepcfg.nsf from filter.xml• Update notes.ini for new load of ndsrep -

instancename• Upgrade for named passwords


Additional Driver Upgrade Steps...

JDBC – 1.6 association utility

Exchange 5.5 – normalize associations

eDir to eDir – watch expired certs(SSL issues)

NIS – add nspmDistributionPassword to notify filter on Sub


We have TIDS...

Latest Driver & Engine builds Identity Manager 2.0:

SAP HR Driver: TID#2968265 *****NEW*****

IDM 2.0 Interim Release 1 TID#2968391 *****NEW*****

Exchange 5.5 Driver: TID#2968400 *****NEW*****

AD Driver: TID#2968367 *****NEW*****

Notable Identity Manager 2.0TID10090919: Passwords not being published to eDirectory from Active Directory.

TID10091354: Installing the new NMAS 2.3 Universal Password Password Policies and Self.

General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Novell, Inc., makes no representations or warranties with respect to the contents of this document, 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 document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

Documents

Upgrading to Identity Manager 2 (IdM formerly DirXML) David Lee SME, Senior Business Manager Novell, Inc. Stuart Proffitt Senior Architect Novell, Inc