Forum Discussion
AltostratusBIG-IP APM: RADIUS and SSO mapping broken
Hi All
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.
Cheers
Patrick
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.
David_GillCirrus
Hi Patrick
If you are using a one-time token then why would you be doing a SSO credential mapping at all since you will never be able to reuse the password variable due to it changing (every 60 seconds I presume)? Or are you using some sort of integrated software token where the user types in their PIN and the software generates the actual passcode in the background? A sample picture of the login page might help.
- renygma
Hi David
Thanks for your message. After re-reading my post, I noticed I totally forgot to mention that it is 2FA. The user first enters their AD credentials, and in a second window that is spawned from the RADIUS block enters the one-time token. I need the AD credentials for SSO.
- David_Gill
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.
- renygma
Hi David
Nice approach!
I did not even think of using an "AD Auth" at all, since my RADIUS server does AD authentication as well. But of course I can use it to get a correct PW into the SSO credential mapper. I only need one logon page though, since we don't have RADIUS ID and password. That should solve my problem though:
Logon Page -> AD Auth -> SSO cred. mapping -> RADIUS Auth.
Thanks 🙂
