Linking to Accounts on Other Resources

Identity Manager uses correlation
and confirmation rules to link accounts. A correlation rule looks for Identity Manager users
that might own an account. It returns a list of users that match the criteria
defined in the correlation rule. A confirmation rule tests an Identity Manager user
against an account to determine whether the user actually does own the account.
It returns true or false values. This two-stage approach allows Identity Manager to
optimize correlation, by quickly finding possible owners (based on name or
other attributes), and by performing expensive checks only on the possible
owners.

Before you begin using correlation and confirmation rules, you must
be familiar with the data that is present from the first data load. The Identity Manager accountId will always be present. If you performed a Load from File
or a Create bulk action, then the values in the heading row of the CSV file
are also present. If you performed a Load from Resource or reconciliation,
some key attributes found on the resource will be present, but others will
be present only if they are explicitly saved.

In addition, you must be familiar with the account data stored on the
secondary resources as well. Ideally, a secondary resource contains data that
overlaps with data that has already present in Identity Manager.

This can be more difficult than it sounds. Different resources often
have varying requirements for user accounts. As an example, the following
table compares the requirements and restrictions for a Windows account name
and a Solaris account name.

Table 4–3 Comparison of Windows Account Name
and Solaris Account Name Requirements

Characteristics

Windows

Solaris

Maximum length

20 characters

8 characters

Special characters permitted

All but “ / \ [ ] : ; | = , + * ? < >

period (.), underscore (_), and hyphen (-) only

Able to specify a full name

Yes

There is one comment field. Traditionally, the comment field lists the
user’s full name, but other information could be included.

Able to specify additional comments, such as employee ID

Yes

The differences between Windows and Solaris account names highlight
some of the difficulties in linking accounts:

Because of the differences in maximum length, the account
names will usually be different on these two systems. On Windows, users often
have an account name that matches their first and last name. On Solaris, account
names might be the concatenation of the first letter of the first name plus
the first seven digits of the last name. Therefore, a correlation rule that
compares account IDs will probably not be enough to link a Solaris account
to a Windows account.

To create a user account on Windows, the administrator must
supply a display name. Solaris user accounts do not require display names,
although the optional GECOS field can be used to specify a user’s name.
There are no guidelines about the contents or format of this field. A user’s
GECOS field might be blank or contain text unrelated to the user’s Windows
display name. Therefore, a correlation rule that compares full names might
not trigger as often as you would expect.

Consider the following questions as you prepare to link accounts:

Do you have users with similar names, such as Mary A. Jones
and Mary B. Jones, or John Doe Jr. and John Doe III? If so, how will you distinguish
between them?

Were account names on each resource defined in a consistent
manner? If yes, then it will be easier to define a rule that compares an account
ID on a resource with a value stored in Identity Manager.

Did users have the ability to edit resource account data?
If yes, then the data might not match values that are stored on a system that
users cannot change.

Defining Custom Correlation Keys

A rule cannot compare an account value on a resource with an Identity Manager value
unless the value is stored in the system. The accounts[Lighthouse] attribute
stores many of these values, but additional values must be added with the Extended
User Attributes Configuration object. The system does not save attributes
that are not registered in the configuration object.

By default, the following attributes are included as extended user attributes:

firstname

lastname

fullname

Note –

The fullname extended user attribute must be
added to the list of QueryableAttrNames.

If you want to use a different attribute, such as an employee ID as
part of a correlation rule, then you must add it to the User Extended Attributes
configuration object. Use the following steps to do this:

To Define a Custom Correlation Key

Access the Identity Manager debug page at http://PathToIDM/debug. The System Settings page is displayed.

Creating Custom Rules

Identity Manager predefines a number of correlation and confirmation
rules in sample/reconRules.xml. You can use these as a basis
for your own rules. Rules must be assigned a subtype of SUBTYPE_ACCOUNT_CORRELATION_RULE or SUBTYPE_ACCOUNT_CONFIRMATION_RULE.

The following rule compares the account.EmployeeId attribute,
which is defined on the secondary resource, with the EmployeeId attribute
that was previously loaded into Identity Manager. If the secondary resource
has an account.EmployeeId value, then the correlation rule
returns a list of users that match the EmployeeId.

In this example, the EmployeeId attribute has been
previously added to the User Extended Attributes and UserUIConfig configuration
objects. If this attribute has was not included as a default Identity Manager attribute
name for the resource, it must also be added or edited on the schema map for
the resource.

Correlation rules return a list of possible matches. If the results
are expected to return only one match, such as an employee ID, then no confirmation
rule would be needed. However, if there could be multiple matches, which could
be the case if correlation found accounts that matched by first and last name,
then a confirmation rule would be needed to further identify the match.

Rules can be added to Identity Manager by using the Identity Manager IDE,
importing an XML file, or editing and renaming an existing rule using the
debug page.

Manually Linking Accounts

Identity Manager provides several mechanisms that can be used to assign
accounts when correlation and confirmation rules do not find a match.

Using the Account Index

The Account Index records the last known state of each resource account
known to Identity Manager. It is primarily maintained by reconciliation, but
other Identity Manager functions will also update the Account Index, as needed.

Note –

Load from resource, load from file, and bulk actions do not update
the Account Index.

To view the account index, click the Resources tab, then click the Account
Index link on the left. Then navigate to a resource to display the status
of all accounts on that resource.

When you right-click on an uncorrelated account (represented in the
Account Index table with a situation of “UNMATCHED” and an Owner
of “_UNKNOWN_”), Identity Manager displays a menu that presents
you with the options of creating a new Identity Manager user account, running
reconciliation on a single account using the reconciliation policy in effect
for the resource, specifying an owner, or deleting or disabling the resource
account. If you select the “Specify Owner” option, Identity Manager displays
a screen that allows you to search for owners that might criteria that you
specify. Refer to Business Administrator's Guide for more information.

Enabling Self-Discovery

The Identity Manager User Interface can be configured to allow Identity Manager users
to discover their own resource accounts. This means that a user with an Identity Manager identity
can associate it with an existing, but unassociated, resource account. Self-discovery
can be enabled only on resources that support pass-through authentication.

To enable self-discovery, you must edit the End User Resources configuration
object, and add to it the name of each resource on which the user will be
allowed to discover accounts.

To Enable Self-Discovery

Access the Identity Manager debug page at http://PathToIDM/debug. The System Settings page is displayed.

After the <List> element, add <String>Resource</String>, where Resource matches the name of a resource
object in the repository. For example, to allow users to self-discover their
accounts on resources AD and Solaris,
edit the <List> element as follows:

When self-discovery is enabled, the user is presented
with a new menu item on the Identity Manager User Interface (Inform Identity Manager of Other Accounts) This area
allows him to select a resource from an available list, and then enter the
resource account ID and password to link the account with his Identity Manager identity.