IBM Tivoli Identity Manager How To

From KnowWiki
Revision as of 14:30, 1 October 2011 by Alex (Talk | contribs)

Jump to: navigation, search

This page is listing various generic know-how for IBM's Tivoli Identity Manager

Contents

How to configure Eclipse to compile ITIM Java Extensions (IBMJS)

  • First, get and install IBM Java 1.6
    • You could also just copy the JDK contents if you do not want to install it and potentially mess up your Java browser plugins:
xcopy /E /Y /I x:\folder\Tools\Java\ibm_sdk60 C:\Program Files\ibm_sdk60 
  • Configure the new JDK as an alternative Java build path:
    • Go into the properties of your project -> Java Build Path -> Libraries -> Add Library
    • Pick Alternative JRE, click Installed JREs, on the new window click Add and define the new JRE by pointing to the directory where IBM Java 1.6 is installed.
  • Add the ITIM API libraries and the WAS libraries to your build path by copying them from the working ITIM system
    • The easies way to pull them off is to use the ITIM Remote API scripts.
    • Then add user libraries of F:\Program Files\IBM\itim\lib and "F:\Program Files\IBM\WebSphere\AppServer\runtimes"
  • If you are using ANT to build your Java Extensions add the following to the <javac ...> item
fork="yes" executable="C:\IBM\ibm_sdk60\bin\javac.exe"

How to check what files are updated by a FixPack

Review the .pak file contents, it is a zip file. Look in the path of "repository\itim.home\data\". This is the list of files that will be updated during installation of the noted Fix Pack.

How to set an ITIM session timeout (expiration)

  1. In the WebSphere console
  2. Click on Servers->Server Types->Application Servers->server1->Session Management->Set Timeout to 480
  3. Click Ok, and then Save.

How to get a list of all manual changes to workflows in TIM

Connect to the ITIMDB and run

select * from enrole.audit_event where itim_event_category='entityoperationmanagement' and timestamp > '20100409' order by timestamp

There is much more interesting stuff in that table that is not [easily] accessible in the UI

How to build an automatic to-do approver

You need to start by creating a HumanResourceMO object. If you use the constructor that takes an AccountMO as a third argument, and pass an AccountMO that represents an ITIM account, then you can then use the getAssignments method to get the to-do list for that ITIM account. Note that to-do lists are associated with ITIM accounts -- not the persons who own the accounts.

The getAssignments method will give you a collection of WorkflowAssignmentMO objects. Each of these represents one item in the ITIM account's to-do list. Most information about the to-do list item is available on the Assignment object returned by the WorkflowAssignmentMO's getData method. Either the Assignment's getActivityType or getActivitySubtype methods will tell you what type of to-do list item it is. I can't remember off the top of my head which of these will tell you whether you are dealing with an approval, RFI, work order, or compliance alert.

You can approve or reject approvals by calling the WorkflowAssignmentMO's complete method with an ActivityResult argument that tells it what the activity's result should be. You can create ActivityResult's for approval and rejection. The ActivityResult class has static fields that define the different result types. Work orders can be completed in the same way, but with an ActivityResult having a status of success, warning or failure. I've never been able to figure out how to complete an RFI or compliance alert through the APIs.

Setting a user's forgotten password information is not done through the to-do list assignments. This must be done using the ChallengeResponseManager class. It has been a while since I've worked with this, so I'm not certain how it responds when you have authenticated as a user who has not setup their challenge responses. I don't know if it returns null when you ask for the user's challenges, or if it returns a ChallengesAndResponses object that is empty. If you determine that a newly authenticated user has no challenge responses defined then you should then force them to do so. You load their challenges and responses into a ChallengesAndResponses object. This should be the same object returned by the getChallengesAndResponses method, if it returned one to you. You can then pass this object to one of ChallengeResponseManager's setChallengesAndResponses methods.

How to configure field population for TAM GSO provisioning policy

Edit the PP with the following

User Id *
Description
Distinguished Name *
Full Name *
Last Name *
{subject.getProperty("uid")[0];}
{subject.getProperty("uid")[0];}
{subject.getProperty("displayName")[0];}
{subject.getProperty("sn")[0];}
{subject.getProperty("x500uniqueidentifier")[0]}
{"cn=" + subject.getProperty("givenname")[0] + "." + subject.getProperty("sn")[0] +",c=us";}
{subject.getProperty("givenname")[0] + " " + subject.getProperty("sn")[0];}
{subject.getProperty("sn")[0];}

How to create a forgot your password link from TAM login page to TIMs challenge response interface

Make sure that the user name is sent correctly via POST to the forgot password servlet.

This is the javascript I used on the login page to have a "forgot your password" forward from TAM to TIM:

function forgotPassword() {
 if ( document.loginForm.username != null && document.loginForm.username.value.length > 0 ) {
  document.loginForm.logonID.value = document.loginForm.username.value;
  document.loginForm.action = document.location.protocol + "//" + document.location.host + "/enrole/question";
  document.loginForm.submit();
 } else {
  alert( "Please enter your username and press the \"Forgot your password?\" link" );
 }
}

This is the form used for POST-ing. Notice the hidden variable.

<FORM name="loginForm" METHOD=POST ACTION="/pkmslogin.form">
<table align="center" border="0" cellpadding="5" cellspacing="0" >
  <tr><td colspan=3 height=5></td></tr>
  <tr>
    <td> User Name:</td>
    <td> Password:</td>
    <td></td>
  </tr>
  <tr>
    <td><INPUT NAME="username" SIZE="15"></td>
    <td><INPUT TYPE="PASSWORD" NAME="password" SIZE="15"></td>
    <td><INPUT TYPE="image" VALUE="Login" src="/images/submit.png"></td>
  </tr>
    <td colspan=3><a href="Javascript:forgotPassword();">Forgot Your Password?</a>
    </td>
  <tr>
  </tr>
</table>
<INPUT TYPE="hidden" NAME="logonID"><INPUT TYPE="HIDDEN" NAME="login-form-type" VALUE="pwd">
</FORM>

Also make sure your TIM ChallengeResponse interface is exposed correctly via TAM's ACL's since anybody clicking on the "forgot your password" link is NOT authenticated. Attach ACL's like this:

Group iv-admin Tcmdbsvarxl
Group webseal-servers Tgmdbsrxl
User sec_master Tcmdbsvarxl
Any-other Trx
Unauthenticated Trx

If exposing the TIM's interface run the following:

object create /WebSEAL/WebSEALCluster/enrole/question Desc 8
object create /WebSEAL/WebSEALCluster/enrole/login_scripts.js Desc 8
object create /WebSEAL/WebSEALCluster/enrole/en/images Desc 8
object create /WebSEAL/WebSEALCluster/enrole/change_password Desc 8
object create /WebSEAL/WebSEALCluster/enrole/images Desc 8
object create /WebSEAL/WebSEALCluster/enrole/script_library.js Desc 8
object create /WebSEAL/WebSEALCluster/enrole/help.js Desc 8
object create /WebSEAL/WebSEALCluster/enrole/image_cache.js Desc 8
object create /WebSEAL/WebSEALCluster/enrole/adhoc.js Desc 8
acl attach /WebSEAL/WebSEALCluster/enrole/question ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/login_scripts.js ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/en/images ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/change_password ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/images ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/script_library.js ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/help.js ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/image_cache.js ACL-all
acl attach /WebSEAL/WebSEALCluster/enrole/adhoc.js ACL-all

How to determine the ITIM version if UI is not available

Look for ui.properties and search for the enrole.build.version string. It will contain the ITIM version and build information.

How to enable TIM agent tracing

use agentCfg -agent AGENTNAME and look for a Activity Logging - enable everything Now the importan part - RESTART the agent by doing StopAgent, StartAgent

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 fill in the AD manager attribute

This technote explains how to successfully populate the erADManager attribute on a Windows AD Provisioning Policy. The concepts presented her can be used to retrieve any information from the user's manager's record.

The erADManager attribute in a Windows AD Provisioning Policy should be set to the erADDistinguishedName attribute from the Windows AD account of the Person's manager. The following examples show how this information can be retrieved:

  1. If your Person records are not using an objectclass that contains a "supervisor" attribute, then you can use the following example javascript for the Manager attribute in the provisioning policy:
{var retval = "";
var mgr = subject.getProperty("supervisor");
if (mgr != null && mgr.length > 0) {
  var accounts = mgr[0].getProperty("account");
  if (accounts != null && accounts.length > 0) {
    for (i = 0; i < accounts.length; i++) {
      if (accounts[i].getProperty("erservice")[0] == "erglobalid=5139984751363320961,ou=services,erglobalid=00000000000000000000,ou=ibm,dc=com") {
         name = accounts[i].getProperty("erADDistinguishedName");
         if (name != null && name.length > 0) {
          retval = name[0];
         }
       }
     }
  }
}
return retval;}
</nowiki></pre>

In this example, we use the "supervisor" relationship to return a Person Entity based on the DN specified in the "manager" attribute on the Person record for this user. After confirming that a Person Entity was returned, we then use the "account" relationship to retrieve all of the accounts for the manager. Again, after confirming some data was returned, we iterate through each account looking for the AD account. The AD account is found by comparing the "erservice" attribute on the account with a hardcoded DN. You MUST change the DN to match the appropriate AD service in your environment. After the AD account is found, we retrieve the "erADDistinguishedName" attribute and return it.

  1. If your Person records are based on a customized objectclass that includes a "supervisor" attribute, then you will not be able to utilize the "supervisor" relationship built into ITIM. In that case, you will want to use the following javascript instead:
{var retval = "";
var mgr = subject.getProperty("manager");
if (mgr != null && mgr.length > 0) {
   var per = new Person(mgr[0]);
   var accounts = per.getProperty("account");
   if (accounts != null && accounts.length > 0) {
      for (i = 0; i < accounts.length; i++) {
          if (accounts[i].getProperty("erservice")[0] == "erglobalid=5469931471158645678,ou=services,erglobalid=00000000000000000000,ou=ibm,dc=com") {
             name = accounts[i].getProperty("erADDistinguishedName");
             if (name != null && name.length > 0) {
                retval = name[0];
             }
          }
      }
   }
}
return retval;}

This example is similar to the first, but with one small change. Instead of receiving back a Person Entity from the "supervisor" relationship, we retrieve the DN from the "manager" attribute and create a Person Entity based on it. From that point on, the two examples are identical. The catch here is that "new Person()" is not available in a provisioning policy by default. To enable it, you must do the following:

a) In /itim45/data/fesiextensions.properties, add the following line at the bottom: fesi.extension.ProvisioningPolicy.newPerson=com.ibm.itim.fesiextensions.PersonModelExtension b) Restart the enRole application for this change to take effect

Please keep in mind that these examples rely on working with accurate data. If your user's Person record does not have a "manager" defined, or the Person record specified in the "manager" record does not have a Windows AD account in ITIM, or the serviceDN specified in the "erservice" comparison is incorrect, then the "erADManager" attribute for the user's new Windows AD account will be blank. Furthermore, when a Windows AD account is first provisioned by ITIM, ITIM will not know about that accounts erADDistinguishedName attribute. What this means is that if you create a manager's AD account and then immediately create an employees AD account using the example above, it will not work. You MUST run a recon before the erADDistinguishedName attribute will be populated in ITIM. Also, these are just examples. They have been shown to work in default ITIM installations from 4.5.1 to 4.6, but there are no guarantees that they will work perfectly in your environment.

How to fix TIM case insensitivity of value change

Changing the case in TIM Identity data fields doesn't not work. To reproduce: Open an existing user, change a case of one or more letters in the name (cn), surname (sn), mail or postOfficeBox. Click submit. After the request is completed check the values. They have not changed. Issues it is causing: If HR changes case in these values for an existing user, the HR feed tries to update these values every night and never suceeds.

  • Can you check in the TDS web admin tool to see if these attribute values are set to case insensitive? If they are, please try changing them to 'case sensitive' and test again.
  • Equality is currently set to caseIgnoreMatch. So is ordering and the substring. Shall we set all to caseExact or only the equality? What side effects does this introduce?

How safe is the change since it is a schema change? Is there another way to instruct Tim to treat the case properly?

  • This is the only way I know of that would change the behavior. If LDAP doesn't care about case sensitivity, when we compare the entries, the entry won't be updated because the only difference is the case of the entry. Otherwise you would have to do a two step change. e.g. change entry "jon doe" to 'jon doe1', then to 'Jon Doe'.
  • I'm not aware of any side effects this would introduce other than achieve your desired behavior. I would set it to caseExact.
  • I'm not aware of any other way to achieve your desired behavior other than the two step change 'jon doe' change to 'jon doe1', then change to 'Jon Doe'.

This was suggested by development, and they were not aware of any dangers of making this change.

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.setAndEncyptPassword(password);
Entity.set(account); 

The setAndEncyptPassword method will be available only if you have added the line "javascript.password.access.enabled=true" to ITIM's data/fesiextensions.properties file.

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.setAndEncyptPassword(pwd);
Entity.set(account);

The setAndEncyptPassword method will be available only if you have added the line "javascript.password.access.enabled=true" to ITIM's data/fesiextensions.properties 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 get ITIM accounts who have answered challenge response

So, follow this workaround to get ITIM accounts who have defined Password Challenge-Response questions:

ldapsearch -D cn=<user> -w <password> -p <port> -h <hostname> -b dc=com -s sub "erlostpasswordanswer=*" eruid 

For instance,

ldapsearch -D cn=root -w ******** -p 389 -h <hostname> -b "ou=systemUser,ou=itim,ou=std,dc=com" -s sub "erlostpasswordanswer=*" eruid

How to get account entry and service entry templates from LDAP

Form templates - search for

erformname=er"serivcename"*

then select either AccountTemplate or ServiceTemplate. They are in

ou=formTemplates,ou=itim,ou=company,dc=com

How to get provisioning policy and javascript for entitlements from LDAP

objectclass=erProvisioningPolicy 

or search by the erPolicyItemName. They are located in

ou=policies,erglobalid=00000000000000000000,ou=company,dc=com
entitlements are in an xml file in the erEntitlements attribute

How to get service profile from LDAP

search for

erobjectprofilename=servicename*

they are in

ou=serviceProfile,ou=itim,ou=company,dc=com

How to import service profiles from command line

config_remote_services.cmd -profile PGEPeopleSoftUserProfile -jar c:\temp\PGEPeopleSoftUserProfile.jar 

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.

How to prevent deletion of certain accounts

If service accounts like 'root' are owned within ITIM and "Correct non-compliance" is specified for the related services, there is a possibility that they may be altered or deleted due to changes to related provisioning policies Solution

  1. Identify service accounts for all end-points.
  2. Do not adopt service accounts. Auto-provisioning actions will never apply to orphan accounts.
  3. If you do allow service accounts to be adopted, ensure that the provisioning policy allowing the entitlement remain tightly managed.
  4. Be wary of enabling "Correct non-compliance" for a service if you haven't addressed service accounts.
  5. Configure ITIM to exclude reconciliation of service accounts from the end-point(s). Review the topic "Excluding accounts from reconciliations" in ITIM's documentation. This procedure will allow specification of accounts by service type that are to be excluded from reconciliations. This is the safest technique to protect these accounts.

For example, here are sample ldif statements will exclude a series of TAM service accounts from being reconciled:

dn: ou=excludeAccounts, ou=itim, ou=IBM, dc=com
ou: excludeAccounts
objectClass: top
objectClass: organizationalUnit

dn: cn=TAM4Profile, ou=excludeAccounts, ou=ITIM, ou=IBM, dc=com 
erObjectProfileName: TAM4Profile
objectClass: top
objectClass: erIdentityExclusion
cn: TAM4Profile
erAccountID: sec_master
erAccountID: ivmgrd/master
erAccountID: ivmgrd/master
erAccountID: default-webseald/xxx
erAccountID: default-webseald/xxx
erAccountID: amwpm/xxxx
erAccountID: amwpm/xxx
erAccountID: default-webseald/xxx
erAccountID: default-webseald/xxx

http://www-1.ibm.com/support/docview.wss?rs=644&context=SSTFWV&q1=exclude+accounts&uid=swg21214530&loc=en_US&cs=utf-8&lang=en

How to unlock/restore accounts on a password reset

By default, ITIM doesn't allow users to unlock their accounts, they can only reset passwords - admins must do the unlocking. Currently, the Netware adapter is the only known adapter that allows you to configure an unlock on password reset.

You can allow users to self-service unlock accounts as part of challenge/response solution by adding an extension to the operational workflow for changepassword, using the built-in extension for restoreAccount. It is possible to always process a RESUME after a password reset.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox