Upgrade from 3.2.4 to 3.4

[Kanika Narang]

Hello Experts

We are planning to upgrade PAM from 3.2.4 to 3.4 version , while i have read the approach on TechDocs and wanted to go from 3.2.x>>3.3.2>>3.4 , while during a recent discussion the management asked why not we make a parallel 3.4 and restore the DB/Config from 3.2.4 version.

Can anyone suggest if this is possible and will it have any impact on the working of the PAM.

Thanks
Kanika

[Reatesh Sanghi]

Hello Kanika,

The plan is good, but unfortunately the DB from 3.2.4 can't be copied over to 3.4 installation. 

Starting with release 3.0.1, there has been a change which is shared below for you.

Restore the Database to a New Appliance

Last Updated November 2, 2019

Beginning in version 3.0.1, only the appliance that performed the database backup can restore the database and function properly. Another appliance can restore the database, but it cannot decrypt the password data, so any functionality involving that data fails. The backup requires the key encryption key from the original appliance for restoration. This requirement prevents a bad actor from getting access to a database backup so that the passwords can then be decrypted and compromised.

To create a duplicate appliance for disaster recovery or migration purposes, follow these steps: 

• Deploy a 

  Privileged Access Manager

   appliance. See Deploying for instructions. 
• Join the original appliance in a cluster with the new appliance, configuring the new appliance as a member of a secondary site. See Set Up a Cluster for details on how to configure clustering.

  You now have a "live" backup of the data from the original appliance because all cluster data is replicated to all nodes in the cluster. For disaster recovery, this new appliance should be in a different data center
• If you want a new, independent appliance, the new appliance can Leave Cluster after all of the data is synchronized between the two appliances. See Cluster Synchronization, Promotion, and Recovery for details. The new appliance and the original appliance can then move forward in separate, distinct, environments. 

------------

Hope this answers your query.

Thanks,
Reatesh.

------------------------------
Principal Support Engineer
Broadcom
------------------------------

[Pankaj Kumar]

Hi @Reatesh Sanghi​,

As you mentioned "Another appliance can restore the database, but it cannot decrypt the password data, so any functionality involving that data fails. The backup requires the key encryption key from the original appliance for restoration." How will the backup appliance decrypt the password data ? How we will get the encryption key in case of Disaster recovery ?

[Joseph Fry]

The key encryption key is replicated to all nodes in a cluster.  Therefore, one option for disaster recovery is to join a spare node to the cluster, then remove it... that node can then be used to restore a database backup in the future in the event of a disaster (just be sure to update that node to the same version first).

I know there have been conversations about how to address this but I am not aware of any plans in the roadmap.  In the mean time I encourage you to support (with a thumbs up) the Ideation I just submitted: https://community.broadcom.com/participate/ideation-home/viewidea?IdeationKey=6d0b9792-0eab-4847-b3a2-b4f16c5d4786

My vision is to make the key something that is supplied/generated by the PAM admin during deployment of the first node in their cluster (and optionally can be updated by a global admin).  This ensures that only one person has knowledge of this key, and they can secure it in such a way that it could be used in a disaster recovery scenario.