PAM allows configuration of scheduled database and configuration backups. In the past, PAM releases 2.X, these could be restored on a new PAM instance in a disaster recovery site as long as that instance was at the same patch and licensing level. But with PAM 3.0.1 and on this is not possible. The database loads, but cannot be used. Specifically all passwords will come up as empty when viewed, and target accounts cannot be used for auto-login to devices either.
In the newer releases there is an additional key that is not stored in the database but needed to decrypt passwords. This was added to prevent someone who gets hold of someone else's database backup file from restoring the backup on any PAM instance and getting access to all passwords.
The primary purpose of database and configuration backups is to be able to go back to a known good state if a PAM database gets corrupted due to internal or user errors. But it is still possible to prepare a disaster recovery (DR) site because the key external to the database is shared by all nodes of a cluster. The new recommended procedure for setting up a DR environment is as follows:
- Make a temporary configuration change of your cluster (or create a cluster configuration if you have a single PAM node) in production and add one node in the DR site where you may want/need to restore a DB backup at some later time.
- Start the cluster. This will copy the key to the DR node.
- Stop the cluster, remove the DR node from the cluster configuration and start the cluster. Production now is decoupled from the DR site again.
- On the DR node replace the cluster configuration from the production node with the correct configuration for the DR site.
- Now you can turn your DR node off.
- At a future time, when there is need for DR, bring up your DR instance and load the latest database backup from production. This will work because the DR node has the correct key.
The following PAM 3.2 documentation page was added to clarify this change: