Radius Client Authentication failed For PIN+Token profile (New PIN Mode) with Cisco Anyconnect VPN
2 years ago
Article Number
000067927
Applies To
  • RSA Product set: SecurID
    • RSA Product/Service Type: Authentication Manager
    • RSA Version/Condition: 8.x
  • Cisco ASA OS version: 9.12(4)30
  • AnyConnect VPN version:  4.10.01075 (Macs); 4.10.03104 (Windows)
Issue
When users Authenticate with “no PIN” Tokens, authentication is successfully. But when “PIN + Token” profile is used, after getting challenged to set a PIN on AnyConnect VPN, authentication fails.

Wireshark logs showed different behaviors; user got challenged to set and re-enter the PIN and then authentication failed.
image.pngimage.png

image.png
image.png


Other logs showed multiple (3) requests were sent with slow response from Auth Manager.
(The timeout counter was set to default from Authentication Agent side)
image.pngimage.png












 
Cause
  • From Security Console >Setup>Settings>Session Handling, “Restrict Per User Sessions” was checked, limiting the number of concurrent sessions to 1 (concurrent_user_session_limit=1)
image.png
  • Run Database query:  
db=# select * from ims_config_value where name like '%ims.session%'; 
Ims.session.manager.user_session_control was set to 3

image.png

To access database follow: https://community.securid.com/t5/securid-knowledge-base/how-to-run-a-sql-query-for-authentication-manager-8-0-or-8-1-and/ta-p/8449

The user_session_control value set to 3 means that, if the number of existing sessions for the user attempting to log on have reached the concurrent_user_session_limit =1, then new sessions will not be allowed.
Resolution
Either you can increase the concurrent_user_session_limit to 3. Or change the user_session_control value to 1 which means it will force all other excess sessions to logout thus allowing the current new session.
Default value for user_session_control is 0 which means supports unlimited sessions. Thus we are suspecting this has been changed due to database migration. 
These changes can be made from security console or the database. Take a backup before making changes to database.


You can change "user_session_control" to 0 by uncheck "Restrict Per User Sessions" from  the Security console, Session Handling page, which will set its value to default 0.
You can change "user_session_control" to 1 by check "Restrict Per User Sessions" and enable radio button "Automatically close a current session, then open new session". 
You can change "concurrent_user_session_limit" from the Security console, Session Handling page - maximum per user sessions. (Server restart not required. ).
Make sure to provide limit as per customer’s need because once concurrent user session reached to the limit, we will face authentication failure.


Fix action was Unchecking "Restrict Per User Sessions" from the Security console, Session Handling page and restarting services the issue was resolved and customer was able to set PIN from Anyconnect VPN.
 
Workaround
Set the new PIN from Self-Service Console then try Authenticating from Anyconnect VPN.
 
Notes
Issue was with a specific Authentication agent (Cisco ASA) connected with Lab environment; however, the same agent was used with other production environment and was working properly.
Customer had imported the production database into Lab environment then reverted back to Lab database when the error was noticed, such changes could have modified the user_session_control/ concurrent_user_session_limit configuration in Authentication Manager, that is why error wasn’t seen with other production environment connected to the same Authentication Agent.

Related Articles

Trending Articles

Don't see what you're looking for?