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