®

IBM Software Group

© IBM Corporation

ITIM 4.6 - Common Lifecycle Operation Modifications

IBM Software Group

Agenda

Introductions

Basic overview of Lifecycle Operations and Entitlement Workflows

Overview of the Workflow Designer and components

Scenarios

Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.

IBM Software Group

Introductions

Fon KwokUS: ITIM L2 Support Engineeremail: fkwok@us.ibm.comphone: 714-438-5112

IBM Software Group

Basic Overview of Lifecycle Operations and Entitlement Workflows

Similarities: Approvals, RFI’s, WorkOrders. These nodes are available in all operations.

Scripting (data manipulation, etc).

Modifying the behavior of ITIM (doesn’t require writing custom Java code).

Differences: Lifecycle Operations: any action on Accounts and Person objects

Entitlement Workflows: only for Add/Modify on Account objects.

Lifecycle Operations: effective after saved, and profile cache is refreshed.

Entitlement Workflows: only effective, after added to a Provisioning Policy, and only effects those Accounts that are associated with that Policy.

“Subprocess”, can only be called in an Entitlement Workflow.

Only Lifecycle Operations can be used with a Lifecycle Rule.

IBM Software Group

Overview of the Workflow Designer and components

Workflow Designer is a Java Applet that is used to configure the Lifecycle Operations and Entitlement Workflows.

Components: Nodes:

Approval: requires approval/rejection from participant RFI: requires information from participant Operation: calls an existing Operation (Person>Modify from Account>Add). Loop: loops until conditions are met Extension: performs a single action (modifyAccount, suspendPerson, etc). Script: JavaScript Work Order: sends notification to a participant, and can create a To-Do Item. Subprocess (only available in Entitlement Workflows): Calls an Entitlement

Workflow, from another Entitlement Workflow. Transitions:

The connectors between nodes. Are used to route the request through the Operation/Workflow. Can contain JavaScript.

IBM Software Group

Overview of the Workflow Designer and components (cont.)

IBM Software Group

Overview of the Workflow Designer and components (cont.)

Data

Input Parameters: data that enters into the workflow/operation, and is used to perform the function. (Static)

Output Parameters: Only supported in Entitlement Workflows. The resulting data of the workflow.

Relevant Data: global variable data within the Workflow/Operation. Can be used to pass data from one activity to the next. JavaScript can be used to retrieve/modify/set Relevant Data.

Accessed by clicking the “Properties” button in the Workflow Designer

The default Input/Output Params and Relevant Data, will differ between Entities, Operations, Workflows.

IBM Software Group

Overview of the Workflow Designer and components (cont.)

IBM Software Group

JavaScript methods

JavaScript methods used in the scenarios: x.get(); retrieves the object

x.getProperty(‘attributeName’); retrieves the attribute value

x.setProperty(‘attributeName’,value); sets an attribute value

x.set(y); pushes the object back into the workflow for later use

process.requestorType; returns the type of requestor (system, user)

process.getRootRequesterName(); name of the requestor for root request

PersonSearch().searchByFilter(profile,filter,scope); searches for (and returns) a person object.

IBM Software Group

Overview of the Scenarios:

Case 1: Sponsor lookup during BPPerson dataload.

Case 2: Dynamically change Service data, while processing requests.

Case 3: Update Person object with Account data.

Case 4: Dynamically change account data during requests.

Case 5: Prevent the ITIM System from deleting accounts.

IBM Software Group

ITIM Entities

IBM Software Group

Scenario 1: Sponsor lookup during BPPerson dataload.

The Sponsor (erSponsor) attribute on BPPerson objects, behaves similar to the Supervisor attribute on Person objects. This attribute contains a DN that points to another BPPerson object.

Previously a bug existed where ITIM does not handle the lookup of erSponsor’s value during datafeed, as it does erSupervisor’s. (NOTE: this has been fixed in ITIM 4.6 IF10 APAR IY80890)

Previously, in order to get the erSponsor value loaded successfully, you would have to pass a valid DN for this attribute in the feed. For Person objects, you can use a common name or an attribute/value pair.

In this scenario, we use a Script node to perform the same type of lookup for the erSponsor, as ITIM would normally do for the erSupervisor attribute.

This scenario will show how to modify the ITIM Operations to workaround bugs/limitations.

IBM Software Group

Add BPPerson Workflow (before and after)

IBM Software Group

Sponsor Lookup Script

IBM Software Group

Sponsor Lookup Script

In this script the following occurs:

Check for the requestor type (ie is this a system generated request or a manual user request?). Specifically not U (which means that a user is triggering an event. We want it to be looking for datafeed processes)

Get the Person entity

Get the Person’s Sponsor value (which is a filter such as “employeenumber=55555”)

Search for the Sponsor’s DN using that filter value.

Return the new Sponsor DN in the Sponsor attribute

IBM Software Group

End Result for Scenario 1

Run the datafeed again with user Tom Jones

The script finds the corresponding sponsor value.

IBM Software Group

Scenario 2: Dynamically change Service data, while processing requests.

Some Services contain parameters to help limit the management scope of that service on the remote platform. Normally, a separate service for each scope would have to be created, in ITIM.

This scenario will show how to dynamically modify Service parameters, at runtime, in order to limit/expand the management scope of the Service on the remote platform.

Most commonly used with AD and RACF Service types. AD: Base Point, Domain ID/PWD.

RACF: RACF ID….

IBM Software Group

Existing AD Service Base Point

IBM Software Group

Add AD Account Workflow (before and after)

IBM Software Group

Set Basepoint Script

IBM Software Group

Set Basepoint Script

The script will do the following:

Get the Account owner (Person)

Get the Service entity

Get the owner’s title

Check if the title is a Contractor, and if so, set a new basepoint

IBM Software Group

End Result for Scenario 2

Add a new AD account for a Person who’s title is Contractor

The new AD account will be created in the “Contractors” container

IBM Software Group

Scenario 3: Update Person object with Account data.

In most Customer environments, Person data needs to be updated with information that was not available during the DataFeed.

Example: Most Person data is loaded into ITIM without a valid email address. The email address is usually created when the Person’s email account is provisioned (via ITIM).

This scenario will show how to update a Person object with a valid email address, once the Person has been provisioned an email account (ADAccount).

This can be used to update the Person object with virtually any Account data (example: erUid -> erAliases).

IBM Software Group

Add AD Account Workflow (before and after)

IBM Software Group

Update Person Email Script

IBM Software Group

Update Person Email Script

This script does the following:

Get the Account entity

Get the Account owner (Person)

Get the Account’s mail property

Populate this into the owner’s mail property

IBM Software Group

Add AD Account Workflow

IBM Software Group

Modify Person Operation

IBM Software Group

End Result for Scenario 3

A new AD account is created for a Person. This account contains a new email address

The email address is now populated in the Person object under the “Communications Information” tab

IBM Software Group

Scenario 4: Dynamically change account data during requests.

This scenario will show how to dynamically modify account data, during a request, based on the request data.

Quite a few customers have requested that ITIM expire account passwords, whenever Help Desk/Admins/etc. reset passwords for a user. But if the owner of the account resets their account password, the password should not be expired.

Based on the requester of changePassword, the Operation will either cause the account’s password to be expired….or will leave the password active.

IBM Software Group

Setting up AD Account Change Pwd Workflow

IBM Software Group

Adding Relevant Data objects

IBM Software Group

Adding Relevant Data objects

IBM Software Group

Change AD Account Password Workflow (before and after)

IBM Software Group

Check Requestor Script

IBM Software Group

Check Requestor Script

The script does the following:

Get the Account entity

Gets the owner of the Account (Person entity)

Gets the Person’s cn

Sets the Person relevant data object

Gets the Account’s service name

Sets the Account relevant data object

Gets the process’s requestor name

Compare it to the Person’s cn, and set the isOwner flag accordingly.

IBM Software Group

Change AD Account Password Workflow

IBM Software Group

Workflow with all relevant data objects added

IBM Software Group

Change AD Account Password Workflow (before and after)

IBM Software Group

Transition Node

If the person requesting the AD password change is the owner, then go to the “End” of workflow.

IBM Software Group

Transition Node

If the person requesting the AD password change is not the owner, then go to the change password node.

IBM Software Group

End Result for Scenario 4

Logged in as “ITIM Manager”, we change the AD password for Chuck Wilson

Check the Chuck Wilson account in Active Directory, and you will see that the “User must change password at next logon” is enabled.

IBM Software Group

Scenario 5: Prevent the ITIM System from deleting accounts.

In order to keep accounts compliant with the ITIM Policies, the Policy Enforcement Action must be set to “Correct”.

The risk of this configuration, is that ITIM will deprovision accounts that are found to be “not allowed”.

Many customers do NOT want ITIM to deprovision accounts, unless specifically requests by a user/admin (non-system).

Customers could replace the ‘deleteAccount’ extension (in the ‘delete’ Operation), with a ‘suspendAccount’ extension….but this would prevent even manual delete requests from deprovisioning accounts.

This scenario shows how to configure the ‘delete’ Operation to allow manual delete requests, but prevent the ITIM System from automatically deleting accounts.

IBM Software Group

Setting up AD Account Delete Workflow

IBM Software Group

Adding Relevant Data objects

IBM Software Group

Delete AD Account Workflow (before and after)

IBM Software Group

Check Requestor ID script

This script checks the requestor type. If it is System (S), then set the String relevant data object accordingly (this will be processed by the Transition node)

IBM Software Group

Delete AD Account Workflow

IBM Software Group

Transition Node If the requestor is the System, then go to the “End” of workflow.

If the requestor is an ITIM user, then go to the Delete account node

IBM Software Group

End Result for Scenario 5

The Person object “Chuck Wilson” belongs to the “AD Users” organization role. This allows him to have an AD account.

We remove Chuck from this organization role.

ITIM normally deletes the account (based on Correct Noncompliance). However, the workflow will find that the requestor was System, and will leave the account under Chuck Wilson as “Not Allowed”

IBM Software Group

Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.

In order to help determine the cause of problems in Workflows/Operations, Scripting can be added that make use of the new JavaScript method added in ITIM 4.6, called Enrole.log().

In previous versions of ITIM, ‘return’ statements would have to be used, or custom fesiextensions would have to be written, in order to return debug data at different points in the Workflow.

Usage: Enrole.log(“Component”,”Message/Data”);

Example: To retrieve and print the title attribute value to the msg.log:

var person = person.get();var title = person.getProperty(‘title’)[0];Enrole.log(“TEST”,”TITLE: “ + title);

IBM Software Group

Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.(cont.)

The msg.log would show something like the following:

<Message Id="CTGIMO023E" Severity="ERROR"><Time Millis="1130457513906"> 2005.10.27 16:58:33.906-07:00</Time> <Server Format="IP">gumfudgin.ITIMlab.local</Server> <ProductId>CTGIM</ProductId><Component>TEST</Component><ProductInstance>server1</ProductInstance><LogText><![CDATA[CTGIMO023E The following definition error occurred. Error: TITLE: Contractor ]]></LogText><Source FileName="com.ibm.itim.fesiextensions.Enrole" Method="Enrole.log"/><TranslationInfo Type="JAVA" Catalog="tmsMessages" MsgKey="standardException.userDefinedError"><Param><![CDATA[TITLE: Contractor]]></Param></TranslationInfo></Message>

The Component value, that was entered in the Enrole.log() statement, can be used to locate the debug output from the scripts.

The msg.log (and trace.log) is located in c:\Program Files\ibm\tivoli\common\CTGIM\logs\

IBM Software Group

Conclusion

In many customer environments, there are business requirements that ITIM cannot perform in a default installation.

We can modify the default ITIM Lifecycle Operations to fulfill these requirements.

Custom external coding is not always necessary.

IBM Software Group

Thank you!