Replica Instance Administrative Tasks

With a few exceptions, you can view, but not update, administrative data on the replica instance. The primary instance is the only system in the deployment that allows you to perform all administrative tasks, but administrators can clear PINs and provide emergency access to users on any primary or replica instance.

You can perform the following administrative tasks on a primary or replica instance:

• Clear the current PIN for a user's token and set the token into New PIN mode. See Clear an RSA SecurID PIN and Clear an RSA SecurID PIN in the User Dashboard.
• Generate a temporary fixed tokencode when a user's RSA SecurID Token or RSA Authenticator app is temporarily unavailable and the user has network connectivity to AM. See Assign a Temporary Fixed Tokencode for Online Emergency Access.
• Generate a set of one-time tokencodes when a user's RSA SecurID Token or RSA Authenticator app is temporarily unavailable and the user has network connectivity to AM. See Assign a Set of One-Time Tokencodes for Online Emergency Access.
• Generate an offline emergency access tokencode when the user's Windows device cannot contact the Authentication Manager server through the network and the user's RSA SecurID Token is unavailable, or the user forgot his or her PIN. See Provide an Offline Emergency Access Tokencode.
• View runtime authentication log entries. When the primary instance or replication is not available, only entries for the replica instance are displayed. When replication is restored, all of the recent runtime authentication log entries are replicated, and become available for viewing on the primary or any replica instance. See View Messages in the Activity Monitor.

Administration When the Primary Instance is Temporarily Offline

Replica instance administration provides high availability and avoids downtime for administrative functions, when the primary instance is temporarily offline or replication is not available. For example, the primary instance might be offline for 15 minutes while a patch is applied or for a longer period during a major upgrade, but administrators can continue to assist users.

When the primary instance or replication is not available, there is no communication between the primary instance and the replica instances or between replica instances. You can use a replica instance to assist users, but the changes are only available to authentication agents using the respective server. For example, if you generate an emergency access tokencode on Replica-2, only agents connected to Replica-2 can authenticate using that emergency access token.

After replication is restored, the following occurs:

• The primary instance collects logs for the administrative tasks that were performed locally on the replica instances.
• All runtime authentication log entries are collected on the primary instance and replicated throughout the deployment.
• Changes that occurred before the primary instance went offline are replaced by later changes that occurred on a replica instance.
• If updates occurred on two replica instances, the most recent PIN changes and emergency access code changes are retained.

Note:  If the primary instance has an “Out-of-Sync” replication status, for any reason, resynchronizing the deployment removes any administrative changes that occurred on a replica instance. For example, you may need to regenerate an offline emergency access tokencode that was generated on a replica instance.

Examples of Administration When the Primary Instance is Temporarily Offline

Suppose that the primary instance went offline while being upgraded. The following scenarios are some examples of what could occur:

• A user's PIN is cleared on a replica instance, and a new PIN is created. When the primary instance is available again, replication occurs and the new PIN can be used on the primary instance or any replica instance.
• New PINs were separately created on more than one replica instance. When the primary instance is available again, the user can authenticate with the most recent PIN.
• An administrator uses a replica instance to generate a temporary fixed tokencode. The temporary fixed tokencode can be used for online authentication to resources protected by the replica instance. After replication is restored, the most recent temporary fixed tokencode can be used for authentication to any AM instance.
• Two administrators on two replica instances each generate a temporary fixed tokencode as a replacement for a user's lost token. When the primary instance is available again, replication and communication between replica instances becomes available. The temporary fixed tokencode that was created last can be used to authenticate to any AM instance in the deployment.
• An administrator uses a replica instance to generate a set of one-time tokencodes. These tokencodes can be used for online authentication to resources protected by the replica instance. After replication is restored, all active emergency access tokencodes are accepted throughout deployment. Any tokencodes that were used by a user or cleared by an administrator are no longer available for authentication.
• An administrator uses a replica instance to generate an offline emergency access tokencode. When the primary instance is available again, replication occurs and the offline emergency access tokencode can be used on the primary instance and any replica instance.
• Two administrators on two replica instances each generate an offline emergency access tokencode. When the primary instance is available again, if neither tokencode was used, the last offline emergency access tokencode that was generated is accepted on the primary instance or any replica instance.