IBM Tivoli Identity Manager 5.0 How To

How to generate ITIM compatible password

Here is the link containing information on how to setup calling a password change operation from a lifecycle rule. 1

In the description the writer simply states something like 'insert a script in which you provide whatever password you want'.

If you wanted to do what ITIM does when you check the 'create password' checkbox in the ui, according to L3, you'd basically call something along the lines of:

PasswordManager.generatePassword(java.util.Collection accounts)         

in a custom workflow extension to obtain a suitable generated password.

Information about developing workflow extensions can be found in:

<itim_home>/extensions/doc/workflow/workflow.html                       

Information about the PasswordManager class can be found in:

<itim_home>/extensions/api/index.html                                   

Erpassword is only used for TIM accounts, in some cases erpassword was populated for other accounts, but this done was in error, and fixed in some iterim fix before if0034. If you can generate a password you can set it in workflow with setAndEncryptPassword() acct.setProperty("postexec", PostExec); acct.setAndEncryptPassword(psw); account.set(acct);

You want to make this the result of your operation. So while still in the property window of the operation node, click over to the postscript tab. In the text box there enter:

process.setResult(activity.resultSummary, activity.resultDetail); 

Click OK to close the operation node's properties window. Now drag a script node from the pallet into the design area. Double click it to open its properties window. Enter whatever code you need to calculate what the account's new password should be. Let's say you have stored that in the script variable named "password". You now need to set that on the account object passed into your workflow as its Entity relevant data item. So enter:

var account = Entity.get();
account.setAndEncryptPassword(password);
Entity.set(account); 

The setAndEncryptPassword method will be available only if you have added the line "javascript.password.access.enabled=true" to data/fesiextensions.properties(ITIM 4.x) OR data/scriptframework.properties(ITIM 5.x) file.

How to expire a TAM password in TIM during password change

(the following text is a copy from another source) Abstract In the situation where TIM is setting TAM passwords, customers have asked for a way to expire the newly set password in TAM. This can be accomplished by modifying the operational workflow that defines the change password event. It is important to note that this method can be used for any target platform.

Step 1 - Edit the fesiextensions.properties file This is the most annoying step, so let's get it out of the way first. Edit the fesiextensions.properties file, which lives in the data directory in the ITIM home directory. Before the last line of all # signs, add the following line: fesi.extension.Workflow.Model=com.ibm.itim.fesiextensions.ModelExtension This allows the Workflow engine to use some other FESI extensions needed to accomplish this task. You will need to restart the TIM server.

Step 2 - Getting to the workflow Once the TIM server is back up, log in as itim manager or an equivalent. Go to the Configuration tab. Go to the Entities tab. Click on TAM4Account. Click on the Define Operations button. You will now see the list of available operations. Click on changePassword and you will enter the Workflow Editor. As you can see there isn't much to this workflow. It simply uses an extensions node to call the changePassword function.

Step 3 - Adding Relevant Data To make this process work, you must first declare some new relevant data items. Click on the Properties button; it's the one next to Save, Update, and Exit. This will bring up the Properties window. Click the Add button. This will bring up the Relevant Data Detail: Add window. Set the following values:

1)      ID = owner
2)      Type = Person

Click Ok. Repeat this process with the following data.

1)      ID = service
2)      Type = Service

Repeat this process with the following data.

1)      ID = changedAccount
2)      Type = Account

It is important that you only set the data elements specified for each relevant data item. If you set attributes like Entity or Context, this process will not work. Click Ok to accept the new Relevant Data changes. It is important that you get this all in one shot. Returning to this window and changing Relevant Data items can have unexpected repercussions.

Step 4 - Adding New Nodes
Back in the main workflow editor screen, you'll need to add two new nodes: a Script node and an Extension node. Connect the CHANGEPASSWORD node to the Script node. Connect the Script node to the new Extension node. Connect the new Extension node to the End node.

Step 5 - Configuring the Script Node Open the Script node by double clicking on it. Set the Activity ID to setupData. Enter the following piece of JavaScript into the JavaScript field.

{
var account=Entity.get();

var serviceDN = account.getProperty("erservice")[0];
var localService = new Service(serviceDN);
service.set(localService);

var ownerDN = account.getProperty("owner")[0];
var localOwner = new Person(ownerDN);
owner.set(localOwner);

account.setProperty("ertam4expirepass","TRUE");
changedAccount.set(account);
}

First this code grabs the only piece of data that is available to it, the Entity, which is, in this case, a TAM account. The second paragraph determines the service the account is from and sets the Relevant Data item service accordingly. The third paragraph determines the owner of the account and sets the Relevant Data item owner accordingly. Finally, the last paragraph sets the Expire Password flag in the TAM account and sets the Relevant Data item changedAccount accordingly. You need to set all of these pieces of data so that the new Extension node can operate properly.

Step 6 - Configuring the New Extension Node This node will actually go and modify the TAM account, setting the Expire Password flag. (You could use an Operation Node here just as easily.) Open the new Extension node. Set the Activity ID to modifyAccount. Select the modifyAccount Extension Name. Now you must assign the appropriate Relevant Data items. Click on the first line of Input Parameters, thus selecting owner / Person. Click the Search Relevant Data button. In the Relevant Data Search window, select the owner / Person line and click Ok. Repeat this process for the service / Service entry. Select service / Service in the Relevant Data Search window. Repeat this process for the account /Account entry. Select changedAccount / Account in the Relevant Data Search window.

Step 7 - Finishing Up Click Exit and click Save to save the changes you have just made. You might receive a warning about this workflow. This is merely a warning to tell you that now that you have overridden an out-of-the-box workflow with a custom one, TIM needs to circulate this change and it can take up to 10 minutes. (My experience has shown that this happens much faster than 10 minutes, but it's time for a coffee break at this point any way.)

Notice that the Type for changePassword is now user-defined.

Step 8 - Use in good health You can now use your newly modified password change system. When an TAM account's password is now changed you will see the following in the Audit Log. Notice that the modifyAccount step appears.

Troubleshooting:

  • If your password changes are failing, open up the View Completed Requests and look at the request.
  • If there is an ECMA Script Interpreter error like the following, you did not edit the fesiextensions.properties
  • file properly or you forgot to cycle the TIM server afterwards.
  • If your password changes are failing and you are seeing null pointer exceptions like the following,
  • then you have, most likely, gone back into the workflow properties and changed the Relevant Data items.

The best thing to do at this point is go back to the list of workflows for the TAM4Account Entity. Select changePassword and delete it. This resets the workflow back to the default settings, and you can try again.

How to generatine a conforming password and set it in a workflow

copy fesiextensions.properties "f:\Program Files\ibm\itim\data"

copy fesiconveniences.jar "f:\Program Files\WebSphere\AppServer\installedApps\ADVTIM\enRole.ear\"

enrole will be restarted automatically

To generate the password this you would go to Entity Type > Accounts > Define Operations. Enter a name in the "New Operation" field (let's call it "PasswordChangeFromRule"), and click the Add button. This will open the workflow designer with a new empty workflow. In the workflow designer, click the Properties button. In the properties window, click the "non-static" radio button. This should add a new relevant data item named "Entity" with a type of "Account" to the list at the bottom of the window. Having this and no other input parameters makes this a legal workflow for an account lifecycle rule to call. Now add a string relevant data item to be passed as the notifyFlag input parameter when you call the password change workflow. Click the Add button for the relevant data item list. Give the item a name such as "notify". Select "String" as its type. Set its default value to either "true" or "false". Click OK to close the add window, and again to close the properties window.

In the workflow designer window, drag an operation node from the pallet into the design area. Double click the operation node to open its properties window. Give it an ID such as "PasswordChangeFromRule".

In the "operation activity type" list select "data reference". This means that you will be passing one of your workflow's relevant data items to be used as the "Entity" data item in the change password workflow. The relevant data item in your workflow that you want to pass is your own workflow's Entity item. Click the "..." button next to the "Relevant data" field. Select the Entity item and click OK to close the selection window.

The "operation" list in the operation node's properties window should now contain a list of the non-static account operations. One of these should be the change password operation. Select it.

Selecting the operation will populate the "Input Parameters" list at the bottom of the window with any additional input parameters that are required by the operation you are calling. You should see the notifyFlag input parameter that is defined by the change password operation. Select it, and click the "Search Relevant Data" button. Select the "notify" relevant data item that you added to your workflow, and click OK. That should be everything you need to have your workflow call the password change workflow.

Finally, you want the return value of the password change workflow to be the return value of your workflow. The operation node returns the result of the called operation as its activity result. You want to make this the result of your operation. So while still in the property window of the operation node, click over to the postscript tab. In the text box there enter: process.setResult(activity.resultSummary, activity.resultDetail);

Click OK to close the operation node's properties window.

Now drag a script node from the pallet into the design area. Double click it to open its properties window. Enter the following code:

var acct=Entity.get();
var acctOwnerDN=acct.getProperty("owner")[0];
Enrole.log("script", "###Account:restore:generatePassword - generating for "+acctOwnerDN);
var pwd=generatePassword("eruid=ITIM Manager,ou=systemUser,ou=itim,DC=DEV,DC=DOM",acctOwnerDN);
Enrole.log("script", "###Account:restore:generatePassword - generated "+pwd);
account.setAndEncryptPassword(pwd);
Entity.set(account);

The setAndEncryptPassword method will be available only if you have added the line "javascript.password.access.enabled=true" to data/fesiextensions.properties(ITIM 4.x) OR data/scriptframework.properties(ITIM5.x) file.

Click OK to close the script's propteries window. Add transitions between the start and script nodes, script and operation nodes, and operation and end nodes.

Click save to save your new workflow definition. You should now be able to call this workflow from a lifecycle rule.

How to make sure pending requests are processed when service configuration is changed

Should work by itself with a small delay. Here is an explanation:

I have been running through more tests on my server setup and I am seeing the situation is actually handled by the server, though with some delay. The following is what I was doing to test the type of setup.

  1. I have a rfi in my account Add workflow for my Posix Linux account type.
  2. I have my service setup pointing at a TDI server on xxx.xxx.121.131 machine in the TDI location field on the service form.
  3. I submit a request to add a posix linux account to one of my users, this get submitted and stays in pending state waiting for another user to respond to the RFI.
  4. If I look at the small_value data column in the processlog table, I can see the service information that contains the xxx.xxx.121.131 value in the TDI location. Note the small_value column in the table is base64 encoded xml data.
  5. I now update my posix linux service form to point to a different TDI/RMI server on another machine, in my case on machine xxx.xxx.121.136. The only change I make to the service for is the TDI location URL to the new IP.
  6. I then log into TIM as the account for which the rfi is pending and respond to the rfi.
  7. I now see the request still pending and when I drill down, I see the create account has the "resource failed" result detail

Now is where there server actually handles this situation. Once the first attempt to submit the add request fails with the "resource failed" message, then the service is marked down in TIM. Then the TIM server will keep rechecking the service every 10 minutes to check if the service is still down or not? When the first attempt to submit the request failed, the request information was placed in the remote_services_requests table, but the information just is the account attribute values and the service for which the request is pending. The data does not contain the actual service form information. So when the service is next checked by the TIM server within the 10 minute interval and it is found to be okay, the request that was pending in the remote_services_requests table it then submitted to the service and succeeds.

So I don't see that there should be any need to resubmit manually the requests, they should still get processed, though just with the slight delay of failing first, then will get resubmitted by the TIM server within the 10 minute interval that the downed services are checked. This assumes the current information on the service form is all correct and the TDI/RMI is actually up and running.