Upgrade to 8.4 patch 4 with existing cloud authentication service

[JoseLuisMartinM]

Dear all,

We have an AM running 8.2 SP1 with Cloud Authentication services configured, with all the process needed for a 8.2 SP1: creating an agent for the IDRs, etc.

Now we are planning a (long overdue) migration to 8.4 and we've seen the new features in 8.4 patch 4 that make easier to integrate AM with cloud authentication services but we have a few doubts:

1) Shall the upgrade keep everything as is configured or shall we need to re-configure the AM with the Cloud Auth Service?

2) In case everything is kept as configured, shall we be able to use the new features, like managing the Cloud users in AM Security Console, the push to approve, etc. or shall we be stuck with the "legacy" features?

Thanks

[TedBarbour]

Hi Jose - AM 8.4 Patch 4 will allow you to add PIN+Approve functionality AND a more efficient Authenticate App tokencode verification (AM communicating the tokencode directly to cloud). 

On the other hand you could upgrade and keep everything as you currently have it if you'd like.

I assume you are currently using a Trusted Realm configuration to allow users to access Authentication Manager protected resources with Authenticate App tokencodes?

Thanks,

Ted

[Boydski]

Hi Jose,

I just went through the same basic upgrade (AM 8.3 to 8.4.0.4) and there were a few surprises.   Once the upgrade is completed and the Authentication Manager servers were communicating again with the Identity Routers, users were able to continue to use Authenticate Tokencodes for legacy authentication.  The cloud authentication panes do not appear in the AM Security Console until you enable direct communication with the RSA Cloud Service via the Security Console.   

Be aware that once you enable the direct connection to the RSA Cloud via the Security Console, the addition panes for Cloud Management show up, but that connections also essentially sets all user Authenticate Tokencodes to new PIN mode and will begin prompting anyone using legacy authentication via Authenticate Tokencode to create a PIN.  

The PIN+Approve functionality works after they create a PIN, but the immediate prompting caught us off guard.

Good Luck with your upgrade,

Scott

[KevinKyle]

Hi Scott,

You mentioned users in "new PIN mode" after completing the new P4 connection between AM and Cloud. Did these users already have SecurID tokens? If so, they should be able to being using PIN + Approve right away and should not have to set a new PIN.

When a user with an existing SecurID token first registers an Authenticate app, when they authenticate, if they enter just their existing SecurID PIN at the passcode prompt they should be sent a push notification and be able to tap to approve. So there should be no "new PIN mode" for these users. If the users do not have existing SecurID tokens, and therefore no existing PINs, then yes, they would need to enter their Authenticate tokencode first and set a PIN.

Please let me know if this does not match what you are seeing in your deployment.

Thanks,

Kevin

[Boydski]

Hi Kevin,

The new PIN requirement is for the RSA Authenticate App users that are using their Authenticate Tokencode to access Authentication Manager protected resources like VPN.   After patch 4 is applied and AM is connected directly to the Cloud, any users that attempts to authenticate using an Authenticate Tokencode is prompted to create a PIN for the Authenticate Token.   All of our users have already have PIN's on their old software tokens and that is NOT applied to the Authenticate tokencode. 

I checked that out myself.   I could authenticate with a software token, which has a PIN set, but when I tried an Authenticate Tokencode, I was prompted to create a PIN.   After that PIN is created, the PIN+Approve worked great.

Note that we rolled back the upgrade to remove the direct connection to RSA Cloud so we can notify our users about the new PIN requirement. 

[KevinKyle]

Thanks, Scott. The SecurID PIN will actually be applied to the Authenticate app during the first PIN+Approve authentication. For users that already have SecurID tokens and associated PINs, on their initial authentication with the Authenticate app, try entering just that existing SecurID PIN. So no Authenticate tokencode. Just enter the existing SecurID PIN. Authentication Manager should check the PIN entered by the user against PINs for their assigned SecurID tokens. When it finds a match it will create the record for the Authenticate token and apply that same PIN to the new Authenticate token. That all happens very quickly and the user should  be almost immediately prompted for an Approve on their registered device. Let us know how that works.

For users that do not have an existing SecurID token, they can enter the Authenticate tokencode and then as you described are prompted to create a PIN.

Thanks,
Kevin

[Boydski]

Thank you very much for the updated information.   We will give that method a try, which sounds a little more user friendly!

Scott

[JoseLuisMartinM]

Hi all,

We just did the upgrade to 8.4 patch 5 successfully. The AMs are now connected to the Cloud and the new Cloud panes appear in AM.

Users can authenticate with Authenticate tokencode, but when we try the PIN+Approve method, we enter the existing SecurID pin, and then we are prompted to press 1 for Approve or 2 for device biometrics.

Shouldn't we be able to get an automatic push without pressing 1?

Thanks for your help

[TedBarbour]

Hi Jose - can you add some detail around your scenario especially with regard to your authentication agent details (platform, agent type, etc.)?   

Thanks,

Ted

[JoseLuisMartinM]

Hi, Ted.

It's a RADIUS client, a Cisco ASA using the AM for authentication of a client-to-site VPN. The users connect with the Cisco AnyConnect client

We don't have the ASA defined as an agent (well, except for the implicity defined when you add a RADIUS client).