- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What do you check to verify an update/upgrade did not break anything?
What are some of the things to check to make sure a patch or an update did not break any normal processes and functionality? There is a maturity level involved in standard patching that insures confidence when rolling out patches from test environment to production. Once a patch has been applied in test a standard procedure dictates validating all critical processes and functions are still running or available. The question is what specifically are those things that should be verified to validate a patch or an update?
- Tags:
- AM
- Auth Manager
- Authentication
- Authentication Manager
- Best Practice
- change_management
- Community Thread
- Discussion
- Forum Thread
- managing change
- patching
- replication
- RSA Authentication Manager
- RSA SecurID
- RSA SecurID Access
- SecurID
- sop
- Upgrade
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Authentication and replication are the two most critical things.
Add a new user, then list users on each replica, does the new user show up ?
Then use a test client like ntradping, and fire an authentication at each RSA server, does each
RSA server authenticate that user ? If you have users in ldap, use an ldap user for this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Authentication and replication are the two most critical things.
Add a new user, then list users on each replica, does the new user show up ?
Then use a test client like ntradping, and fire an authentication at each RSA server, does each
RSA server authenticate that user ? If you have users in ldap, use an ldap user for this.
