Accepted Solutions
Hi,
RE:
The scenario is
I have software and hardware tokens . Now the software tokens are expired .And ordered for new tokens .
(User A was using software tokens and it is expired and now I assigned hardware tokens to User A )
today I received software tokens from RSA .
My question is If I am importing the new tokens does it affect the current hardware token users ?
a) Nothing will affect current users by simply importing more tokens on the system
( I mean does it affect the USER A ) .
second question
If I have a hardware token and If it is expired do I need to buy the new hardware token device or just renew ?
b) If you want to continue to use hardware token, you need to buy new ones and assign them or assign as replacements.
hardware tokens have no way to continue past the expire date etched on the reverse of the token itself.
You could assign software tokens as replacements to the expiring hardware token and get the software token to the end user. Just
note the restrictions on the 'pin number complexity' and 'type of software token' you distributed if you want the user to use
the old token pin with the new software token (if pins will transfer to the new token it makes token replacement more seamless)
----
1) you can import any tokens at any time, it has no affect other than you now have more tokens on the system that can be assigned.
2) any user can have up to three active tokens assigned at any time, all with their own pin, and do not interfere with each other. most users have one token though...but three are technically possible.
3) in fact a user can have six tokens assigned at one time if you assign a replacement token to each existing token. a replacement token is when a token is about to expire, you can assign a replacement token, and the original token keeps working until it actually reaches the expire date, OR the user 'gets around to' using the new replacement token for the first time. By default when a user uses the replacement token for the first time, the original becomes unassigned.
4) when using the replacement token feature, the new token will inherit the old token pin number*, so the user just uses the new token with the old pin and it is pretty seamless. *if the new token can use such a pin....
5) If the original is a hardware token, and the replacement token is a software token, note that the PIN can only transfer seamlessly if the pin format used on the hardware token will work with the replacement token. example: I have a hardware token and a pin of XY12...my new replacement token is distributed as PINPAD style software token. PINPAD software tokens have to use numeric pins only (because the pin is mathematically added to the tokencode, non-numeric characters in the pin won't work with PINPAD type tokens) , so I will need to set up a new pin for the new software token. But if the new software token is distributed as KEYFOB style, I can use the alphanumeric pin.
Software tokens are highly flexible by the admins, and you can distribute them as keyfob or pinpad style.
6) If the original token that is about to expire is a software token, and that software token has long expiration date of 2035 on the user device, but a normal expire date on the RSA Security Console, that indicates the software token originally was distributed from version 8.2 or higher, and it should have an extendable flag set on the Security Console when you look at assigned tokens. The extendable flag means you could 'extend' the old token with a new software token you recently imported, and the old token will inherit the new token expire date, the new token will be deleted, the old token will permanently be flagged as being 'extended by' the serial number of the new token, and the end user needs to do nothing...the token will keep working up to the new expire date recently inherited. Hardware tokens cannot be extended.
Here is an example: I have three old tokens from 2004. serial numbers 00020735xxx are a very old batch I had. I assigned and distributed them to users and of course they do not work, as they are all expired. But they did come from an 8.4.0.5.0 system, therefore the expire date on the user device is in 2035. They work on the user device but the RSA Server denies authentication. So I went to my unassigned tokens where I have more recent non-expired tokens 00011603xxxx batch, and extended these old tokens. They will immediately start working for authentication, and are permanently marked with the serial number of the tokens they inherited the expire date from. Next time around I can extend these again and again as long as I have new unexpired software tokens to extend them with.
Hi,
Thanks for the reply . I am an accidental administrator 
.
Here is the scenario
most of the users were using software tokens and few of them using hardware tokens . So we assigned hardware tokens for those who expired . Now all of them are using hardware tokens .
today I received software tokens . My question is If I am importing the tokens does it affect the current hardware token users ?
And what do you mean by from a different deployment
Thanks
If you are importing an .xml file that you downloaded or received from RSA, that is the Token Seed record that Steve is talking about. Inside this file you would see a record for each Serial Number of a software or hardware token, like this
<TKN>
<SN>159871813</SN>
<Seed>=CFngxGplS2QePgVLkLF9Ng==</Seed>
<Birth>2016/05/11</Birth>
<Death>2021/06/30</Death>
<TokenMAC>C3s6rcbc3oafSfSUxl0sIw==</TokenMAC>
You would import this file in the Security Console - Authentication - Tokens - Import
You can either ignore duplicates or overwrite them, but if this is the first time you are importing a token seed record, there should be no duplicates. If you import the same file a second time, every token Serial number will be a duplicate unless you had deleted that serial number. When you buy new tokens from RSA you would need to import the token seed record .xml file for those tokens in order to assign those tokens, and in order to distribute assigned software tokens. These files just have tokens.
The other thing Steve mentioned was Import and Export Users and Tokens, from one deployment (Primary) to another. If interested there are some references to these types of jobs.
