RSA Cloud Access Service (CAS)

RSA Authentication Manager (AM) v8.7 SP1 and later

RSA Authenticator for iOS & Android v4.4 and later

RSA Authenticator for MacOS v5.1 and later

RSA Authenticator for Windows v6.2 and later

A "push" authentication with the RSA Authentication app, is either an Approve or Biometrics authentication.  Authentication is either through the RSA Cloud Access Service (CAS) directly, or via RSA Authentication Manager (AM) to CAS. A push authentication might also require the user to select or enter a code that matches what the application has displayed (this is called code matching).   See:

• section "Push Notifications" on page Authentication Methods for Cloud Access Service Users .
• How RSA Cloud Access Service Push Authentications Work (Approve and Device Biometrics)

Common issues that may occur include:

• Push notification not received when expected
• Multiple push notifications received for one authentication
• Authentication fails after tapping Approve for a push authentication.
• Approve prompt not received after tapping the push notification

Network

The most common cause for push authentication failures are network issues, either between the application and CAS, or between the end user's device and either CAS or the device vendor's push notification service or both.   See How RSA Cloud Access Service Push Authentications Work (Approve and Device Biometrics) to view all the network connections and components used for a push notification.

If the application is connecting to RSA Authentication Manager(AM) but the connection from AM to CAS is down, push authentications will not be available even if High Availability Tokencodes is configured.

Timeout

Another common issue is timeout:  either the application times out before it receives the authentication response from CAS, or CAS times out if the user does not tap Approve quickly enough.  CAS has a maximum 1 minute limit that it will wait for a user to tap Approve, but an application may be configured to timeout sooner than that.  This may be an application configuration or user issue.

Retries

Multiple push notifications for an authentication occur when the application times out and then automatically sends retries to CAS as new authentications.  This is an application design or configuration issue.

Basic Troubleshooting

Advanced Troubleshooting with RSA Support

Basic Troubleshooting

Checks that should be done include:

• If push notifications are not received, does the user have push notifications enabled for the RSA Authenticator app?   Instructions to check are at these links:
  • Windows: Notifications and Do Not Disturb in Windows
  • MacOS:  Notifications settings on Mac
  • iOS: Change notification settings on iPhone
  • iPadOS:  Change notification settings on iPad
  • Android: Control notifications on Android

Note: enabling push notifications is not mandatory.  If push notifications are disabled or just not received, the user can open the RSA Authenticator app themselves, or bring it to the foreground, when they expect to receive an Approve or Biometrics prompt.

• Check network connectivity:
  • Can the application connect to CAS or AM (as applicable)?
  • If using AM, can AM connect to CAS?
  • Does the device running the RSA Authenticator app have good network connectivity?
  • Try connecting the RSA Authenticator app to a different network, e.g. if connected to wifi, switch to a mobile/cellular network or vice versa.
• Check application timeout and retries configuration.   For an authentication where push may be a step-up method, the application should set its timeout to 45-60 seconds, to allow plenty of time for the user to access their device, sign in and tap Approve.  Automatic retries should be avoided as they can lead to long delays for the user, e.g. 2 retries with a 60 second timeout can leave the login screen hanging for 3 minutes before a failure message is displayed to the user.
  • For RADIUS authentications, retries, if used, must be sent with the same RADIUS Identifier as the original request, else the user will receive multiple push notifications on their device.  Using the same Identifier for a retry is a requirement of the RADIUS standard (see section "4.1.  Access-Request" in RFC 2865 Remote Authentication Dial In User Service (RADIUS)).  Check with your application vendor if in doubt about how it is doing retries.
• If the application is using CAS (Identity Router) RADIUS, is Automatically prompt for push notification methods configured as needed in the RADIUS client of the Cloud Admin Console?
• Check the User Event Monitor in CAS for events for the user around the time of a failed authentication. If no event is shown, do not filter by user in case the user id was not recognized. If still no events are shown, then either CAS did not receive the request or the application was not recognized by CAS.
• If the application connects to AM, use the Authentication Activity Monitor or run an Authentication Activity Report.   Run the report for all users so that the events for the user are shown even if their user id was not recognized by AM.  If no events for the authentication are shown, then either the request was not received by AM or the application was not recognized by AM.

Advanced Troubleshooting with RSA Support

If RSA Support assistance is needed, please follow the below steps to gather the data that Support will need to troubleshoot:

1. An affected user should enable Enhanced Log Collection in the RSA Authenticator app.  See How to capture enhanced RSA Authenticator app logs for troubleshooting purposes  .
2. Have the affected user perform an authentication that reproduces the issue.  Tell us:
   1.  The date, time (with timezone) and user name for the attempt. 
   2. Describe:  What happened in the Authenticator app?  What happened in the application? 
   3. Take screenshots or video if necessary to show the problem. 
3. Tell us how the application is integrated with RSA, e.g. is it RADIUS to AM or CAS, an MFA Agent, a SecurID Agent, a Relying Party or My Page SSO Portal app or something else?
4. If using CAS (IDR) RADIUS, send us a screenshot of the Automatically prompt for push notification methods section in the RADIUS client in the Cloud Admin Console.
5. In the CAS User Event Monitor, select Include Verbose Logs, then take screenshots or "print to PDF" of all events for the user around the time of the authentication at step 2.  If there are no events for the user, do not filter by user.   Send the screenshots or PDF to Support, or if no events are displayed at all, tell us.
6. If the application connects to AM, generate an Authentication Activity Report.   Run the report covering the time of the authentication at step 2, for all users so that the events for the user are shown even if the user id was not recognized by AM.  Send the report to Support.
7.  Ask the affected user who tested at step 2 to follow the remaining steps in How to capture enhanced RSA Authenticator app logs for troubleshooting purposes to save the RSA Authenticator app logs and turn off Enhanced Log Collection. Send the Authenticator app logs to Support.

While push authentications are not working, use Authenticate OTP instead. You may need to add Authenticate OTP to the Assurance Level  used by the Access Policy for the application (if not already there) .