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.
* * *
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.
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).
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.
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
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.
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:
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
|Required Fields||TokSerial, ReplTokSerial|
csv file might look like this at it's most basic
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)
(one of the profiles I made in the security console)
and will deploy them as sdtid file attachment (-g) or ctkip (--ctkip)
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
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 (184.108.40.206.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
then all tokens below this will be Desktop PC 4.x