BIG-IP APM: RADIUS and SSO mapping broken
I think that using a combination of RADIUS authentication (with one-time token) and SSO credential mapping within APM is broken.
Credentials entered on the logon page are stored in the username & password session variables. If you do a RADIUS authentication with one-time token, the password variable will be overwritten with the token. So an SSO credential mapping after the RADIUS authentication will get a wrong password.
You can prevent this with either putting the SSO credential mapping before the RADIUS block, or "caching" the initial password in a separate variable with variable assign before ( password2 = password ) and after ( password = password2 ) the RADIUS block. However, this fix will not work if the user enters the wrong password initially. The RADIUS block will reload the login page and show you the "wrong credential" warning as often as you define, but the SSO credential mapping or variable assign defined BEFORE the RADIUS authentication won't be updated with the correct password.
I know that I could set the "max. attempts allowed" to 1 and have a completely new APM session after every wrong credential or I could build a loop and lose the "wrong credential" message, but those 2 options are not that pretty in my opinion.
I'm just wondering if someone has a nice solution to this problem.
This example uses AD and Radius authentication. Authentication is performed in the Macro, "AD and 2FA" Login. Logic is as follows:
Macro: AD Logon Page
Logon page is presented where the user is prompted for AD credentials. The credentials are not authenticated but rather they are stored in session variables for the time being.
Macro: Radius Logon
A second logon page is presented this time asking for Radius ID and password. The Password is authenticated based on number of attempts you allow, etc. If the Radius authentication fails then the session terminates. If successful, the access policy continues to the next macro which is AD Auth after 2FA.
Macro: AD Auth after 2FA
The AD credentials that were save during the AD Logon Page macro are restored to the original session variables and now you do an AD Auth to validate them. If AD Auth passes then the session is allowed. If the AD credentials fail, you re-present the AD logon page and give the user another attempt (or two?) to try again. In my example, I do not allow the user to change the userID originally entered (hence the name of the macro) but you may not want/need to do that.
The advantage of this method is that it prevents people from locking out random AD accounts since the AD credentials are not validated until after the Radius credentials pass.
Hope this helps. I have been using this for many years on many systems.