Forum Discussion

renygma's avatar
renygma
Icon for Altostratus rankAltostratus
Mar 31, 2022
Solved

BIG-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

APM
application delivery
radius
security
SSO
  • David_Gill's avatar
    David_Gill
    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.

     

4 Replies

Sort By
  • David_Gill's avatar
    David_Gill
    Icon for Cirrus rankCirrus
    Apr 01, 2022

    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's avatar
      renygma
      Icon for Altostratus rankAltostratus
      Apr 01, 2022

      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's avatar
    David_Gill
    Icon for Cirrus rankCirrus
    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.

     

    • renygma's avatar
      renygma
      Icon for Altostratus rankAltostratus
      Apr 01, 2022

      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 🙂