CA Identity Manager Connector Guides › Connectors Guide › Connecting to Endpoints › RSA Authentication Manager SecurID 7 Connector › Connector Specific Features

Connector Specific Features

This section details your connector's specific management features, such as how to acquire and explore your endpoint. Also included are account, account template, and group information specifically for your connector.

Note: For a general overview of the Provisioning Manager and its main features, see Managing the Connectors. For more detailed information about the Provisioning Manager, see the Provisioning Guide.

RSA 6.x Connector Data Migration

You can use the RSA SecurID 7.1 migration utility, RSA7Migrate, to migrate existing RSA 6.1 account templates to the new RSA 7.1 connector data. The migration utility creates new RSA 7.1 account templates; RSA 6 templates are preserved during the migration process.

The migration utility does not migrate RSA 6.1 endpoint data because such migration requires retrieval of all accounts from an RSA 6.1 endpoint. Instead, reexplore the RSA 7.1 endpoint that contains the RSA 6.1 migrated data. Or, to be precise, perform subtree exploration only on an RSA 7.1 security domain where you migrated the RSA 6.1 data.

RSA only supports data migration from RSA Authentication Manager 6.1. As a result, the RSA7Migrate utility only supports the migration of RSA 6.1 endpoint data. The utility cannot differentiate between acquired RSA 5.x, 6.0 and 6.1 endpoints.

Important! Verify that all relevant RSA data has been successfully migrated before running the RSA7Migrate utility,

RSA7Migrate Command

Valid on Windows and Solaris

Use the RSA7Migrate command to migrate existing RSA 6.1 account templates to the new RSA 7.1 connector data, or migrates tokens from RSA 6.1 endpoints to RSA 7.1 endpoints.

This command has the following format:

(Windows and UNIX) RSA7Migrate [-tokens]

-tokens

(Optional) Migrates tokens from RSA 6.1 endpoints to RSA 7.1 endpoints and populates the CA Identity Manager Provisioning Directory with RSA 7.1 tokens.

RSA7Migrate Processing Modes

When you run the RSA7Migrate utility to migrate account templates, you are prompted to run the utility in one of the following modes:

• Mode 0 – Do nothing, that is report only

  We recommend that you first run the utility in this mode, to identify any errors.

• Mode 1 – Create a template only if there are no errors

  If no errors are found after running the utility in mode 0, run the utility in mode 1.

• Mode 2 – Create a template even if errors found, but do not associate it with a namespace.
• Mode 3 – Create a template and associate it with a namespace even if errors found.

  Use this mode to identify and solve problems after you run the migration utility.

• Mode 4 (interactive mode) – Modify a template to make it compatible with a namespace. In interactive mode, you are prompted to specify an existing trusted realm.

  Use this mode to resolve problems with templates. For example, if the utility does not find RSA objects automatically, use this mode to specify the names and locations of the missing RSA7.1 endpoint objects.

Migration Utility Prerequisites

Before you run the RSA7Migrate utility, do the following:

• Perform a migration of the RSA 6.1 endpoint data to RSA 7.1 endpoint data
• Acquire and explore RSA 7 namespaces that contains the migrated RSA data

You are required to supply the following information during the migration process:

• CA Identity Manager Provisioning Server connection details:
  • Host name
  • Port
  • TLS status
  • TLS port (if TLS status is enable)
  • User name
  • Password
  • RSA 6 namespace name
  • RSA 7 namespace name, that corresponds to the above RSA 6 namespace
  • Security domain where the migrated RSA 6.1 data is located. This domain is always specified during the data migration process on the RSA side.
  • Suffix you want to add to the RSA 6 template name to create the RSA 7 template name.

What the Migration Utility Does

The migration utility does the following:

• Searches for all RSA 6 account templates which are associated with the specified RSA 6 namespace. You are asked to specify a search pattern. If the search operation does not return anything, the migration utility prompts you to specify a new search pattern.
• For each account template returned by search operation, the migration utility does the following:
  • Returns all template attributes
  • Verifies that the RSA7 template with the name you specified exists
    • If the name exists, the utility prompts you for a different name
    • If you use an existing RSA7 template, the utility skips template generation and proceeds to verification and association with the specified RSA7 namespace.
• Generates a new RSA 7 template

  If a template is a local template (that is, the realm name is not specified in the RSA 6 template) the utility represents each group listed in the RSA 6 template as a local group in the RSA 7 template. For example, the group Rsa6_group is represented as the following in the RSA 7 template:
  eTDYNGroupName= rsa6_group,eTDYNContainerName=Security_Domain,…

  For example, the group Rsa6_group@site is represented as the following in the RSA 7 template:
  eTDYNGroupName= rsa6_group,eTDYNContainerName=site, eTDYNContainerName=Security_Domain,…

  Each agent host listed in RSA 6 template is represented in the RSA 7 template as a local group. For example, the agent host Agent_host.ca.com is represented in the RSA 7 template as:
  eTDYNGroupName= Agent_host,eTDYNContainerName=Security_Domain,…

  If a template is a remote template, that is, the realm name is present in the RSA 6 template, trusted group DNs are generated instead of local ones as previously shown, and the account name is represented as account % realm.

• Verifies that specified security domain exists in the RSA 7 namespace.

  If a domain cannot be found in interactive mode, the utility prompts you to provide a proper name.

• Verifies that the specified realm exists in the RSA 7 namespace, if a template is a remote template.

  In interactive mode, you are prompted to choose an existing trusted realm.

• Verifies that all RSA 7 groups (that is, groups corresponding to RSA 6 groups, and groups corresponding to RSA 6 agent hosts) exist in the RSA 7 namespace.

  If a group cannot be found in interactive mode, you are prompted to specify a proper group name. Use the following format for DNs composite names:

  Realm/SD_Level_1/SD_Level_2/…

• Creates an RSA7 template and associates it with the RSA 7 namespace.

Account Template Migration Limitations

Account template migration limits are mostly related to RSA6 templates associated with more than one namespace. Observe the following limitations during account template migration.

All namespaces associated with the same template must:

• Have the same security domain DN
• Contain the same Group DN(s) for all the groups associated with a template
• Have the same Identity Source DN for accounts to be stored
• Expose the same realm in case of remote templates

If any of the objects described previously have different names (or DNs) in different namespaces, such namespaces must have a separate set of templates. If necessary, run the migration utility several times to create the templates correctly.

Migrate RSA 6.1 Account Templates to RSA 7.1 Connector Data

To migrate RSA 6.1 account templates to the RSA 7.1 connector data, run the RSA7Migrate utility.

To migrate RSA 6.1 account templates to the RSA 7.1 connector data

1. Verify that the Provisioning Server is running.

   Note: The Provisioning server must be running when you migrate templates.

2. Open a command prompt window and navigate to the \bin directory where you installed the Connector Server.
3. Enter the following command:

   RSA7Migrate
   

   The RSA7Migrate utility starts and prompts you for the Provisioning Server connection details.

4. Enter the information requested.

   The RSA7Migrate utility creates an RSA7 template and associates it with the RSA 7.1 namespace.

What the Token Migration Utility Does

The token migration utility does the following:

• Prompts you for the:
  • CA Identity Manager Provisioning Directory connection details
  • RSA 6 namespace name where the templates you want to migrate are located
  • RSA 7 namespace name, corresponding to the above RSA 6 namespace
  • Security domain where the migrated RSA 6.1 data is located. This domain is always specified during data migration process on the RSA side.
• Connects to the CA Identity Manager Provisioning Directory
• Prompts you to provide a search pattern for token serial numbers
• Reads all tokens which satisfy the search pattern, from the RSA 6 explored data in the CA Identity Manager Provisioning Directory
• Writes the RSA 7 token object into the provided security domain in the RSA 7 explored data for each token.

Token Migration Prerequisites

Before you run the RSA7Migrate token migration utility, do the following:

• Migrate the RSA 6.1 endpoint data to RSA 7.1
• Acquire and explore the RSA 7.1 namespaces that contains the migrated RSA 6.1 data.

You are required to supply the following information during the migration process:

• CA Identity Manager Provisioning Directory connection details:
  • Host name
  • Port
  • TLS status
  • TLS port (if TLS status is enabled)
  • Password
• RSA 6 name
• RSA 7.1 endpoint name, corresponding to the above RSA 6 namespace
• RSA 7. 1 security domain where the migrated RSA 6.1 data is located. This domain is always specified during data migration process on the RSA side.

Migrate Tokens

To migrate tokens to populate the CA Identity Manager Provisioning Directory with RSA 7.1 tokens, run the RSA7Migrate utility with the -token command-line parameter.

To migrate tokens

1. Stop the CA Identity Manager Provisioning Server.
2. Open a command prompt window and navigate to one of the following directories where you installed the Connector Server.
   • (Windows) C:\Program Files\CA\Identity Manager\Connector Server\resources\rsa7\
   • (Solaris) /opt/CA/IdentityManager/ConnectorServer/resources/rsa7/
3. Enter the following command:

   RSA7Migrate -tokens
   

   The RSA7Migrate utility starts and prompts you for the Provisioning Server connection details.

4. Enter the information requested.

   The migration utility writes the RSA 7 token object into the provided security domain in the RSA 7 explored data for each token.

5. Start the CA Identity Manager Provisioning Server.

Local and Remote User Support

The RSA SecurID 7.1 Connector supports both remote users and local users, through the one account object class. Remote users are users that exist in other realms but to whom you want to grant certain rights within the current realm. Local users and remote users (also known as trusted users) can have the same login names within one security domain.

The different account types are distinguished by appending a suffix to the associated RSA user ID and using the percent sign as delimiter. For example, " % ".

Note: There is a space before and after the delimiter.

Remote users have special LDAP names with the following format:

Remote_username< delimiter >Realm_name

An example of a remote user name is UserName01% CA

Using a delimiter to distinguish local and remote users has implications on global user correlation and the use of account templates. During correlation, the delimiter becomes part of the global user name. However global users with the delimiter as part of their name cannot be used to create endpoint users using account templates as the delimiter is treated as a special character.

To allow for some alternatives for correlation, you can use the following hidden attributes:

• LoginID

  The Login Id attribute is always set to the login name of the user regardless of whether the user is a remote or local user. That is, it does not contain the delimiter and realm suffix for remote users.

  Correlating against this attribute means that all global users created can be used with account templates but any users with the same login name as the same user are also correlated. For example, the local user janesmith is correlated to the same global user as janesmith % sales and janesmith % dev1.

• LocalUserLoginID

  This attribute is set to the login name of the user only for local users, but is not set for remote users.

  Correlating against this attribute creates global users for all local RSA users while correlating all remote RSA users to the default user.

More information:

Create a Trusted User

Windows Password Integration

If Windows password integration enabled in RSA, the RSA server caches the Windows password of each user in the security domain. When a user logs in, they are only required to enter their RSA passcode.

When you select the Clear cached copy of Windows credentials check box on the General 1 Tab (User Account Dialog) or General 1 Tab (Account Template Dialog), the connector removes the user's Windows credentials from the cache. The next time the user logs in, the user is prompted for their Windows password in addition to their RSA passcode.

The check box does not show the status of the cache, or whether the check box has been set on a prior transaction.

Date and Time Considerations

All dates and times that the RSA SecurID 7.1 Connector receives should be in UTC. All dates and time values that specify time zone information other that +00:00, -00:00 or Z, are invalid and any date or time values received without time zone information are treated as UTC.

In Account screens, values are in Provisioning Manager local time. The Provisioning Manager converts these values to UTC then passes them to endpoint. The endpoint then converts the values to the time zone it is in. For example, if the Provisioning Manager is in Perth (UTC + 8) and the endpoint is in Melbourne (UTC + 10), to set an endpoint-based time of Sept 1, 2009 10 am, set the value in the Provisioning Manager to September 1, 2009 8 am. (Provisioning Manager local time).

In Account template screens, although you can enter any value, the valid values are:

• %XD%

  Specifies the date and time of account creation. The Provisioning Manager sets this value to the date and time of account creation converted to UTC, in the format yyyy-mm-ddTHH:MM:SSZ. The endpoint converts the value to the time zone it is in.

• Specific date

  Use the same format as the rule string %XD%, with or without the Z. This string is passed as is (no conversion) to the Provisioning Server, and eventually to the endpoint. The endpoint then converts this value to its local time. Therefore, enter the value to whatever endpoint time you want the endpoint time it to be, converted to UTC, that is, use the equivalent UTC. As in the previous example of the endpoint in Melbourne and the Provisioning Manager in Perth, if you want to set the value to be September 1, 2009 10am Melbourne time, enter 2009-09-01T00:00:00.

• Daylight savings time

  As in the previous example of the endpoint in Melbourne and the Provisioning Manager in Perth, if you want to set the value to Dec 25, 2009 10am Melbourne time, the set the value in the Provisioning Manager to 2009-12-24T23:00:00.

• %UCUnn%

  This value works the same way as with the specific date case. That is, enter the UTC equivalent value.

Group Access Times

The RSA7.1 endpoint stores group access times as UTC but displays them using the RSA7 Server local time. To make it easier for group administrators to set the access times relevant to other time zones, the RSA Security Console provides the ability to select a time zone and displays the group access times relevant to the select time zone. However, the selected time zone is not stored. Each time the page is displayed the time zone control defaults to the RSA server local time.

Due to limitations in the RSA API, the RSA SecurID 7.1 Connector cannot return the RSA server local time. To resolve this limitation, a time zone attribute has been added to the RSA7.1 endpoint dialog, General 1 tab. You can use this attribute to specify the time zone to use for group access times. This attribute defaults to UTC. All times displayed or entered for group access are assumed to be for this time zone.

This solution is also applicable to time zones specified for trusted user groups.

Multi-value Assignment Dialogs

The multi-value assignment dialogs let you search for a specific object in a selected system domain, then assign those values to a specific object. For example, you can search all administrative roles in a specific system domain, then assign the administrative roles to a user account.

The multi-assignment dialog contains the following fields:

Available List Search

Displays the containers in the namespace you can search.

Class

Specifies the object class you want to search.

Classes that use the attribute displayed in the Attribute list are displayed in the list.

Attribute

Specifies the attribute you want to search for.

Value

Specifies the value you want to restrict the search to.

Default: Wildcard character (*). The wildcard causes the search to return all entries.

Note: If you perform an advanced search for an attribute, this field is not available.

Search one level only

Restricts the search to only the level selected in the Available List Search.

Advanced

Displays the Advanced Search Attributes dialog. Use this dialog to set more advanced search criteria.

Note: Specifying advanced search criteria is useful if you want to narrow the list of objects in the class.

Assign Multivalues to an Object

To assign multiple values to an RSA object, search for the object you want to assign then select the values you want assign to the RSA object.

To assign multivalues to an object

1. On the multivalue assignment dialog, select a class from the class list.

   Selecting a class list specifies the object class you want to search. Classes that use the attribute displayed in the Attribute list appear in the list.

2. In the Attribute list, select an attribute.

   Selecting an attribute specifies the attribute you want to search for.

3. Type a value in the Value field.

   The value that you want to restrict the search is specified.

   Note: The default is the wildcard character (*). The wildcard causes the search to return all entries.

   Note: If you perform an advanced search for an attribute, this field is not available.

4. Select the Search one level only check box.

   Selecting the check box restricts the search to only the level selected in the Available List Search tree.

5. Click Advanced.

   The Advanced Search Attributes dialog appears.

6. If necessary, specify more advanced search criteria.

   Note: Specifying advanced search criteria is useful if you want to narrow the list of objects in the class.

7. Click Search.

   The objects you can assign appear in the Available list.

8. Select the objects you want to assign, then move the objects to the Assigned list, then click OK.

   You have assigned the objects to the RSA object you are working with.