Importance of your Master Password
Why is my Master Password so important?
During PAM installation, it is stressed that the master password generated and displayed be saved to a file and stored in a safe location. Here we will explain the importance of your Master Password.
Master Passwords are generated and displayed during installation.
Above, you will see a Windows installation on the left and Unix on the right.
Privileged Access Management encrypts sensitive data stored in its backend database using an AES-256 algorithm.
This algorithm is based on the master password that system uses to lock and unlock encrypted data.
Without the master password nothing can decrypt sensitive data in your system database which is a good thing because there is no backdoor to circumnavigate this algorithm.
However, in the unfortunate event when the master password is lost it would be helpful to have it available for restoration to make sure that encrypted data could be decrypted by the trusted password holder.
This is why it is important to save your master password in a safe place during system installation.
PAM secures your master password in its Directory Service component.
The Directory Service component could be hosted on a separate computer to increase overall system security by keeping encrypted data and the master password on different physical machines.
PAM generates a master password for each farm during installation of the Directory Service component of this farm.
It is vitally important to save the master password to a safe place after installing Directory Service.
Please note that encrypted export file does not include a master password for the security purposes.
The only way to access a lost master password is to save it during installation.
Unfortunately, if the password is lost then your data cannot be decrypted by anyone, so please do save it to a file and store it in a safe location.
It only takes a minute to do and can potentially save a lot of pain and heartache in the future.
When configuring PAM in a High Availability (HA) deployment then all system nodes must have the same Master Password.
Additional information about HA deployments can be found here.
If a node in this kind of configuration is using a different master password, then it will be unable to read secrets that were created in one of the other nodes and vice versa.
The usual indication of this type of misconfiguration between nodes is when you click the Unlock button, the secured value fails to load and you receive a decryption error in the log.
To resolve this issue with mismatched Master Passwords, you will need to set the Master Password of the new node to that of the current node.
That will ensure that all future records created in either node will be read by both. If you have existing records that were encrypted with the previous Master Password, then those will need to be re-encrypted with the new password.
To do this, navigate to Administration > Settings > Database and click the Change Master Password button.
In the dialog, supply the Current Master Password and the New Master Password to start the process.
This option will re-encrypt all records in the system encrypted with the provided old master password using the new provided master password. This option is useful when repairing the records created by the incorrect master password.
Note that the same master password should be used to view these records after re-encryption.
When it begins, the system will traverse the entire Indentity Vault and for every record, it will attempt to decrypt each using your Current Master Password.
For those that decrypt, it will then re-encrypt them with your new Master Password.
For records that fail to decrypt with the current, they will not be re-encrypted.
When the re-encryption process begins and completes, an Audit Event will be generated for each.
Category: Operation
Level: INFO
Event: Re-Encrypt Records
Message: Records re-encrypting started
Category: Operation
Level: INFO
Event: Re-Encrypt Records
Message: Records re-encrypting completed
When a record is re-encrypted, an Audit Event will be generated for each that was updated.
Object: {Name of Record}
Category: Data
Level: INFO
Event: Update
Message: Re-encrypt
If a record is not re-encrypted, then no Audit Event for that object will be generated.