Overview
Okta’s ASA (Advanced Server Access) allows customers to transform SSH and RDP authentication flows, eliminating the use of password and SSH-key based challenges by leveraging just-in-time, tightly scoped, ephemeral certificates. This improves the customer’s security posture while streamlining operations related to user lifecycle management and delivering a clean, uniform end user experience, regardless of hosting platform.
Okta allows for the enforcement of MFA when users access the ASA portal, but transactional MFA – an MFA challenge per server session, is not possible within the platform. (This feature is included in Okta Privileged Access.) Additionally, some customers wish to preserve some form of authentication when using sudo, another capability ASA does not offer, based on long-standing operational or security procedures.
Although ASA is unable to address transactional MFA requirements directly, it is possible to use Okta’s RADIUS agent to facilitate step up authentication for sudo using the open-source linux libpam_radius module. This guide describes the basic steps to establish this pattern.
Prerequisites
This guide assumes you already have a functional Okta organization with an ASA team connected and at least two Linux servers enrolled in a project. You’ll need one server to host Okta’s RADIUS agent and another from which to test sudo step-up MFA.
Okta RADIUS Agent
Step 1: Create a service account
Within Okta’s admin dashboard, create a new user account with the super-admin role. You’ll use this account when authenticating the Okta RADIUS agent for the first time.
Step 2: Install the Okta RADIUS Agent
Install the agent according to the documentation. You could run the agent on Windows as well, but since the use case is specific to sudo authentication, this guide assumes you’ll use Linux throughout.
IMPORTANT NOTE: During installation, you’ll be provided with a URL to register the agent within your Okta organization. Best practice is to use the service account created in step 1, above, when authenticating for agent registration. This way, any tokens created for the agent will exist under the service account instead of your own user.
Step 3: Verify agent health
Before proceeding, be sure the agent appears healthy in the dashboard.
Okta RADIUS Application
With an agent installed and configured, you’ll need to add a RADIUS application from the OIN to configure desired behaviors.
Step 1: Add RADIUS Application
- Browse the OIN app catalog and search for “RADIUS”.
- Select “RADIUS Application” from the result set, and click Add Integration.
Step 2: Initial Configuration
- Update the Application label to something like “RADIUS for sudo step-up authentication” and click Next.
- Disable the Okta performs primary authentication option. Because we’re using ASA’s ephemeral certificates for primary authentication, we don’t want to reduce our security posture by stepping down to username and password. Instead, we want RADIUS to offer MFA challenges only.
- Set the UDP Port. The default port for RADIUS authentication is 1812. Specifying alternate ports allows for multiple use cases to be served simultaneously, each with a unique RADIUS Application configuration.
- Create a Secret Key. This key is necessary to authenticate RADIUS clients (Linux servers) to Okta’s agent.
- Change Application username format to “Custom”, then paste in this expression:
String.replace(String.substringBefore(user.login,”@”),”.”,”_”)
This assumes you’re letting ASA automatically derive the unix username based on the Okta user.login attribute. This transformation is necessary because when the Linux server attempts to authenticate sudo commands via RADIUS, it’s going to use the username ASA used during session setup, not the Okta username. - The Update application username on option should be set to “Create and update”.
Step 3: Advanced RADIUS Settings
- In the Client IP section, leave the Report Client IP option disabled. We really only care about the server IP showing up in the logs, which happens by default. Information about the client IP can be found in the ASA generated audit events.
- In the Groups Response section, leave the Include groups in RADIUS response option disabled. Groups are managed by ASA.
- In the Authentication section, leave all options disabled.
Step 4: Sign On Policy
- The Default sign on rule, requiring multifactor for every session from all devices, requires no modification.
Step 5: Assignments
- Assign the same groups and users currently assigned to the ASA application. Alternatively, you can assign the “Everyone” group.
Linux Server Configuration
With Okta ready to respond to RADIUS based MFA requests, the final configuration steps are performed on the servers which require step-up MFA for sudo access. This step assumes you have already enrolled the server in your ASA team. These steps should be scripted for deployment at scale.
Step 1: Install and configure pam_radius module
- Install the libpam-radius-auth package. For debian based Linux distributions, run:
sudo apt-get update
sudo apt-get install libpam-radius-auth - Configure the libpam-radius-auth package to use the Okta RADIUS Agent installed earlier:
sudo nano /etc/raddb/server
Add the following lines to the file:
# Use Okta RADIUS agent for sudo step-up MFA with 60 second timeout
<IP address of Okta RADIUS Agent> <RADIUS Secret Key> 60
Press CTRL-X to save and exit. - Ensure only root can access the libpam-radius-auth configuration file
sudo chmod 600 /etc/raddb/server
ls -l /etc/raddb/server
Step 2: Update PAM configuration to use RADIUS for sudo
- Open the /etc/pam.d/sudo file:
sudo nano /etc/pam.d/sudo - Comment out the three @include lines by prepending each with a #
- Add the following line at the end of the file:
auth sufficient pam_radius_auth.so client_id=NAS_Identifier conf=/etc/raddb/server
Press CTRL-X to save and exit. - Review the updated file:
sudo cat /etc/pam.d/sudo
Override ASA Default Admin Sudo Entitlement
When assigning a group to an ASA project, you can choose either User or Admin in the Server Account Permissions section. When Admin is selected, ASA adds group members to the sft-admins group on the Linux host. The ASA managed sudo entitlement for members of this group includes the NOPASSWD option.
As a result, groups assigned with the Admin permission will never be prompted for a password when running sudo. To change this behavior, a new sudo entitlement is needed.
Step 1: Create new entitlement for all commands
- Create a new sudo entitlement named “all-with-password” or similar.
- Add a Description for clarity: “Allow all commands but with password required.”
- Under the Commands section, change the type to Raw and enter ALL in the command entry box.
- In the Advanced Configuration section, ensure the Enable NOPASSWD option is disabled.
Step 2: Assign a group to ASA project
- Add a group to a project, and give it User permissions.
- Click Update Group
- Click Add Sudo Entitlement Binding
- Select the entitlement created in step 1 above, then click Submit
Test Sudo Step-Up MFA
Once the above steps are completed, for any sudo commands where password is required, the user can satisfy the prompt depending on the MFA challenge they want to use.
Step 1: Connect to the test server via ASA
- Connect to the test server using ASA as you normally would. If demonstrating this flow to a customer, it may be beneficial to show the entire Okta login flow, including how a user enrolls new authenticators, but this is not necessary for testing.
Step 2: Run any sudo command
- Any command will do, but I typically test with something simple:
sudo -l
(that’s a lowercase L, not an uppercase I)
Step 3: Respond to the password prompt
- For push notification with Okta Verify, enter the word push
This should work for Duo as well, but is untested. - For TOTP code from an authenticator app, simply enter the code as shown by the app for the appropriate account.
- For Yubikey OTP, simply tap the button on the Yubikey to have it paste the OTP directly into the password prompt.
Thoughts on RADIUS for MFA
Okta Support
At the time of this writing, this configuration is not supported by Okta.
Security Considerations
While RADIUS is a very old protocol and the transport of credentials is cryptographically weak (libpam_linux supports PAP only), my opinion is that when used only for secondary authentication in which no static knowledge factor is ever transmitted, the risk of interception and subsequent replay of credentials is eliminated.
Furthermore, because session setup requires ASA’s tightly scoped, ephemeral certificates, there’s no risk of this becoming an attack vector for malicious actors attempting to access the host via SSH. This flow is used only as an in-session validation of user identity, protecting from someone leaving their workstation unlocked when they step away, or as a cautionary speed bump to encourage a user to consider the impact of what they are doing before actually doing it.
RADIUS vs ASA+RADIUS
Because of the weaknesses described above, customers should avoid using RADIUS for primary Linux authentication. Because libpam_linux only supports PAP, and only in securing the password itself, risk of interception of usernames and passwords via network packet capture is high. This would be a considerable step down even from LDAP, which can encrypt the entire authentication flow, although it’s still dependent on username and password input.
By contrast, ASA eliminates the use of passwords during session setup entirely, delivering a true SSO experience. This improves the security posture of the server fleet while streamlining user LCM and providing a clean, uniform end user experience, regardless of hosting platform.
Augmenting ASA with RADIUS for sudo step-up MFA provides options to customers that want to embrace new, advanced authentication flows while preserving trusted operational and security procedures that may have been in place for decades. And because it uses authenticators already enrolled in Okta, there’s no additional MFA administration burden, nor additional user training required.
API Rate Limits
By using RADIUS only for sudo step-up MFA, impact to API rate limits should be minimal. However, for very large organizations, some consideration should be given to making rate limit adjustments as necessary.
Compatibility with Okta Privileged Access
At the time of this writing, OPA (Okta Privileged Access) does not support the management of sudo entitlements. Once that feature is released, configuring RADIUS for sudo step-up MFA should follow the same setup steps, with the exception of ASA specific sudo entitlement configuration.
IAMSE