This chapter provides tips to consider when preparing to load account information into Waveset. It also includes sample scenarios that illustrate some issues that you might encounter.
Before you can begin loading user account information into Waveset, you determine which know the following questions applies to your environment:
Is there an authoritative resource for all user IDs?
If yes, then loading user accounts into Waveset should be straightforward. Use that resource as your first resource, then load accounts from other resources, using correlation rules to link the accounts together.
Can a complete list of users be obtained from resources that overlap, but for which there is a correlation key?
If yes, then the process of loading user accounts will be similar. Be sure that the user accounts are loaded from the overlapping resources into Waveset before loading accounts from other resources.
Can a list of users be obtained from overlapping resources that do not have a correlation key?
If yes, then determine how a unique set of users can be discovered from those resources most easily. You will probably need to manually correlate and delete users for each resource.
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 Waveset users to departmental administrators or end-users.
Ideally, the first resource you use to load accounts into Waveset has the following characteristics:
References a comprehensive set of users. The goal of an initial load is get as many accounts into Waveset 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 Waveset account ID. Each Waveset account ID must be unique. Ideally, your resource will have an attribute that is guaranteed to be unique and can be used as a Waveset 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 Waveset account will be generated.
Stores user attributes that can be used correlation keys. To link resource accounts in Waveset, 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 Waveset 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 Waveset. 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.
Waveset login names. If one resource creates a more desirable login name of Waveset, then this can be a deciding factor.
After you have chosen which resource will be used as the starting point for loading user data into Waveset, 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
The Load from File process seeds Waveset 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 Waveset. 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.
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 Waveset 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.
For example, the first three lines of a CSV file might look like this:
accountId,firstname,lastname,EmployeeID Josie.Smith,Josie,Smith,1436 AJ.Harris,Anthony,Harris,c310
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 Waveset, 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 Waveset 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 Waveset user. User forms are discussed briefly in Assigning User Forms.
.The Load from File process does not add entries into the Waveset account index. Therefore, you must perform a full reconciliation, or update the users, before your Waveset deployment is complete. In addition, the Load from File does not run any workflows when creating users in Waveset.
The Load from File process does not add entries into the Waveset account index. Therefore, you must perform a full reconciliation, or update the users, before your Waveset deployment is complete. In addition, the Load from File does not run any workflows when creating users in Waveset.
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 Waveset. 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.
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 Waveset 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.
.The Load from Resource process does not add entries into the Waveset account index. Therefore, you must perform a full reconciliation, or update the users, before your Waveset deployment is complete. In addition, the Load from File does not run any workflows when creating users in Waveset.
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 Waveset-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 Waveset 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.
command,user,waveset.resources,password.password,password.confirmPassword, accounts[MyAD].description,accounts[MySolaris].comment Create,John Doe,MyAD|MySolaris,changeit,changeit,John Doe,John Doe Create,Jane Smith,MyAD,changeit,changeit,Jane Smith |
The following example illustrates how the Create and Update bulk actions can be used in two separate files.
command,user,waveset.resources,password.password,password.confirmPassword, accounts[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, accounts[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 Waveset account index. Therefore, you must perform a full reconciliation before your Waveset deployment is complete.
. Creating accounts using bulk actions does not add entries into the Waveset account index. Therefore, you must perform a full reconciliation before your Waveset deployment is complete.
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.
Review the following sections before you begin the process of loading account information into Waveset:
Configuring an Adapter
Setting Account ID and Password Policies
Creating a Data Loading Account
Assigning Forms
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 Waveset.
For general information about configuring an adapter, see Understanding and Managing Identity Manager Resources in Sun Identity Manager 8.1 Business Administrator’s Guide. For detailed information about a specific adapter, refer to the Sun Identity Manager 8.1 Resources Reference or the online help.
When you load account data from a resource using Load from Resource, reconciliation, or Active Sync, Waveset 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 Waveset account passwords will not be the same as the those on the resource. By default, Waveset 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 Waveset account ID. See Assigning User Forms and Chapter 3, Identity Manager Views, in Sun Identity Manager Deployment Reference 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 Waveset accounts, and are categorized as:
Waveset account policies -- Use these to establish user, password, and authentication policy options. These 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 Waveset.
The following table lists the policies provided with Waveset as well as the default settings.
Table 4–2 Default Waveset Policies
See Chapter 3, User and Account Management, in Sun Identity Manager 8.1 Business Administrator’s Guide for more information about account and password policies.
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 Waveset administrator is assigned a user form that creates and edits Waveset 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 Creating Users and Working with User Accounts in Sun Identity Manager 8.1 Business Administrator’s Guide for more information about creating accounts.
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 Waveset 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 Waveset user. It includes:
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 Waveset 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.
The following fields are often in a user form that loads users.
The waveset.accountId and waveset.organization are values specific to Waveset. The EmployeeId attribute is a customized attribute. Its use is illustrated in Defining Custom Correlation Keys.
Waveset 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 Waveset Forms for more information about creating and editing forms.
Do not directly modify a form provided with Waveset. 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.
Waveset uses correlation and confirmation rules to link accounts. A correlation rule looks for Waveset 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 Waveset 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 Waveset 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 Waveset 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 Waveset.
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 Waveset.
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.
A rule cannot compare an account value on a resource with an Waveset 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
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 Waveset 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 Waveset attribute on the Account Attributes (schema map) page for the resource.
Save your changes. Waveset 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. Waveset returns to the System Settings debug page.
Restart your application server.
Waveset 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 Waveset. 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> <new class=’com.waveset.object.AttributeCondition’> <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 Waveset 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 Waveset by using the Identity Manager IDE, importing an XML file, or editing and renaming an existing rule using the debug page.
Waveset provides several mechanisms that can be used to assign accounts when correlation and confirmation rules do not find a match.
The Account Index records the last known state of each resource account known to Waveset. It is primarily maintained by reconciliation, but other Waveset functions will also update the Account Index, as needed.
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_”), Waveset displays a menu that presents you with the options of creating a new Waveset 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, Waveset 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.
The Waveset User Interface can be configured to allow Waveset users to discover their own resource accounts. This means that a user with an Waveset 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.
Access the Waveset 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>AD</String> <String>Solaris</String> </List>
Save your changes. Waveset returns to the System Settings debug page.
When self-discovery is enabled, the user is presented with a new menu item on the Waveset User Interface (Inform Waveset 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 Waveset identity.
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
A company wants to use Waveset 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 Waveset 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.
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 |
Use the following steps as a guideline for using reconciliation to load Active Directory accounts into Waveset.
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 Waveset 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.
(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 Waveset 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 Waveset users. Since this is the first resource, you probably want to assign the UNMATCHED situation to the value “Create new Waveset 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.
If you used the default Waveset account policy and default Active Directory identity template, Waveset will not create an Waveset 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.
Waveset 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 Waveset account name will be the same as Active Directory login name.
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 Waveset 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.
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.
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, 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.
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 Waveset 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.
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 |
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 EmployeeNumber |
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 |
Use the following steps as a guideline for using reconciliation to load PeopleSoft accounts using Active Sync into Waveset.
From the Resources page in the Waveset 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.
Configure the adapter. Make sure you do not delete the accountId or fullname Waveset 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.
Waveset 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 Waveset 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.
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 Waveset User Attribute side of the schema map, and employeeNumber to the Resource User Attribute side.
The PeopleSoft adapter uses the Waveset 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 Waveset User Attribute side of the schema map, and mail to the Resource User Attribute side. email is a predefined Waveset 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.
Waveset 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.
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:
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 Waveset user based on resource account” option, the Waveset user will have, by default, an account name based on the LDAP cn attribute.
Reconcile the LDAP resource.
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.
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 Waveset User attributes:
accountId
email (the correlation key)
The USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR correlation rule will link the Remedy accounts to the Waveset accounts.
From the Resources page in the Waveset 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 Waveset User attributes. Other attributes can also be added.
See the online help and the Resource Reference for more information about configuring the adapter.
Configure the reconciliation policy for the resource as follows.
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.
The following procedure illustrates how a few users can be quickly added to Waveset using Create actions. Any resources referenced in the CSV file must be defined within Waveset 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 Waveset 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 id=’1’ name=’Approve’> ... </Activity> <Activity id=’3’ name=’Notify’> ... </Activity> |
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:
<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.
Create an Waveset account that will be used to load accounts into Waveset. Assign the user form created in Expedited Bulk Add Scenario to this user.
Log in to Waveset using the account created in the previous step.
Run the Create bulk action.