I recently noticed our service desk started using the new RSA AM v8.2 "Extend SecurID Token Lifetime" feature. Unfortunately, it seems users are unable to logon with these extended tokens (one expired 31/12/2016 and was extended, but user can't logon).
I've checked the manual on this feature but I still don't understand what this about or when/how to use it. I can't test atm because I have no tokens expiring soon (and for other tokens it says "The token cannot be extended. It has more than 15 day(s) remaining before token expiration.")
The manual says:
For example, a token that will expire in 15 days can be extended so that it will not expire for another 30 years. An unassigned token that expires in 30 years provides a new expiration date to the distributed token that was expiring in 15 days, and the unassigned token is deleted. The original, distributed token on the user device receives an extended lifetime in Authentication Manager.
Does this mean the extended token just "claims" one of the free non-extended tokens and uses its 'presence' to continue authentication? Thanks for helping out!! Regards,
- Auth Manager
- Authentication Manager
- Community Thread
- extendable tokens
- Forum Thread
- RSA SecurID
- RSA SecurID Access
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
This is a new feature, and only works on Soft Tokens that were distributed under AM 8.2 or later. So if you distributed these software tokens back in AM 8.1 SP1 P15 or less, then upgraded to AM 8.2, you would have to distribute that software token again in order to extend it.
Basically both the AM server and the token need to know how to extend the lifetime, and that 'knowledge' was not included in software tokens distributed pre-8.2
Thanks for the info - that bit is all clear, however, I don't understand how the extension works technically. I mean, if I could just extend expiring tokens with another 30 years, we would never have to buy another token again. The way the manual describes it, we would never have to replace another token as they can simply be extended.
In the portal, I still see the token as "expired on 31/12/2016" but on the user's device, the expiry is now showing as 2035. Will the AM portal still authenticate this token? If not, then what did the "Extend Expiry" do? Hope you see my point!!
To your question:
Does this mean the extended token just "claims" one of the free non-extended tokens and uses its 'presence' to continue authentication?
Yes on the RSA server, the expiring token 'claims' the expire date of the new token.
The end user experience is they install the token once, and never deal with installing
it ever again, and it never expires on their device.
All the user notices if you do not extend the token past is expire date, is logins start to fail, whereas before
version 8.2, the end user would have the software token app tell them the token is expired.
Thanks for your comments all - very useful information! Also about the tip regarding authentication "suddenly" failing will definitely come in handy as neither users nor helpdesk will understand why the token kept on going regardless of its (server-side) expiry date.
Just one last question - is it correct that the token that is used as "Extension token" (so the one with a future expiry date, which is 'borrowed' by the already-expired token) cannot be found anymore in either the "Assigned tokens" or the "Unassigned tokens" overview?
It shows up when I dig up the old/expired token and then check the "Extension token" field, but when doing a search, it's almost as if the token has disappeared - is this by design?! Tx!
Thanks - I indeed see the extension token does not even return when unassigning the initial token from the user. It's almost as if the 2 tokens were merged, leaving just a record of the old token (and the extended token actually inherits the deleted token's expiry date).
Cheers for the help!!