Example Scenarios

This section provides scenarios that illustrate the process of loading accounts from one or more resources. The following scenarios discuss issues that might arise in your environment.

• Active Directory, SecurID, and Solaris

• LDAP, PeopleSoft, and Remedy

• Expedited Bulk Add

Active Directory, SecurID, and Solaris

A company wants to use Identity Manager to manage Active Directory, SecurID, and Solaris accounts. All workers have an Active Directory account, and most employees have a SecurID account. Only a fraction of employees have a Solaris account. After examining the account data on each resource, the Identity Manager administrator has determined the following attributes can be used as correlation keys.

Because all employees have an Active Directory account, it will be used as the first data loading resource. SecurID will be loaded second, because the account IDs on this resource match those on Active Directory. Account IDs are always unique, therefore this is a better correlation key than full name. The Active Directory and SecurID accounts are expected to correlate without problems.

Correlating the Solaris accounts will be difficult. The only correlation attribute that exists on Solaris accounts is the user’s full name. Solaris does not have individual attributes for defining first name and last name. As a result, the correlation rule will be a comparison of the string defined in the Solaris useradd -c command with the fullname value in Active Directory. The comparison will often fail, due to factors such as use of nicknames or extraneous spaces and punctuation.

Example Users

In this scenario, the following users demonstrate some of the possible problems you might encounter when loading accounts.

Loading Active Directory Accounts

Use the following steps as a guideline for using reconciliation to load Active Directory accounts into Identity Manager.

To Load Active Directory Users

1. From the Resources page in the Administrator Interface, select the Windows 2000/ Active Directory resource from the New Resource pull-down menu. Then configure the adapter.

   Make sure you do not delete the accountId or fullname Identity Manager user attribute from schema map. Also make sure the identity template is correct. See the online help and the Resource Reference for more information about configuring the adapter.

2. (Optional) Edit the account and password policies as desired. See Setting Account ID and Password Policies for more information.

3. (Optional) Create a user form that will be used for reconciliation. See Assigning User Forms for more information.

4. (Optional) Create an Identity Manager user for performing data loading. Assign the user form created in the previous step to the user.

5. Configure the reconciliation policy for the resource. On the first resource, the correlation rule is not important, and the confirmation rule is not used when creating Identity Manager users. Since this is the first resource, you probably want to assign the UNMATCHED situation to the value “Create new Identity Manager user based on resource account.”

6. If you created a user to perform data loading, log in as that user. This step is not necessary for reconciliation, but would be for Load from File, Load from Resource, or Bulk actions.

7. Reconcile the Active Directory resource.

Results

If you used the default Identity Manager account policy and default Active Directory identity template, Identity Manager will not create an Identity Manager user that links to Theodore Benjamin’s Active Directory account, because his name contains more than 16 characters. For this example, the account ID policy was set to 25 characters.

Identity Manager creates user accounts for all resource accounts with a situation status of CONFIRMED. This should include all users that passed the password and account ID policies. Unless your user form specified otherwise, the Identity Manager account name will be the same as Active Directory login name.

Loading SecurID Accounts

When SecurID is implemented, SecurID user records are usually imported from a Microsoft Security Accounts Manager (SAM) database or from an LDAP server. As a result, the SecurID account IDs match those from the source. This makes correlating users a relatively simple task, because there is a one-to-one correlation between SecurID and Active Directory accounts. The User Name Matches Account ID correlation rule can be used to quickly link these accounts.

To load SecurID accounts, perform the procedure described in Loading Active Directory Accounts, with the following modifications:

• When you are configuring the SecurID adapter, ensure that you do not delete the accountId Identity Manager user attribute.

• Configure the reconciliation policy as follows:

  • Set the correlation rule to “User Name Matches Account ID.”

  • Since Active Directory is considered to be an authoritative source, and SecurID relies on Active Directory account information, you might want to set the UNMATCHED situation option to “Delete Resource Account” or “Disable Resource Account.” The UNASSIGNED situation should be set to “Link resource account to Identity Manager user.”

All SecurID accounts should correlate with the Active Directory account. Perform any additional steps to resolve UNMATCHED or DISPUTED situations.

Loading Solaris Accounts

In this scenario, the fullname attribute is the only correlation key. This is a weak correlation key, because differences in spacing and punctuation guarantee matches will fail. In addition, users can change their display names with the Solaris chfn command. Even if full names once matched, they might not agree if any users have run the chfn command.

By default, the fullname attribute is not queryable. To enable this feature, you must edit the UserUIConfig configuration object, and add the fullname attribute to the <QueryableAttrNames><List> element. See Defining Custom Correlation Keys for more information.

You will also need to create a custom rule to correlate fullname attributes. The following example, which is named “Correlate Full Names”, performs the correlation. It compares the value of the account.Description attribute from the Solaris resource to the fullname attribute, a system attribute that was populated from Active Directory.

<Rule subtype=’SUBTYPE_ACCOUNT_CORRELATION_RULE’ name=’Correlate Full Names’
   <cond>
      <ref>account.Description</ref>
      <list>
         <new class=’com.waveset.object.AttributeCondition’>
            <s>fullname</s>
            <s>equals</s>
            <ref>account.Description</ref>
         </new>
      </list>
   </cond>
</Rule>

This rule compares the Description attribute from the Solaris resource with the Identity Manager fullname attribute. If the two attributes match, the accounts are correlated, with a situation of CONFIRMED.

To load Solaris accounts, perform the procedure described in Loading Active Directory Accounts, with the following modifications:

• When you are configuring the Solaris adapter, ensure that you do not delete the accountId or Description Identity Manager user attribute.

• Configure the reconciliation policy as follows:

  • Set the correlation rule to “Correlate Full Names” (the example rule).

  • There could be numerous Solaris accounts that do not correlate with the accounts already loaded into Identity Manager. Set the UNASSIGNED situation to “Link resource account to Identity Manager user”. In most cases, you should set the UNMATCHED situation to “Do nothing”. Deleting or disabling unmatched users could result with a loss of data or productivity.

The following table describes the users in this dataloading scenario.

In this example, only accounts for Isabelle Moreno can be expected to correlate.

• The accounts for Anthony Harris, John Thomas (Jr.), Robert Blinn, and Theodore Benjamin will not correlate because the Active Directory fullname attributes do not exactly match the Solaris Description attributes. These accounts will have a situation of UNMATCHED. In this scenario, the Solaris account names are based on first initial plus last name. With the exception of the John Thomas account, assigning these unmatched Solaris accounts is easy.

• The Solaris accounts jthomas and jthomas2 will have a situation of DISPUTED. Both of these accounts have a Description value of John Thomas. You must find another means to determine which user Solaris accounts jthomas and jthomas2 belong to. Ideally, you could use a confirmation rule to distinguish between the two accounts. However, Solaris and Active Directory accounts do not contain enough intersecting attributes to create a confirmation rule.

LDAP, PeopleSoft, and Remedy

In this scenario, the LDAP or PeopleSoft resource could theoretically be the primary resource.

• If all employees and contractors are tracked in PeopleSoft, then this application can be considered an authoritative resource.

• If all employees have LDAP accounts, then LDAP could be considered an authoritative resource.

Remedy is not a candidate to be the primary resource, because only a small percentage of workers have a Remedy account.

In many cases, if you have multiple authoritative resources, then any of those resources can be loaded first. However, the PeopleSoft Component adapter performs Active Sync functions only. (There is another PeopleSoft adapter available, but it is limited in scope.) The PeopleSoft Component adapter does not perform reconciliation, and as a result, reconciliation policy cannot be set for the resource. There are no correlation rules available, so the PeopleSoft accounts must be loaded first. The Identity Manager account names will match PeopleSoft EMPLID (employee ID) values.

The PeopleSoft employee ID is ideal as a correlation key, because it is unique for all users defined in the system. The LDAP inetOrgPerson object contains an employeeNumber attribute. An employee ID could also be stored in an attribute with a label such as Description, or in a custom attribute. This scenario assumes the employeeNumber LDAP attribute is in use.

The Remedy adapter does not provide default attributes. You must customize the adapter to fit your environment. Because the Remedy application is often configured to send email when a request enters the system, the e-mail attribute should be available. The LDAP inetOrgPerson object also contains the mail attribute. Therefore, the e-mail address will be the correlation key.

The following table lists the correlation keys for each resource in this scenario.

Example Users

In this scenario, the following users demonstrate some of the possible problems you might encounter when loading accounts.

Loading PeopleSoft Users

Use the following steps as a guideline for using reconciliation to load PeopleSoft accounts using Active Sync into Identity Manager.

To Load PeopleSoft Users

1. From the Resources page in the Identity Manager Administrator Interface, select the PeopleSoft Component resource from the New Resource pull-down menu. If this resource is not displayed, click the Configure Managed Resources button and add com.waveset.adapter.PeopleSoftComponentActiveSyncAdapter as a custom resource. This adapter requires the installation of a JAR file provided by PeopleSoft. See the Resource Reference for more information.

2. Configure the adapter. Make sure you do not delete the accountId or fullname Identity Manager user attribute from schema map. Also make sure the identity template is correct.

3. (Optional) Edit the account and password policies as desired. See Setting Account ID and Password Policies for more information.

4. (Optional) Create a user form that will be used for data loading. The $WSHOME/sample/forms/PeopleSoftForm.xml file can be used as a foundation. See Assigning User Forms for more information.

5. Start ActiveSync on the PeopleSoft adapter.

Results of This Scenario

Identity Manager loads all users unless the user form indicates that an account should not be loaded. In this scenario, Renée LeBec does not have an LDAP or Remedy account. Presumably, she no longer works for the company. If you used the default PeopleSoft form, then Identity Manager disables PeopleSoft accounts for terminated employees.

The accounts for William Cady and John P. Thomas are not created because they are not defined within PeopleSoft.

Loading LDAP Users

In this scenario, the employeeNumber attribute in the LDAP inetOrgPerson object is the correlation key. This attribute is not listed by default in the schema map for the LDAP adapter, so you must add it manually. For this example, add the attribute EmployeeId to the Identity Manager User Attribute side of the schema map, and employeeNumber to the Resource User Attribute side.

The PeopleSoft adapter uses the Identity Manager attribute name EmployeeId by default. This value was chosen to maintain consistency between LDAP and PeopleSoft, although this is not required.

The e-mail address will be the correlation key for the Remedy resource, but it must be set-up and configured before you load LDAP accounts. The inetOrgPerson object contains the mail attribute, which will be the correlation key for loading Remedy accounts. The mail attribute also must be added to the schema map. Add the email attribute to the Identity Manager User Attribute side of the schema map, and mail to the Resource User Attribute side. email is a predefined Identity Manager attribute, so it is easier to user this attribute, rather than editing the User Extended Attributes or UserUIConfig configuration objects to include a mail attribute.

Identity Manager stores account IDs in the User object in the attribute resourceAccountIds. This is a multi-valued attribute, with each value taking the form accountId@objectId. You can create a rule that will compare the EmployeeId value from LDAP to the PeopleSoft accountId using the following rule:

Comparing EmployeeId value from LDAP to PeopleSoft accountId

<Rule subtype=’SUBTYPE_ACCOUNT_CORRELATION_RULE’ name=’Correlate EmployeeId with accountId’>
   <cond>
      <ref>account.EmployeeId</ref>
      <list>
         <new class=’com.waveset.object.AttributeCondition’>
            <s>resourceAccountIds</s>
            <s>startsWith</s>
            <concat>
               <ref>account.EmployeeId</ref>
               <s>@</s>
            </concat>
         </new>
      </list>
   </cond>
</Rule>

In this scenario, it is not necessary to add attributes to the User Extended Attributes or UserUIConfig configuration objects, because the accountId and email attributes are always available to the system.

To Load LDAP Accounts

1. From the Resources page in the Administrator Interface, select the LDAP resource from the New Resource pull-down menu. Then configure the adapter as follows:

   1. Add the EmployeeId and email Identity Manager User attributes.

   2. Make sure you do not delete the accountId Identity Manager user attribute from the schema map.

   3. Ensure that the identity template is correct.

      See the online help and the Resource Reference for more information about configuring the adapter.

2. Configure the reconciliation policy for the resource as follows.

   1. Set the Correlation Rule to Correlate EmployeeId with accountId.

   2. Set the following situation values:

      Set the UNASSIGNED situation to “Link resource account to Identity Manager user”.

      Set the UNMATCHED situation to an appropriate action. You might need to discuss with the PeopleSoft administrator about the possibility of adding users who are discovered on other resources. If you select the “Create new Identity Manager user based on resource account” option, the Identity Manager user will have, by default, an account name based on the LDAP cn attribute.

3. Reconcile the LDAP resource.

Results of This Scenario

In this scenario, accounts for William Cady, Josie Smith, and John P. Thomas will be in the UNMATCHED state. For Josie Smith, the employee ID values on the PeopleSoft and LDAP resources do not match. Because employee IDs are generated by PeopleSoft, then LDAP value is incorrect. Correct the mistake and reconcile again.

William Cady and John P. Thomas are not defined in PeopleSoft. As mentioned in step 2 of loading LDAP account procedure, you should consider whether the accounts need to be added to PeopleSoft.

Loading Remedy Users

The Remedy adapter does not have predefined account attributes. You must add these attributes to the schema map. Remedy uses integers to uniquely identify each attribute that it tracks. For example, the Remedy account ID might be assigned a value such as 1002000100. These Remedy attribute numbers must be added as Resource User Attributes on the schema map. At minimum, you must add the following Identity Manager User attributes:

• accountId

• email (the correlation key)

The USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR correlation rule will link the Remedy accounts to the Identity Manager accounts.

To Load Remedy Accounts

1. From the Resources page in the Identity Manager Administrator Interface, select the Remedy resource from the New Resource pull-down menu. Then configure the adapter as follows:

   At minimum, add the accountId and email Identity Manager User attributes. Other attributes can also be added.

   See the online help and the Resource Reference for more information about configuring the adapter.

2. Configure the reconciliation policy for the resource as follows.

   1. Set the Correlation Rule to USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR.

   2. Set the following situation values:

      1. Set the UNASSIGNED situation to “Link resource account to Identity Manager user”.

      2. Set the UNMATCHED situation to an appropriate action.

   3. Reconcile the Remedy resource.

Results of This Scenario

The Remedy accounts for William Cady, Eric D’Angelo, and John P. Thomas correlated successfully because the email addresses defined in LDAP and Remedy matched. The Remedy account for Robert Blinn did not correlate. The e-mail address on Remedy was an alias. The other users in this scenario do not have Remedy accounts.

Expedited Bulk Add Scenario

The following procedure illustrates how a few users can be quickly added to Identity Manager using Create actions. Any resources referenced in the CSV file must be defined within Identity Manager before the CSV file is loaded into the system.

To Perform a Bulk Add

1. Generate a CSV file that contains information needed to perform a Create bulk action. See Create Bulk Actions for more information about the format of the CSV file.

2. If your CSV file does not contain passwords, set the default Password Policy Options so that passwords are generated by the system. To do this, click the Configure tab, then Policies on the left. Click the Default Identity Manager Account Policy link. Then select the Generated option from Password Provided by drop-menu.

3. Create a new provisioning task based on the default Create User provisioning task.

   From the XML view, in the TaskDefinition tag, edit the value of the resultLimit parameter to 0. This value determines the number of seconds the results of the task is to be retained.

   Then delete the following sections from the task:

   <Activity id=’1’ name=’Approve’> ... </Activity> <Activity id=’3’ name=’Notify’> ... </Activity>

   ---

   Note –

   The activity calling to the provisioner must remain, or users will not be created properly.

   ---

   Be sure to rename the task, to a value such as Fast Create User.

4. Create a new user form based on the default User form.

   From the XML view, replace the entire <Form>... </Form> structure with the following:

   <Form help=’account/modify-help.xml’> <Field name="viewOptions.Process"> <Expansion> <s>Fast Create User</s> </Expansion> </Field> </Form>

   Be sure to rename the user form, to a value such as Fast User Form.

5. Create an Identity Manager account that will be used to load accounts into Identity Manager. Assign the user form created in Expedited Bulk Add Scenario to this user.

6. Log in to Identity Manager using the account created in the previous step.

7. Run the Create bulk action.