You need to fix the CyberArk side. Possibly.
The RSA server can only handle 2 fields for authentication: the userid and [password field (which contains the passcode, or pin+token)]. If there is another password field in play (like ldap password or anything not a pin+token) it is not controlled on the RSA server side.
Once the user and the passcode is authenticated, with radius, we can attach radius return attributes (if you configure it) along with access-accept, for the radius client device to act upon. If CyberArk was using radius return attributes and now they are missing, that could be what changed.
CyberArk Software Inc. - Technology Integrations
If you only upgraded the RSA server from (what version?) to 8.1..all I can guess is you were using Radius
return attributes previously, and the CyberArk was using that return data to trigger some other action, and the new RSA server does not have the same radius profile. So, was a radius profile being used on the previous RSA server before upgrade ?
short summary:
RSA server sees incoming userid, checks if the user exists and is not locked out
RSA server looks at the password field and sees if it matches a pin and token belonging to that user
RSA server send back access-accept
RSA server checks if the user or the agent has a radius profile assigned, and if so, it appends additional attributes
to the access-accept return message.
The Radius client itself may be expecting the return radius attributes to contain specific parameters on what action to do next.
