000033903 - How to differentiate same system vs different system backup/restore on RSA Authentication Manager 8.x

Document created by RSA Customer Support Employee on Sep 7, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000033903
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: RSA Authentication Manager
RSA Version/Condition: 8.x
Platform: SuSE Linux
IssueWhen installing a new instance of Authentication Manager, the server will get a pair of universally unique identifiers:  the instanceGUID and deploymentUUID.
  • The deploymentUUID never changes and is unique for each server. If two servers have the same deploymentUUID, it means they were cloned. And thus, during the backup and restore process, it will be considered to be a backup/restore of the same system.  A possible result would be that the replica from the "backup system" will be attached to the restored system.  The significance of this is that all replica servers' information stored in the backup will be wiped out after restore since Authentication Manager does not support keeping replicas when doing a Different Box Restore.
  • The instanceGUID is overwritten when a backup is restored. 
  1. Login to SSH as rsaadmin:
    login as: rsaadmin
    Using keyboard-interactive authentication.
    Password: <enter OS user password>
    Last login: Tue Aug 30 05:38:15 2016 from jumphost.vcloud.local
    RSA Authentication Manager Installation Directory: /opt/rsa/am

  2. Navigate to /opt/rsa/am/utils and obtain the database password in order to access the database:
    rsaadmin@am81p:~> cd /opt/rsa/am/utils
    rsaadmin@am81p:/opt/rsa/am/utils> ./rsautil manage-secrets -a get com.rsa.db.dba.password
    Please enter OC Administrator username: <enter Operations Console admin user name>
    Please enter OC Administrator password: <enter Operations Console admin user password>
    com.rsa.db.dba.password: rSKD5bGguLGNL9uGvFWnJoxIcHJah2
    rsaadmin@am81p:/opt/rsa/am/utils> cd ../pgsql/bin
    rsaadmin@am81p:/opt/rsa/am/pgsql/bin> ./psql -h localhost -p 7050 -d db -U rsa_dba
    Password for user rsa_dba: <enter the com.rsa.db.dba.password captured above>
    psql.bin (9.2.4)
    SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
    Type "help" for help.

  3. Once in the PostgreSQL database, type SECT * FROM rsa_rep.ims_instance to get the instanceGUID, shown in the output below in the id column:
    db=# SELECT * FROM rsa_rep.ims_instance;
                    id                | cpu_count |           description            | is_primary | deployed_state
    1666addb1e02a8c008016d234bd2b1d7 |         1 | promoted to primary from replica | t          |
    1055445d1f02a8c00801c4db3d79d286 |         1 | demoted to replica from primary  | f          | active
    (2 rows)

  4. Type SELECT name, value FROM rsa_rep.ims_config_value WHERE name = 'ims.deployment.uuid to get the deploymentUUID, shown in the value column, as below:
    db=# SELECT name, value FROM rsa_rep.ims_config_value WHERE name = 'ims.deployment.uuid';
            name         |                value
    ims.deployment.uuid | 71f241d3-7637-4737-9e66-d1c8b7b0f304
    (1 row)

ResolutionIn order to have a correct backup and restore, make sure to have the correct deploymentUUID in place. If it is the same system backup/restore, the deploymentUUID should be the same. If it is two different systems, the deploymentUUID must be different.