Currently software tokens are expired and hardware tokens are not expired . I got the new token pack in a removable media .
1) So the question is how can I add or decrypt and import the new tokens to the system .
2).There will be any impact on the current running hardware tokens
3).What is token pack ID and where should I use the token pack id
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 18.104.22.168.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.
I've moved your question to the RSA SecurID Access" data-type="space space where it will be seen by the product's support engineers, other customers and partners. Please bookmark this page and use it when you have product-specific questions.
Alternatively, from the RSA Customer Support" data-type="space page, click on Ask A Question on the blue navigation bar and choose . From there, scroll to RSA SecurID Access" data-type="space and click Ask A Question. That way your question will appear in the correct space.
Thanks for the reply
Once I import what we will be the default PIN.
And the company information should exactly match with the order ?
If yes which portal I can find the company information used in the order ?
Please tell me once imported ,how to assign soft token to a user .
is it possible to assign both soft token and hard token to a same user ?
what if we have two server for redundancy
There is no default PIN. Tokens, when assigned, do not have a PIN set. The user will be prompted to set a PIN when they use their new token.
A userid can have three tokens assigned to it; hard and soft can be assigned to the same userid.
Changes are automatically replicated to the other instances from the Primary.
Assigning software tokens works much the same as with hardware tokens, but after assignment comes distribution, and that takes some setup. You'll need to have Software Token Profiles in place (created in the Security Console), and depending on your requirements, RSA Webtier software installed in your DMZ to allow end users to securely download their tokens without having direct access to your internal network. It's not difficult, but it takes some careful planning and work to get this set up. The product documentation (Planning Guide, Setup and Configuration Guide, Administrator's Guide, online help in the Security and Operations Consoles) discusses this at length, and there is quite a bit of help here in the community. If, after all this, it still seems overly complicated, I recommend engaging RSA Professional Services to assist with planning, architecture and implementation of soft tokens.
Thanks for the reply . Is it necessary (step 6 in the below guide ) all the information like first name last name ,email phone number must be same or I can change ?
The scenario is like below , users were assigned soft tokens . soft token were expired .so the users are assigned hard tokens .
Now the new soft tokens received and wants to import .If I am importing the new tokens does it affect the currently assigned hardware tokens ?
What if I choose the "Overwrite all duplicate tokens"
The question is " how to import the soft tokens without affecting the current users " .
Once imported does it will affect the current hardware token users
Hmmm, maybe I misunderstood your question. Are you importing new seed records (newly purchased), or are you importing a file of users and tokens from a different deployment? If you are importing new seed records, you will not affect already existing tokens or users.
If you are importing a file of users and tokens exported from a different system, then yes the users' first and last names and userids (and whatever else it mentioned) must all match or else the import won't work.
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
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
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.
Thanks for the reply .
I have very simple question now , actually I am repeating the question . Sorry If I could not convey it properly in previous post
The scenario is