1. ® IBM Software Group © IBM Corporation ITIM 4.6 - Common Lifecycle Operation Modifications

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

3. IBM Software Group Introductions  Fon Kwok US: ITIM L2 Support Engineer email: fkwok@us.ibm.com phone: 714-438-5112fkwok@us.ibm.com

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

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

6. IBM Software Group Overview of the Workflow Designer and components (cont.)

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

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

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

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

11. IBM Software Group ITIM Entities

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

13. IBM Software Group Add BPPerson Workflow (before and after)

14. IBM Software Group Sponsor Lookup Script

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

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

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

18. IBM Software Group Existing AD Service Base Point

19. IBM Software Group Add AD Account Workflow (before and after)

20. IBM Software Group Set Basepoint Script

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

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

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

24. IBM Software Group Add AD Account Workflow (before and after)

25. IBM Software Group Update Person Email Script

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

27. IBM Software Group Add AD Account Workflow

28. IBM Software Group Modify Person Operation

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

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

31. IBM Software Group Setting up AD Account Change Pwd Workflow

32. IBM Software Group Adding Relevant Data objects

33. IBM Software Group Adding Relevant Data objects

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

35. IBM Software Group Check Requestor Script

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

37. IBM Software Group Change AD Account Password Workflow

38. IBM Software Group Workflow with all relevant data objects added

39. IBM Software Group Change AD Account Password Workflow (before and after)

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

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

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

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

44. IBM Software Group Setting up AD Account Delete Workflow

45. IBM Software Group Adding Relevant Data objects

46. IBM Software Group Delete AD Account Workflow (before and after)

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

48. IBM Software Group Delete AD Account Workflow

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

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

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

52. IBM Software Group Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows. (cont.)  The msg.log would show something like the following: 2005.10.27 16:58:33.906-07:00 gumfudgin.ITIMlab.local CTGIM TEST server1  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. 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.

54. IBM Software Group Thank you!