This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject
Register Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Announcements

SecurID® Community Blog

Subscribe to the official SecurID Community blog for information about new product features, industry insights, best practices and more.

(some) Best Practices for RSA Authentication Manager

JayGuillette
Apprised Contributor Apprised Contributor
Apprised Contributor
4 5 3,366
‎2019-10-11 05:58 PM

This blog started as a knowledge base, KB article, but it was quickly decided by the KCS content review team that any put in this KB would be added to, and possibly changed.  It is our hope that all growth here will be useful.

 

While RSA does not have a Best Practices Guide for Authentication Manager, we do have planning, performance and configuration guides.  See    RSA Authentication Manager 8.4 Performance & Scalability Guides   See Also

RSA Authentication Manager Previous Versions page for versions earlier than 8.4.

 

Principles

  1. Probably the single best piece of advice I ever got in the technical business world is that "you tend to get more credit for a small success than a big failure."  So good principles are to watch scope creep, keep jobs manageable and then use manageable subprocesses as building blocks for larger processes or jobs.
  2. Try to stay up to date with versions and patches.  Not only are new features are included in newer versions, but bug and vulnerability fixes are always targeted for the latest releases.  Be aware that your support contract mandates staying current with versions, and that asking RSA apply new fixes to older versions results in exponentially more complex Quality Engineering test scenarios, especially in the area of upgrades or updates.  Applying a hot fix to an older version of AM means QE has to go back and test previous version updates.
  3. Authentication is the act of verifying the authenticity of someone or something; in other words, to make sure someone is who they claim to be.  Authentication is the foundation of all access control, and all access controls are only as sound as the authentication system under girding them.  Authentication Manager two factor authentication (2FA) is the integration of something you have (the tokencode) and something you know (the PIN) into the passcode.
  4. If your tokens do not require PINs (that is, PINless tokens), then you do not have 2FA configured. and have an inherently less secure authentication mechanism.
  5. If you mate PINless tokens with passwords, you have a multi-factor authentication (MFA), which may or may not be a strong as 2FA, depending on the degree of integration and the protection of token seeds.  What I'm saying is there is a debate, which we will not resolve here, and all I can say is this debate revolves around the concept that one eight-foot high fence is considered more secure than two four-foot high fences.  Your risk analysis needs to determine if your MFA is sufficient to mitigate your risk concerns in according to your business principles.


Technical Principles

  1. You cannot extend the size of the RSA Authentication Manager appliance disk drive on a virtual machine after it has been deployed.  To resolve this, you will need to deploy a new instance, probably a replica that you will promote.
  2. Authentication Manager is an authentication system first, and only secondarily a reporting system; therefore you need to understand several database concepts, such as managing log archival maintenance, which lets you understand how long authentication and administration data is maintained in the database for your authentication and administration reports.
  3. Log archival management is closely related to database management.  As authentication and administrative activity is logged into or added to the database, the database grows in size. As this information grows older there is a point where is should be archived out and purged from the database, so that the database does not grow infinitely.  However, most databases do not automatically compress the space allocated to this information as it is archived, so the database does not instantaneously shrink, instead the database marks this space as writeable so newer logged data can use this space, so that the rate of growth of the database is slowed.  If you want or need to compress the the Authentication Manager internal database, you need to run the postgres vacuumdb utility.  For information on how to run this utility, please contact customer support and open a case.  Cite article 000035033.
  4. If your Authentication Manager primary runs on VMware you may have deployed this server with the default disk size of 100GB.  If you also have thousands of users, there may be circumstances where due to logging and archiving your disk could be at risk for filling up.  Therefore, it is wise to configure a Critical System Event Notification in the Security Console (Setup > System Setup), and enable an email for Low disk space events.  Optionally modify the warning threshold from the default setting of 5GB to something larger to give you an earlier warning.  See 000036191 - How to modify the low disk space critical event email warning threshold from 5 GB to 10 GB free in RSA Authentication Manager 8.2.1 and higher for more information.

Recommended KBs


Server consoles


Agent and Authentication Knowledge


Linux and certificate knowledge


Authentication Manager Integration Service (AMIS) articles


Hardware appliance knowledge

5 Comments
© 2023 RSA Security LLC or its affiliates. All rights reserved.