- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How can you prevent expiring tokens from showing in the assign token screen?
In RSA Authentication Manager 8.3, how to you prevent token that will expire in the next 30 days from showing up in the Assign Token screen ? The assign token or replace token screen should only show tokens that have more than 90 days of life left on them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've moved your question to the RSA SecurID Access 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 page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question. From there, scroll to RSA SecurID Access and click Ask A Question. That way your question will appear in the correct space.
* * *
I removed the image that had your token serial numbers listed for security reasons. Please see Tips for Posting Questions to the RSA SecurID Access Community for information on posting personally identifiable information on a public site.
Regards,
Erica
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only way to do this is place tokens of whatever date range, into their own Security Domain, and then allow admins (who are not superadmins) to not be able to access that Security Domain.
Then only tokens you want will be available to those admins. The idea is we never want to block the ability to use a token that still has some life left on it.
In later patches (8.4 patch 10) you can no longer assign expired tokens, and also when the system automatically selects replacement tokens, you can choose ones that have longer life (the system used to pick any, and that was problematic when you had a mix of new and old tokens and wanted the system to automatically pick).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello IAN BARNES
The limitation of 50 tokens is only there when you try to assign the token from the User's Dashboard. If you click on the username and select SecurID Tokens instead, all available tokens will show up for you to choose from.
Give that a try and you should be able to scroll through the tokens.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, just going to the Authentication > SecurID Tokens > Manage Existing page [assigned/unassigned], you can see up to 500 at once.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can also filter the non-expired tokens from the list. You can choose the expired tokens and select all and delete them. Note : You can delete up-to 500 tokens at once
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We’re issuing replacement tokens in an environment that has both soft tokens and KeyFobs.
If we just choose “Replace with next available token” it will Choose a KeyFob.
The only place RSA AM allows us to select a specific replacement token is through the Dashboard view.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You might be able to get around this by moving all of the unassigned hardware tokens to another security domain (temporarily)
See more here on Security Domains and how to create a new one: Security Domains
I would imagine that this would then choose only a software token (in the same Security Domain) to replace the users current token with.
Since you mention that you have both hardware and software tokens in the environment, you may need to do this twice.
1st - Move all of the unassigned hardware tokens and replace the tokens for users who only posses software tokens.
2nd - Move all of the unassigned software tokens and replace the tokens for users who only posses hardware tokens.
-Tyler Mahoney-Eggers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The securid tokens list, also can let you choose specific replacements, instead of automatic.
Check off the tokens to replace, then use the dropdown at the top of the list.
Or you can use AMBA (authentication manager bulk admin) and script it and assign replacements by serial number and a CSV file you create:
Replace Token
The TokSerial field contains the token serial number of the token to be replaced and
must already be assigned to a user. The ReplTokSerial field contains the token serial
number of the token replacing TokSerial. The token specified by ReplTokSerial will
be assigned to the user as a replacement token. The TokEnabled field defines the
Token state following successful assignment. If the ReplTokSerial token is already
assigned, a FAILURE message will be generated. PinMode may contain a value of 1
to set the token in new PIN mode or a value of 0 or empty to not change the new PIN
mode.
Action | REPT |
Required Fields | TokSerial, ReplTokSerial |
csv file might look like this at it's most basic
Action,TokSerial,ReplTokSerial
REPT,000159871817,000132251661
REPT,000159871818,000132251662
REPT,000159871819,000132251663
REPT,000159871820,000132251664
But advanced usage can assign replacements
and for software tokens even email them out as ctkip links or sdtid file attachments in the same csv
This one sets the software token profile for all tokens below it
(until a new profile is set, or not, it stays in memory)
as GenericAES
(one of the profiles I made in the security console)
and will deploy them as sdtid file attachment (-g) or ctkip (--ctkip)
Action,TokSerial,ReplTokSerial
REPT,000159871817,000132251661
REPT,000159871818,000132251662
REPT,000159871819,000132251663
REPT,000159871820,000132251664
CIF,Action,SoftTokenProfile
SSTP,GenericAES
CIF,Action,TokSerial,TokEnabled,DeviceSerialNumber,DeliveryMethod,DestinationAddress
SSD,000132251661,1,,SMTP,zazx@farmco.local
SSD,000132251662,1,,SMTP,muffin@farmco.local
SSD,000132251663,1,,SMTP,spanky2@farmco.local
SSD,000132251664,1,,SMTP,gottem@farmco.local
So, to fire this off:
./rsautil AMBulkAdmin -a admin -P support1! --verbose -m 0 --ctkip -i inputfile.csv
(note this is using the debug options, useful when starting out with AMBA)
My end user(s) sees this email arrive for the replacement token:
Authenticator created for:
User ID: zazx
Name: null zazx
Token: 000132251661
Activation code: 001559091987
Activation url: https://edavis-vm162.na.rsa.net:8008/ctkip/services/CtkipService
If I use the very same input file but want sdtid file attachment, I use -g instead of --ctkip.
------------------------
NOTE: AMBA in the current version (8.4.0.10.0) uses named software token profiles and SSTP
Your version 8.3.x.x.x does not know about SSTP and profiles, instead that older version uses Key and KeyType....
example: older AMBA format for software token deployment
Action,Key,KeyType,MiscVariable
SSTDT,Desktop PC,FamilyKey,4.x
then all tokens below this will be Desktop PC 4.x
