Current Setup
- On-Premise RSA Authentication Manager 8.5 with latest patch (Primary and Replica) and RSA Identity Router (Nov 2020 release) integrated with RSA SecurID Access.
- Windows 10 clients with the RSA Authentication Agent 7.4.x, successfully authenticating to RSA Authentication Manager.
- Primary Authenticator: SecurID 700 (Physical Token)
Proposed Setup
Migrate Windows 10 clients to RSA MFA agent 2.0.2. Typical on-net desktops will be configured to authenticate to RSA Authentication Manager (AM) leveraging the REST API, pointing the desktop to the on-net [RSA AM Primary IP]:5555 and [RSA AM Replica IP]:5555 along with the API Key from AM. Laptops (road warriors) will be configured to authenticate to RSA SecurID Access, pointing the laptop the Cloud Authentication Service along with the API Key from SecurID Access.
For the most part, on-net Authentication using the MFA agent 2.0.2 appears to be working, however the behavior of offline authentication appears to be a bit confusing. When logging into a client with the RSA MFA agent 2.0.2, the user is required to provide their Active Directory username and password prior to being challenged for MFA. When the client is disconnected from the network, the user may be presented with an unsuccessful login when providing their Active Directory username and password. This behavior is different from the user experience when using the RSA Authentication Agent 7.4.x as if the Windows cached credentials are not leveraged. IN the event the user be able to successfully provide their Active Directory username and password while disconnected, they are challenged for RSA MFA. However, they are challenged to provide a tokencode from the RSA Authenticator App opposed to their SecurID passcode.
Is this normal behavior for offline authentication with the RSA MFA Agent 2.0.2 for Windows? We do not intend on leveraging the RSA Authenticator App as a primary authenticator.
