Forum Discussion
BIG-IP APM: RADIUS and SSO mapping broken
- Apr 01, 2022
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.
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.
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 🙂
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com