RSA Token Assigning Problem
license violation active user limit exceeded message prompts while we have 7 unassigned tokens available to use. I removed about 4 users from active directory then assign token to new user by using RSA this time problem resolved. Kindly guide me regarding this problem and why token assigned after deleting users from AD?
- Authentication Manager
- Community Thread
- Forum Thread
- Licensing Issue
- problem in assigning token
- RSA SecurID
- RSA SecurID Access
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
First, the users with tokens license does not expire however it has a "users with tokens" limit that can be reached and after that you will not be able to assign more token to users.
Hence, there is 2 different aspects, the first one is the "users with tokens" license limit which should be available in order to assign any available tokens and it can be viewed or imported through the "Security Console > Setup > Licenses".
The other aspect is the tokens' seeds which you import separately through the "Security Console > Authentication > SecurID Tokens > Import SecurID Token Jobs".
Therefore, I believe you have tokens' seeds available but there is not enough license limit.
Regarding the AD users deletion, kindly perform a clean up from the "Security Console > Setup > Clean Up Unresolvable Users" so as you can restore the tokens as unassigned.
The Clean up can be done for specific Identity source to clean up all the users that have been deleted recently from this identity source.
Any user, with any single way to authenticate or more, takes 1 off the licence.
One user with: token, two tokens, three, a fixed passcode, on-demand, or any combination, takes 1 off the licence.
Passwords alone, do not. An authenticator, or more, does.
When a user is deleted from the internal database,
authenticators go back to unassigned, and the licence will free up one slot.
When you have an AD or LDAP user, and you remove them from AD,
the authenticators do not get unassigned, the userid and any authenticators remain assigned to <unknown> and the idea is, if the reason the user is missing is a simple network outage or other problem reaching LDAP, everything is normal once LDAP connectivity is restored. The system does not know if you deleted a users from LDAP intentionally, or there is an outage, so it keeps things assigned in the internal database, hoping to see the userid come back.
The identity source cleanup routine is what will go in the database and scrub all LDAP orphans and free up licence slots if you know you've made some changes and want tokens freed. The 'cleanup now' has a preview of objects it could clean, and you can review it and if you know why certain userids are on the list, then a cleanup can fix the licence count.
The scheduled cleanup can take care of this automatically, and also this cleanup job be set to not run if there are suddenly more objects to clean than expected (in case there is a network outage you may not want the cleanup to assume all ldap user info can be erased) so it has adjustable settings such as 'do not run if more than 50 objects' or 'do not run unless objects have been sitting for 7 days or more).