TimothyHuang48636 (Customer) asked a question.
Im planning out an upgrade from 8.7 to 8.7 SP1 to 8.7 SP2. From the upgrade documentation and this article, I understand that there's a database corruption bug on 8.7 SP1, fixed in SP2 and in the SP1 hotfix: https://community.rsa.com/s/article/RSA-Authentication-Manager-8-7-SP1-Patch-1-Hotfix-1
I've spoken with some engineers with RSA SecurID support, and I'm confused as to whether or not users will be able to authenticate as usual when I am on 8.7 SP1 and upgrading to 8.7 SP2 (Im planning to perform the upgrades back-to-back).
In addition, can anyone help clear up what activities will perform a database write and read, so I know what to avoid during the upgrade to circumvent database corruption.
@TimothyHuang48636 (Customer) ,
If you have a primary and one or more replicas, then you will be upgrading only one server at a time so your end users will not be affected by the upgrade process. While you upgrade the primary, some administrative functions like running reports and assigning tokens will be offline. Any authentications handled by a replica are stored in sweep files that are then shared up to the primary when it is back online. The primary then pushes those deltas to the replicas so the database remains synched.
Always ensure that you upgrade the primary first then the replicas, as follows:
NB: Replication is known to go out of synchronization as you upgrade your servers, so check replication status in the Operations Console once you have upgraded all of the servers to the same version (after steps 2, 4, 6). If you see that replication is not working, please review steps to manually resynchronize the servers.
@EricaChalfin (RSA)
Thanks for the response. I understand the general procedure for upgrading the primary and replica, I was more trying to understand if the specific bug referenced in the RSA article affects user authentication rather than the upgrade process.
@TimothyHuang48636 (Customer) ,
Thank you for the clarification. The application of Authentication Manager 8.7 SP1 upgraded the underlying OS from SUSE 12 to SUSE 15. Because of the operating system upgrade. a database REINDEX was required on all servers in the deployment. The hotfix performed that step on the PostgreSQL database.
The script was included in subsequent software releases so a manual REINDEX is not required. Since you are only upgrading one server at a time, authentication is not affected.
@EricaChalfin (RSA)
That would be a big relief if thats the case.
In some of my past support cases with RSA, the engineer has asserted that authentication may or may not be affected on 8.7 SP1; and that RSA engineering had tested authentication on 8.7 SP1 and uncovered some authentication problems. Do you have any idea what they could be referring to?
The article says, "there may be corruption on the first write access to the database. Reading from the DB does not do any harm to the stored data, but the results may be unexpected or even wrong." That does not refer to authentication?
Is the script also in AM 8.7 SP2, that is can you go straight from 8.7 -> 8.7 SP1 -> 8.2? Also what constitutes a database write in this scenario? A user logging on would trigger a database write? Or would this only be an action like creating/deleting/modifying a user/group/token?
Edit: Answered myself running the 8.7 SP2 update in a lab, can clearly see that it does indeed run the fix script.
INFO: Performing preUpdate task InvokeGroovy (Reindex DB for AM-51872)
INFO: ** Begin reindex DB **
INFO: Executing reindexDB. Log output will be found here: /opt/rsa/am/install_logs/dbscripts/reindexDB.log
INFO: Executing /opt/rsa/am/pgsql/bin/psql
INFO: ** End reindex DB **