Chapter 4 Dataloading Scenario

This chapter provides tips to consider when preparing to load account information into Identity Manager. It also includes sample scenarios that illustrate some issues that you might encounter.

Assessing Your Environment

Before you can begin loading user account information into Identity Manager, you determine which know the following questions applies to your environment:

Is there an authoritative resource for all user IDs?

Can a complete list of users be obtained from resources that overlap, but for which there is a correlation key?

Can a list of users be obtained from overlapping resources that do not have a correlation key?

If the answer is no to all these questions, then the process of loading accounts is problematic. Load user accounts as best you can, and plan to delegate creation of other Identity Manager users to departmental administrators or end-users.

Choosing the First Resource

Ideally, the first resource you use to load accounts into Identity Manager has the following characteristics:

References a comprehensive set of users. The goal of an initial load is get as many accounts into Identity Manager as possible. Thus, the following applications might be a good choice:

A Human Resources application, such as PeopleSoft or SAP. (If the application does not contain contractors and other temporary workers, be sure to load those accounts separately.)

A directory-based application, such as LDAP or Active Directory. A majority of users are often defined in a central organization or organization unit.

Contains enough information to construct an Identity Manager account ID. Each Identity Manager account ID must be unique. Ideally, your resource will have an attribute that is guaranteed to be unique and can be used as a Identity Manager account ID. Examples include an employee IDs or Active Directory sAMAccountName attributes. First and last names can also be concatenated to produce an account ID, but this technique might not guarantee a unique Identity Manager account will be generated.



Note	The Lighthouse account is now called the Identity Manager account. You can override this name change through the use of a custom catalog. See Appendix B, "Enabling Internationalization" for information about custom catalogs.

Stores user attributes that can be used correlation keys. To link resource accounts in Identity Manager, you must have attributes that have the same values across two or more resources. Ideally, the values on the secondary resources will always perfectly match values on the first resource. In addition, it would be ideal if the values on the secondary resource are unique within that resource. The best attributes include employee ID and full name, but any other attribute that is present and consistent across multiple resources is acceptable.

Contains data that can be considered authoritative. If users can edit their own account data, then the data might not be consistent across systems.

The following diagram illustrates a small scenario in which a company has three types of resources. Most of the company’s workers are defined in a Human Resources application, such as PeopleSoft or SAP. However, the company does not enter contractors in the HR application, so the contractors cannot be loaded into Identity Manager using this application. The Active Directory also defines most, but not all, users. (These users might be factory workers with no need for computer access.) Thus, the majority of users are defined in both resources, but neither contains all the users. Some workers also have UNIX accounts.

Which resource should be selected as the first resource? The UNIX resource can be safely eliminated, because it does not contain a comprehensive set of users. Active Directory and the HR application contain about the same number of users, so neither has a clear advantage.

Factors that can help determine whether the Active Directory or HR application should be loaded first include the following:

Urgency to manage accounts within Identity Manager. If the workers not defined in Active Directory (that is, they are defined in the HR application only) do not have any additional resource accounts, such as UNIX or other systems, then the HR application might not be as crucial as the Active Directory resource.

Correlation keys. If one resource has attributes that are also on the UNIX accounts, then that attribute might be a better choice.

Identity Manager login names. If one resource creates a more desirable login name of Identity Manager, then this can be a deciding factor.

Choosing the First Data Loading Process

After you have chosen which resource will be used as the starting point for loading user data into Identity Manager, you must decide which process to use. The following table provides a summary of the benefits and drawbacks of each data loading process. A discussion of each data loading process follows.

Table 4-1 Overview of Data Loading Processes
Data Loading Process	Advantages	Disadvantages
Load from File	Quickest loading process. Easy to control which attributes are loaded. Easier to configure and faster than reconciliation.	Requires customer time to generate a CSV file from a resource. Requires a full reconciliation before production. Cannot be used to update accounts.
Load from Resource	Works with all resources Easier to configure than reconciliation	Cannot pick and choose which resource accounts will be loaded. Requires a full reconciliation before production.
Create bulk action	Allows you to add multiple accounts simultaneously to an Identity Manager user.	Slower than loading from resource or reconciliation. Cannot easily generate the CSV file from resources. Requires detailed knowledge of Identity Manager to make full use of this feature. Requires a full reconciliation before production.
Reconciliation	Can implement all aspects of reconciliation policy Using reconciliation up-front prevents last-minute surprises	Cannot pick and choose which resource accounts will be loaded. Can take a large amount of time to load all accounts in large environments (over 50,000 employees)
ActiveSync	If at all possible, avoid choosing ActiveSync as the means to load account information. ActiveSync is designed to detect changes, and as a result, initial loads are slow.

Load from File

The Load from File process seeds Identity Manager accounts with basic values, such as account ID, first and last name, and e-mail address. The account ID is the only required attribute.

The Load from File process imports the contents of a comma-separated values (CSV) file into Identity Manager. The top line of this file contains a list of attribute names, separated by commas. Each subsequent line contains a series of corresponding attribute values. All attributes must also be separated by commas.

Load from File also accepts XML files, but the syntax of an XML file must match the syntax generated by the Extract to File feature. This format is beyond the scope of this discussion.

The data in a CSV file is often exported from a resource. For example, the Active Directory Users and Computers MMC (Microsoft Management Console) allows you to export the contents of an organization unit directly into a CSV file. The console exports all users defined in the organization unit as well as the displayed attributes. Therefore, you should verify only attributes that will be managed by Identity Manager are displayed in the Active Directory Users and Computers MMC. Including extraneous attributes will cause loading times to increase.

Some resources are not capable of directly exporting user account information to CSV format. If you wish to use to this method of data loading, you might need to extract the information programmatically or add data manually.


Note	.Load from File also accepts XML files, but the syntax of an XML file must match the syntax generated by the Extract to File feature. This format is beyond the scope of this discussion.

The attributes listed in the CSV file must be pre-defined as user view attributes. Basic attributes such as accountId, email, password, and confirmpassword are pre-defined. Others are defined in the extended user attributes configuration object. By default, this object adds firstname, lastname, and fullname to the list of available attributes.

If you want to retain values for attributes that are not pre-defined in Identity Manager, such as an employee ID, you must add them to the Extended User Attributes Configuration object.

The Load from File process configuration page prompts for a correlation and confirmation rules. Since this is the first attempt to load data, select the User Name Matches AccountId correlation rule. You do not need a confirmation rule.

It is important to remember that the data contained in the CSV file is used for Identity Manager accounts only. Even if the data is exported directly from Active Directory, for example, the data is not linked to any Active Directory accounts or resources unless you have created a custom user form to do this. Without a custom user form, a different data loading mechanism must be used to link resource account data to an Identity Manager user. User forms are discussed briefly in Assigning User Forms.

The Load from File process does not add entries into the Identity Manager account index. Therefore, you must perform a full reconciliation, or update the users, before your Identity Manager deployment is complete. In addition, the Load from File does not run any workflows when creating users in Identity Manager.

Load from Resource

Although the configuration pages for the Load from Resource and Load from File processes are almost identical, the Load from Resource is functionally closer to reconciliation. The Load from Resource and reconciliation processes pull data from the resource, and then adds the accounts it finds to Identity Manager. Therefore, the adapter must be configured before you perform either of these operations.

Load from Resource is faster on the initial run than reconcile but does not populate the Account Index. Reconcile on the second execution running in Incremental mode should be faster than Load from Resource. If reconciliation is the desired tool as the long-term solution, then use reconciliation for the initial load of users.


Note	.The Load from File process does not add entries into the Identity Manager account index. Therefore, you must perform a full reconciliation, or update the users, before your Identity Manager deployment is complete. In addition, the Load from File does not run any workflows when creating users in Identity Manager.

A user form can be used to set the account ID, place users in an Organizations, and perform other related tasks related to creating users. See Assigning User Forms for more information.

When you seed Identity Manager accounts for the first resource using Load from Resource, the correlation and confirmation rules are not very meaningful. Select the User Name Matches AccountId correlations rule. You do not need a confirmation rule.

Create Bulk Actions

The Create bulk action loads data from a CSV file. Unlike the Load from File process, the create bulk action allows you to define any writable attribute in the user view, including Identity Manager-specific attributes, global attributes, and resource account attributes. This flexibility means that it will probably be more difficult to assemble a bulk actions CSV file. If your bulk actions affect multiple resources, you will need to find a way to merge resource data into a single CSV file. However, you could also define a simpler bulk action file and use subsequent update actions to load data into Identity Manager user accounts.

Bulk actions runs the default workflows for create, update, and delete actions. This slows down the process of loading user accounts, but add greater flexibility.

The following example illustrates the use of Create bulk actions only. The command and user attributes are required.

The following example illustrates how the Create and Update bulk actions can be used in two separate files.


Note	.The Load from Resource process does not add entries into the Identity Manager account index. Therefore, you must perform a full reconciliation, or update the users, before your Identity Manager deployment is complete. In addition, the Load from File does not run any workflows when creating users in Identity Manager.

command,user,waveset.resources,password.password,password.confirmPassword,a ccounts[MyAD].description,

Create,John Doe,MyAD,changeit,changeit,John Doe,John Doe

Create,Jane Smith,MyAD,changeit,changeit,
Jane Smith

command,user,waveset.resources,password.password,password.confirmPassword,a ccounts[MySolaris].comment

Update,John Doe,MySolaris,changeit,changeit,John Doe

Update,Jane Smith,MySolaris,changeit,changeit,Jane Smith

Creating accounts using bulk actions does not add entries into the Identity Manager account index. Therefore, you must perform a full reconciliation before your Identity Manager deployment is complete.

Reconciliation

The first reconciliation of a resource will probably take longer than any subsequent reconciliation. You can expect the first reconciliation of a resource to add a large number of Account Index entries.


Note	. Creating accounts using bulk actions does not add entries into the Identity Manager account index. Therefore, you must perform a full reconciliation before your Identity Manager deployment is complete.

Preparing for Data Loading

Review the following sections before you begin the process of loading account information into Identity Manager:

Configuring an Adapter

Setting Account ID and Password Policies

Creating a Data Loading Account

Assigning Forms

Configuring an Adapter

To manage accounts on resources, you must configure an adapter for each source of account information. If you are using the Load from File process or bulk actions, then the adapter configuration can wait until you are ready to reconcile. Otherwise, the adapter must be configured before you can load data into Identity Manager.

For general information about configuring an adapter, see Identity Manager Administration. For detailed information about a specific adapter, refer to the Identity Manager Resources Reference or the online help.

Setting Account ID and Password Policies

When you load account data from a resource via Load from Resource, reconciliation, or Active Sync, Identity Manager does not obtain the password from the resource. (It would be a security breach on the part of the resource if it yielded the password.) Therefore, the Identity Manager account passwords will not be the same as the those on the resource. By default, Identity Manager generates a random password that must be reset. However, you can also use the password view in the user form to specify a temporary password, such as a literal string that is the same for everyone, or is the same as the Identity Manager account ID. See Assigning User Forms and the chapter titled Identity Manager Views for more information.

For bulk actions, and Load from File, you can specify password values in the CSV file. These should be considered temporary passwords that users must change.

Policies establish limitations for Identity Manager accounts, and are categorized as:

Identity Manager account policies -- Use these to establish user, password, and authentication policy options. Identity Manager account policies are assigned to organizations or users.

Resource password and account ID policies -- Use these to set or select length rules, character type rules, and allowed words and attribute values.

Make sure you make any updates to the default policies before you begin loading account information into Identity Manager.

The following table lists the policies provided with Identity Manager as well as the default settings.

Table 4-2 Default Identity Manager Policies
Policy Name	Default Characteristics
AccountId Policy	Account IDs must have a minimum length of 4 characters and a maximum length of 16 characters.
Default Lighthouse Account Policy	Sets the account ID and password policies to AccountId Policy, and Password Policy. Passwords are generated by Identity Manager, rather than by users.
Password Policy	Passwords must have a minimum length of 4 characters and a maximum length of 16 characters.The password cannot contain the user’s e-mail, first name, last name, or full name.
Windows 2000 Password Policy	Passwords must have a minimum length of 6 characters. Passwords must have 3 of the following characteristics: 1 numeric character 1 uppercase letter 1 lowercase letter 1 special character In addition, the password cannot contain the account ID.

See the chapter titled Identity Manager Users in Identity Manager Administration for more information about account and password policies.

Creating a Data Loading Account

It is recommended that you create a separate administrator account to perform data loading for the following reasons:

Data loading actions can be tracked more easily when auditing is enabled.

Every Identity Manager administrator is assigned a user form that creates and edits Identity Manager users. When you create an account for data loading, you can specify a streamlined form that runs quicker than the default forms. See the next section for information.

See Identity Manager Administration for more information about creating accounts.

Assigning User Forms

In the context of data loading, user forms are used to perform background processing. For example, forms can work in conjunction with resource adapters to process information from an external resource before storing it in the Identity Manager repository. They can also be used to place users in the correct Organization based on input user data.

The user view is a data structure that contains all available information about an Identity Manager user. It includes:

Attributes stored in the Identity Manager repository

Attributes fetched from resource accounts

Information derived from other sources such as resources, roles, and organizations

Views contain many attributes, and a view attribute is a named value within the view (for example, waveset.accountId is the attribute in the user view whose value is the Identity Manager account name).

Most form field names are associated with a view attribute. You associate a field with a view attribute by specifying the name of the view attribute as the name of the form field. For more information on the user view, including a reference for all attributes in the user view, see the chapter titled Views.

firstname

lastname

fullname

waveset.accountId

waveset.organization

EmployeeId

The waveset.accountId and waveset.organization are values specific to Identity Manager. The EmployeeId attribute is a customized attribute. Its use is illustrated in Defining Custom Correlation Keys.

Identity Manager provides numerous forms that are pre-loaded into the system. Additional forms are also available in the $WSHOME/sample/forms directory. Many of the forms in this directory are resource-specific. You might wish to review these forms with the Identity Manager IDE to determine whether they should be used in production.

To increase performance during bulk operations, the user form assigned to an administrator should be as simple as possible. If you want to create a form for data loading, then you can remove code that is designed to display data. Another example of simplifying the form would be if you use bulk add actions. Your CSV file could define basic attributes such as firstname and lastname. These attributes could then be removed from the administrator’s user form. See the chapter titled Identity Manager Forms for more information about creating and editing forms.


Note	Do not directly modify a form provided with Identity Manager. Instead, you should make a copy of the form, give it a unique name, and edit the renamed copy. This will prevent your customized copy from being overwritten during upgrades and service pack updates.

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.

Do you have users with similar names, such as Mary A. Jones vs. Mary B. Jones, or John Doe Jr. vs. 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.

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:

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

Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

Select the edit link for User Extended Attributes.

Add the new attributes to the List element, for example:

<String>EmployeeId</String>

The attribute must be defined as an Identity Manager attribute on the Account Attributes (schema map) page for the resource.

Save your changes. Identity Manager returns to the System Settings debug page.

The custom attribute must also be added to the QueryableAttrNames element in the UserUIConfig configuration object.

Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

Select the edit link for UserUIConfig.

Add the new attributes to the <QueryableAttrNames><List> element, for example:

<String>EmployeeId</String>

Save your changes. Identity Manager returns to the System Settings debug page.

Restart your application server.

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.

<Rule subtype='SUBTYPE_ACCOUNT_CORRELATION_RULE' name='Correlate Employee IDs'

<cond>

<ref>account.EmployeeId</ref>

<list>

<s>EmployeeId</s>

<s>equals</s>

<ref>account.EmployeeId</ref>

</new>

</list>

</cond>

</Rule>

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

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.


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

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 Identity Manager Administration 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 do this:

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

Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

Select the edit link for End User Resources.

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:

<List>

<String>Solaris</String>

</List>

Save your changes. Identity Manager returns to the System Settings debug page.

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.

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:

Table 4-4 Possible Correlation Keys
Possible Correlation Keys	Active Directory	SecurID	Solaris
Account ID matches AD	N/A	Yes	No
Employee ID	Yes	No	No
Full name	Yes	Yes	Yes (Description attribute)

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.

Table 4-5 Dataloading Scenario: Potential Problems during Account Loading
Worker name	AD and SecurID Logon Name	AD Full Name	Solaris Account Name	Solaris Description
Anthony Harris	AJ Harris	Anthony J Harris	ajharris	A.J. Harris
Isabelle Moreno	Isabelle Moreno	Isabelle Moreno	imoreno	Isabelle Moreno
John Thomas (Sr.)	John Thomas	John Thomas	jthomas	John Thomas
John Thomas (Jr.)	John P. Thomas	John P. Thomas	jthomas2	John Thomas
Robert Blinn	Robert Blinn	Bob Blinn	rblinn	Bob Blinn
Theodore Benjamin	Theodore Benjamin	Theodore Benjamin	tbenjami	Ted Benjamin

Loading Active Directory Accounts

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

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 Identity Manager Resources Reference for more information about configuring the adapter.

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

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

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

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

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.

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.

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

Results

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>

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

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.

Results

Table 4-6 Users in Dataloading Scenario
Worker name	AD Full Name	Solaris Account Name	Solaris Description
Anthony Harris	Anthony J Harris	ajharris	A.J. Harris
Isabelle Moreno	Isabelle Moreno	imoreno	Isabelle Moreno
John Thomas (Sr.)	John Thomas	jthoma	John Thomas
John Thomas (Jr.)	John P. Thomas	jthomas2	John Thomas
Robert Blinn	Bob Blinn	rblinn	Bob Blinn
Theodore Benjamin	Theodore Benjamin	tbenjami	Ted Benjamin

In this example, we can expect that only accounts for Isabelle Moreno will 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, we’ll assume the e-mail attribute is 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.

Table 4-7 Dataloading Scenario: Correlation Keys for Each Resource
Possible Correlation Keys	PeopleSoft	LDAP	Remedy
Employee ID	Yes	Yes	No
E-mail address	No	Yes	Yes

Example Users

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

Table 4-8 Deployment Scenario: Possible Problems during Account Loading
Worker name	PeopleSoft EMPLI	LDAP Employee Number	LDAP Email (@example.com)	Remedy Email (@example.com)
Robert Blinn	945	945	Bob.Blinn	bblinn
William Cady	None	None	William.Cady	William.Cady
Eric D’Angelo	1096	1096	Eric.D’Angelo	Eric.D’Angelo
Renée LeBec	891	None	None	None
Josie Smith	1436	1463	Josie.Smith	None
John Thomas	509	509	John.Thomas	None
John P. Thomas	None	None	John.P.Thomas	John.P.Thomas

Loading PeopleSoft Users

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

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 Identity Manager Resources Reference for more information.

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.

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

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

Start ActiveSync on the PeopleSoft adapter.

Results

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.


Note	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:

Code Example 4-1 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>


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

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:

Add the EmployeeId and email Identity Manager User attributes.

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

Ensure that the identity template is correct.

See the online help and the Identity Manager Resources Reference for more information about configuring the adapter.

Configure the reconciliation policy for the resource as follows.

Set the Correlation Rule to Correlate EmployeeId with accountId.

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.

Reconcile the LDAP resource.

Results

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.

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 Identity Manager Resources Reference for more information about configuring the adapter.

Configure the reconciliation policy for the resource as follows.

Set the Correlation Rule to USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR.

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.

Reconcile the Remedy resource.

Results

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.

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.

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 Lighthouse Account Policy link. Then select the Generated option from Password Provided by drop-menu.

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>

...

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

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

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

<s>Fast Create User</s>

</Expansion>

</Field>

</Form>

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

Create an Identity Manager account that will be used to load accounts into Identity Manager. Assign the user form created in Step 4 to this user.

Run the Create bulk action.

Previous Contents Index Next
Sun[TM] Identity Manager 8.0 Deployment Overview