1. ITIM 4.6 - Common Lifecycle Operation Modifications

2. 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.

3. Introductions
Fon Kwok US: ITIM L2 Support Engineer phone:

4. 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.

5. 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.

6. Overview of the Workflow Designer and components (cont.)
This is a generic workflow for an Active Directory Service.

7. 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.

8. Overview of the Workflow Designer and components (cont.)

9. 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.

10. 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.

11. ITIM Entities
Our labs will be centered around making modification to default ITIM entities.
Found under Configuration  Entitles
In these scenarios we will be using the BPPerson and ADAccount entities

12. 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.

13. Add BPPerson Workflow (before and after)
- Add a script node to allow lookup for the sponsor

14. Sponsor Lookup Script

15. 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

16. End Result for Scenario 1
Run the datafeed again with user Tom Jones
The script finds the corresponding sponsor value.

17. 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….

18. Existing AD Service Base Point
Notice that we can only specify one base point at a time.
This script will allow us to use multiple base points.

19. Add AD Account Workflow (before and after)

20. Set Basepoint Script

21. 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

22. 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

23. 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 address. The address is usually created when the Person’s account is provisioned (via ITIM).
This scenario will show how to update a Person object with a valid address, once the Person has been provisioned an account (ADAccount).
This can be used to update the Person object with virtually any Account data (example: erUid -> erAliases).

24. Add AD Account Workflow (before and after)

25. Update Person Email Script

26. 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

27. Add AD Account Workflow

28. Modify Person Operation

29. End Result for Scenario 3
A new AD account is created for a Person. This account contains a new address
The address is now populated in the Person object under the “Communications Information” tab

30. 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.

31. Setting up AD Account Change Pwd Workflow
Create new Relevant Data items to represent the Person and Service entities for the Modify operation performed later.

32. Adding Relevant Data objects
Add a Person relevant data object

33. Adding Relevant Data objects
Add a Service relevant data object
Add a String relevant data object to check if the requestor is the owner of the Account.

34. Change AD Account Password Workflow (before and after)

35. Check Requestor Script

36. 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.

37. Change AD Account Password Workflow

38. Workflow with all relevant data objects added

39. Change AD Account Password Workflow (before and after)
Set the transition in the workflow

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

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

42. 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.

43. 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.

44. Setting up AD Account Delete Workflow

45. Adding Relevant Data objects

46. Delete AD Account Workflow (before and after)

47. 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)

48. Delete AD Account Workflow

49. 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

50. 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”

51. 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);

52. 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=" "> :58: :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\

53. 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.

54. Thank you!