We have launched Robotics process automation pilot (BOT) which needs access using RSA Token. The RSA Token is asking to enter the next RSA code after the first one is entered. This is a "BOT", so we need to disable the next token. Is the process to do is too select "Disabled" the token under the Token Status for the specific token?
That cannot be turned off. It may be able to be cleared. The policy for BOT can be weakened to prevent triggering it too early.
Next tokencode mode might be part of the initial use of a token, where you are using it for the first time and setting up a pin for it. That must be done in order to get the pin set up for a newly assigned token. Next tokencode might be due to too many failures and now forced to enter two codes to prove token ownership. Next tokencode might be from a bad time on the RSA server and/or bad time on the token device.
So without full context on 'why it is in next tokencode mode', just tossing out information about it.
Ways to fix it:
You would go to the userid the BOT is using, and 'authentication settings', and clear incorrect passcode count
and that will turn off asking for the next tokencode (until the next time it is triggered).
You could reduce the chances of it occurring by making a security subdomain, and making a special 'weaker' policy just for the BOT, where it takes more failed authentications to trigger next tokencode mode, and putting BOT into that subdomain so the policy applies to that userid.
Or, set up a fixed passcode for the BOT. Go log in with it somewhere so it can be changed (the first use of fixed passcode allows user to change it to a different one). Now once the fixed passcode has been changed, the BOT can use that same code indefinitely until policy dictates the fixed passcode needs to change again.
(or the policy can make it permanent for all time).
Just be sure the userid for the BOT doesn't have true access to secured resources since a fixed passcode is very weak from a security standpoint, but they are good for BOT testing a login (radlogin4 is one example of a radius test client BOT that can alert you if an RSA server refuses login).
Hello Ed,
Thanks for the insight. So, if the token is being used by an automation script that does not expect the next token, then there is still no way to disable the “next token” functionality after the first attempt. With what you stated about clearing the “incorrect” password count, that would take into consideration that there have been failed login attempts, correct? So, in this case, I don’t see any failed attempts to clear.
Thanks,
Derrick Chapman
As Ed says,there are two ways to get into "next tokencode"; one is to exceed the number of configured failed attempts, and the other is if the entered passcode is outside the small window of acceptable passcodes but still within the large window. This can happen when the time on the token device differs from the time on the AM8 servers. The AM8 server wants the next tokencode to make sure you didn't just make a lucky guess, and to try to figure out exactly how far off your time setting is from its own. As Ed says, this one (time based) cannot be disabled. You must code your bot to handle next tokencode requests from the server. You should code it, actually, to handle ALL the possible returned statuses. There aren't many. They are shown in the sample code and docs with the authentication sdk.
That cannot be turned off. It may be able to be cleared. The policy for BOT can be weakened to prevent triggering it too early.
Next tokencode mode might be part of the initial use of a token, where you are using it for the first time and setting up a pin for it. That must be done in order to get the pin set up for a newly assigned token. Next tokencode might be due to too many failures and now forced to enter two codes to prove token ownership. Next tokencode might be from a bad time on the RSA server and/or bad time on the token device.
So without full context on 'why it is in next tokencode mode', just tossing out information about it.
Ways to fix it:
You would go to the userid the BOT is using, and 'authentication settings', and clear incorrect passcode count
and that will turn off asking for the next tokencode (until the next time it is triggered).
You could reduce the chances of it occurring by making a security subdomain, and making a special 'weaker' policy just for the BOT, where it takes more failed authentications to trigger next tokencode mode, and putting BOT into that subdomain so the policy applies to that userid.
Or, set up a fixed passcode for the BOT. Go log in with it somewhere so it can be changed (the first use of fixed passcode allows user to change it to a different one). Now once the fixed passcode has been changed, the BOT can use that same code indefinitely until policy dictates the fixed passcode needs to change again.
(or the policy can make it permanent for all time).
Just be sure the userid for the BOT doesn't have true access to secured resources since a fixed passcode is very weak from a security standpoint, but they are good for BOT testing a login (radlogin4 is one example of a radius test client BOT that can alert you if an RSA server refuses login).