- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Replacing expiring tokens via Self Sevice
Hi All,
We have a high number of tokens expiring soon and this is our first time using our new 8.1 self service portal for replacement. One thing we are noticing in testing is that the users can definitely go on the site, hit replace and get a CTKIP activation email with the new token activation details...
We are only deploying desktop PC and MAC tokens
After the user goes through the activation process, the token gets imported and the process completes.
The issue is it appears that the old token is still retained as the current token and the new one shows as "Pending Replacement"
Does anyone know if this is by design? It would make sense that the new token will not become active until the current token actually expires in a few days.
If this isn't the correct behavior... what else does the user need to do to activate the new token and begin using it?
Thanks
Version 8.1 r14
- Tags:
- 8.1
- activation
- aiuth manager
- AM
- Authentication Manager
- Authenticator
- Authenticators
- Community Thread
- ct-kip
- Discussion
- Forum Thread
- pending replacement
- RSA SecurID
- RSA SecurID Access
- SecurID
- self-service console
- software tokens
- ssc
- Token
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By design:
when you get a replacement token, user now has two tokens assigned, an O and an R
the original one (O) keeps working until
a) it expires
or
b) you actually use the replacement token (R) with the original token pin to log in
Default policy unassigns the (O) token only when (R) is first used (even if (O) still has life left)
and (O) goes to the unassigned pile, and is disabled.
Also by default, (R) inherits the (O) token pin. But you can change policy to
require a new pin with the (R) token, or delete the (O) token from the
system when (R) is first used successfully.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By design:
when you get a replacement token, user now has two tokens assigned, an O and an R
the original one (O) keeps working until
a) it expires
or
b) you actually use the replacement token (R) with the original token pin to log in
Default policy unassigns the (O) token only when (R) is first used (even if (O) still has life left)
and (O) goes to the unassigned pile, and is disabled.
Also by default, (R) inherits the (O) token pin. But you can change policy to
require a new pin with the (R) token, or delete the (O) token from the
system when (R) is first used successfully.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the response... it felt like it was by design. We just went through the process of using the new Token to connect and sure enough it became the default and removed the expiring token, so we are good.
