2FA via freeRADIUS, ignoring password

I've been tasked with setting up freeRADIUS to prompt a user for their second authentication factor (eg. Google Authenticator OTP) BUT without first checking the user's password.

I'm coming into this completely blind, with no prior RADIUS experience. We have a webapp that prompts the user to sign in so the password authentication is already done. We then need to prompt the user for a second authentication factor in order to perform certain actions. We don't want to repeatedly ask the user to enter their password (and caching it locally is a no-no, apparently) so what we'd like to do is configure freeRADIUS somehow so that it will:

• Ignore the value that we pass for the password in the initial request
• Return a challenge response which will prompt the user to enter their second authentication factor (eg. OTP)

Is this even feasible? Like I said, I don't have any prior RADIUS experience, so apologies if this is a dumb question.

I figured this out myself. If anyone is interested, it's related to the configuration in /etc/pam.d/radiusd

First, follow one of these tutorials to set up Google Authenticator as the second factor on your freeRADIUS server:
https://networkjutsu.com/freeradius-google-authenticator/ https://www.supertechguy.com/help/security/freeradius-google-auth/

When it comes to making changes to /etc/pam.d/radiusd, use one of these configurations:

1. To prompt for password AND Google Auth OTP:

   auth requisite pam_google_authenticator.so forward_pass
   auth required pam_unix.so use_first_pass
   account required pam_unix.so audit
   account required pam_permit.so

2. To prompt JUST for the Google Auth OTP (i.e. no password):

   auth required pam_google_authenticator.so
   account required pam_unix.so audit
   account required pam_permit.so

Note that this doesn't send a challenge response - it just means that the password doesn't need to be entered in the first place.

Radius is a network authentication/authorization/accounting protocol. It operates at layer 3 in the OSI model.

Your web application operates at layer 7.

So there's a bit of a mis-match here. You might use Radius for authenticating network connections such as WiFi or network ports, but you need something http-based for your web application.

I'm making some assumptions, but it sounds as though you have a Radius server for authenticating users on your network, and have leveraged the same database of users for authenticating users in your web application. Whether or not the web app is speaking the Radius protocol to authenticate users, your users are not speaking Radius when they enter a username and password into a web page, so Radius is not going to help you with this - it needs to be done in the web application.

If your web application has access to the radius server, it might be possible to determine which user is authenticated, and authorize/OTP prompt based on that, but this is web application logic. No amount of configuration in FreeRadius can achieve this for you.

So I'd recommend taking a step back and considering where your user data is stored. While you might be authenticating against a freeRadius server, Radius is just a protocol, and at the backend there is a database of users. This could be an LDAP server, an SQL database, pam or just a plain text file.

Assuming you have a common user database, you can then add some kind of Oauth/SAML single sign-on application (Okta and PingID are some commercial examples) to the authentication flow of each service, so that a sign-on in one place takes effect in another. With SSO in place, you can either modify your web app to require the second factor at certain points (it would have to know the user's existing OTP secret, or you could require they set up another one for this purpose), or you could use some kind of policy and reauth if the SSO technology you use supports it.

In conclusion, I can't see a way to do this in freeRadius alone, and even if you could you probably shouldn't. And to do the authorization part you are always going to need to modify the application, unless you implement some horrible man-in-the-middle proxy which totally compromises security.