After restoring a copy of an RSA Identity Governance and Lifecycle database using the avdbimport command and restarting RSA Identity Governance & Lifecycle, issues are noted in areas of the product where passwords are stored.
POP3 email is not working because the password is invalid.
Data collectors fail when attempting to bind to the data source because the passwords for the bind are incorrect.
Authentication sources no longer work.
The AFX server does not start because the AFX server Default Truststore Password is encrypted with the wrong key.
AFX connectors initially fail due to the AFX server failure but once the AFX server starts, the connectors fail when attempting to connect to the endpoints because the passwords to authenticate the connections are incorrect.
The aveksaServer.log file shows the following errors:
04/27/2017 16:06:56.448 ERROR (default task-109) [com.aveksa.server.utils.PasswordTypePropertyHandler]
Error in decryption method=ManagePasswordTypeProperties
java.lang.IllegalStateException: An issue with handling encryption was encountered
04/27/2017 16:03:10.192ERROR (ApprovalInboxProcessorServiceProvider)
[com.aveksa.server.email.mailboxmonitor.MailboxMonitorThread] Error Processing Email
javax.mail.MessagingException: Could not connect to message store for pop3s://firstname.lastname@example.org:995;
nested exception is:
javax.mail.AuthenticationFailedException: [AUTH] Authentication failed.
A backup of an RSA Identity Governance & Lifecycle database version 7.0.0 or later is restored using avdbimport without also importing the encryption keys.
Importing a backup of a database using avdbimport into a different instance of RSA Identity Governance and Lifecycle.
Importing a backup copy of the database using avdbimport into the same instance of RSA Identity Governance and Lifecycle where an uninstall and a re-install have been performed.
Importing metadata for data collectors and AFX connectors from a different instance of RSA Identity Governance and Lifecycle.
Starting with RSA Identity Governance & Lifecycle 7.0.0, all passwords that are stored in the database and used within the product are encrypted for security purposes using a Key Encryption Key (KEK). The KEK files are stored in the /home/oracle/security directory. The keys in the KEK files must match the exported data in order for RSA Identity Governance & Lifecycle to access any of the encrypted passwords. If a database import is done without restoring the corresponding encryption keys, then areas of the product that rely on saved passwords such as data collectors and AFX connectors will fail.
KEK keys are named arbitrarily using a hashing algorithm to avoid name collisions but are always a combination of three characters including uppercase and lowercase characters and numbers and the filename extension .key. An example KEK filename is F1M.key. KEK keys are searched exhaustively during decryption. As new keys are added, new unique KEK files will be created in the master key storage directory (default /home/oracle/security). When archiving or copying KEK files, be sure to maintain allfiles in the directory.
Recover all encryption key files from the master key storage directory, /home/oracle/security, as per the instructions in the RSA Identity Governance & Lifecycle Database Setup and Management Guide for your version.
If a copy of the Encryption Key file is not available, then it is possible to update the passwords in all aspects of the product where they may have been encrypted by accessing the configuration pages, entering the password again, and saving the changes. Places where passwords are used include, but are not limited to, connectors, collectors, AFX truststore passphrase and email configuration.
Ensure that a backup copy of all the Key Encryption Key (KEK) files from the master key storage directory (default /home/oracle/security) are maintained for restoration purposes.
Ensure that a copy of these files are retained before any uninstall and re-installation of the product.