You can export and import token records and user records between two Authentication Manager deployments. You might do this when merging two deployments or to move tokens from one deployment to another. You can export and import tokens, or you can export and import users with tokens. You export from the source deployment and import to the target deployment.You can move tokens that are assigned or unassigned, and reassign the tokens to different users on the target deployment. Authentication Manager encrypts the export file to ensure that the process is secure.
Moving users to a new deployment does not interrupt authentication because the exported data from the source deployment is not deleted. Users can still authenticate to the source deployment even after you have imported their records to the target deployment. You must manually delete the users from the source deployment.
If the source and target deployments both store user records in external identity sources (an LDAP directory server), Authentication Manager creates reference records in the target deployment that point to each user’s record in the LDAP directory sever. The users being moved must have the same User IDs in the source and target deployments.
The following apply:
If the user record already exists and a user is already assigned one or more tokens in the source deployment, Authentication Manager does not import the user and token(s). Instead, Authentication Manager logs an exception message.
If the user record already exists and the user has no assigned tokens in the target deployment, Authentication Manager updates the user record on the target deployment and imports the tokens. Authentication Manager writes a warning message to the system logs.
If the user records are stored in the internal database in both the source and target deployments, Authentication Manager adds new records to the internal database in the target deployment only if the records do not already exist. If the user record already exists in the target deployment, the record is not duplicated and the user and all linked tokens are ignored.
When the source deployment uses an internal identity source and the target deployment uses an external identity source, the following apply:
If the user record already exists and a user is already assigned one or more tokens, Authentication Manager does not import the user and token(s). Instead, Authentication Manager logs an exception message.
If the user record already exists and the user has no assigned tokens in the target deployment, Authentication Manager updates the user record on the target deployment and imports the tokens. Authentication Manager writes warning message to the system logs.
When the source deployment uses an external identity source, users’ LDAP passwords are not exported. The user records are imported to the internal database without a password and password authentication is disabled. If the users need password authentication, you must reset the passwords, or the user must use the Self-Service Console to create a password.
For more information, see Enable Users to Reset Passwords After User and Token Export.If the user record already exists in the target deployment, the record is not duplicated and the user and all linked tokens are ignored.
The export and import operations affect user records in the following ways.
If the exported users are enabled for risk-based authentication (RBA) on the source deployment but the target deployment does not have an RBA license, the users are disabled for RBA after the import. If the target deployment has an RBA license, the user is imported with the same status as on the source deployment, either enabled or disabled for RBA.
If exported users have a RADIUS profile or a user alias on the source deployment, the users are disabled for RADIUS profiles and aliases on the target deployment. Users will not be able to authenticate using RADIUS.For more information, see RADIUS Profiles and Assign a User Alias to a RADIUS Profile.
If the source and target deployments have different PIN policies, each user may need to change his or her PIN when logging on to the target deployment for the first time to conform to the different PIN standards.
Users’ security questions and answers are exported if the following conditions are met on the target deployment:
The language is the same on both deployments. If the language does not match, the user is imported without the security question answers. RSA recommends that the source and the target deployments use the same language.
The same security questions must exist on both deployments. If the questions are not the same,the user is imported without the security question answers.
If the number of questions the user must answer on the target deployment is less than or equal to therequired number on the source deployment, the users and answers are imported. If the target deployment requires users to answer more questions than the source deployment requires, the users are imported without the answers. Users will have to reconfigure security questions and answers when they log on to the target deployment for the first time.For more information, see Managing Security Questions.
If a user in external identity source is already registered on the target deployment, the user and theuser’s answers are not imported.
You can export on-demand authentication(ODA) user data from your Authentication Manager deployment. You specify whether or not to export ODA data on the Export Tokens and Users page of the Security Console. If you export ODA data from your deployment, users configured for ODA authentication will be able to continue using ODA features when you import the data to another deployment.
The user attribute configured for default ODA delivery (for example, email or mobile) is transferred between deployments according to fixed, direct attribute mapping. For example, if the source deployment has multiple email attributes such as email and email2, and email is set as the default ODA delivery method, the values for the email attribute will be exported. When importing the data, the values will be imported to the email attribute in the destination deployment. Values for email2 will not be exported or imported.
Note:To avoid ODA problems for imported users, ensure that the user attribute setting for default ODA delivery method is the same in the source and destination deployments.
Software token profiles are not imported. The association between the profile and the token is imported if thesame profiles exist on the source and target deployments. Authentication Manager handles the import of software token profiles as follows:
If the names of the software token profiles on the source and target deployments match, the tokens are imported with the software token profile association preserved.
If the names of the software token profiles on the source and the target deployments do not match, the tokens are imported, but the software token profileis not associated with the tokens. The software token profile does not affect authentication, but it does affect token distribution. By default, if these tokens are either lost or damaged or need replacement, they cannot be replaced through the Self-Service Console. RSA recommends that users request a new token when these tokens need to be replaced. As an alternative, the administrator can redistribute them from the Security Console using a new profile, so replacements can be requested. However, this would affect authentication for the redistributed token.For more information, see Software Token Profiles.
If the software token profile on the source deployment contains new Device Types that cannot be found on the target deployment, the new Device Type is removed from the token when it is imported.
If an assigned token is imported with no associated user, the software token profile association is removed and the Device Type is reset to the default device definition type.