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.