The following reconfiguration has been identified as part of the preparation needed to perform the upgrade to Okta Identity Engine (OIE). Note that additional Okta features may require reconfiguration or be disabled in order to complete the upgrade. The initial, legacy release of the Okta RADIUS Agent required the creation of an Okta Sign-On Policy rule with RADIUS criteria to control Multi-Factor Authentication (MFA) for RADIUS authentications. In the legacy model, settings such as port, shared secret, and timeouts were managed locally on the server where the RADIUS agent was installed.

  
Screenshot: RADIUS ‘Legacy Model’ with authentication configuration in Okta Sign-On Policy

• Okta RADIUS Agent

• Okta Identity Engine (OIE)

• Upgrade Eligibility: Not Eligible - Customer Configuration Required

• RADIUS Legacy authentication

The infrastructure that supports the Legacy Model is retired.

Okta reimplemented RADIUS support using an App Model in 2018. This model provides multiple RADIUS applications available in the Okta Integration Network Catalog, each containing RADIUS in the application name. Associating the installed agent with a specific application moves many of the RADIUS configuration settings to the Okta user interface (UI). This simplification improves documentation, simplifies authentication policy, and makes it possible to support multiple services using RADIUS authentication in one organization (Org), each with discrete settings and configuration.

The App Model RADIUS implementation is in General Availability (GA) and allows the RADIUS agent to be configured centrally inside the Okta admin console.

Deactivate any sign-on policies configured using the legacy configuration and remove all legacy sign-on policies. Test to confirm that RADIUS authentication works using the App Model. Once complete, delete the Okta Sign Policy Rule containing the RADIUS condition.

NOTE: If RADIUS applications are deployed, the legacy model is not being used. In this case, verify that there are no sign-on policies configured using the legacy configuration and remove any legacy sign-on policies.

Transition to "App Model"

Follow these migration steps to transition RADIUS to the App Model for authentication:

1. Identify the service supported by RADIUS.

   1. For the majority of customers receiving this message, only one service is supported by RADIUS. In the Legacy Model, supporting multiple RADIUS services requires multiple Okta tenants/subdomains. Typically, supported services were overwhelmingly Virtual Private Networks (VPNs).

   2. For organizations that have multiple Okta tenants to support multiple services using RADIUS, follow the additional steps in the general actions section.

   3. Obtain the PORT, SHARED SECRET values, and timeout configurations on the server where the RADIUS agent is currently installed. NOTE: These values are necessary for Step 4.

   4. Ensure that the running RADIUS agent meets the minimum version required. Okta RADIUS Server Agent 2.5+ must be running. NOTE: Okta suggests upgrading to the Early Access (EA) version 2.14.0.

2. Test a login to the existing service before continuing.

   • This ensures that the existing configuration works and provides a baseline of the user experience to compare to the updated configuration.

3. (Optional, but recommended) Test the App Model.

   • Prior to migrating the existing configuration, consider deploying a completely new configuration with the App Model in another Okta tenant (for example, Okta Preview) to test and understand the flow.

   • A RADIUS test tool like NTRadPING can be used to validate behavior. Follow the instructions to deploy a new service..

   • NOTE: Test in a separate Okta tenant to avoid impacting Production users. Once a RADIUS Application is deployed and activated in the tenant, all RADIUS servers connected to that tenant switch to using the App Model. All legacy sign-on policies for RADIUS are ignored.

4. Deploy a RADIUS App integration to the environment.

   • Follow the instructions here to deploy the Okta RADIUS application.

   • Important things to note:

     • When configuring the Okta application, use the values for PORT and SHARED SECRET from the existing configuration (see Step 1).

     • Okta for MFA only: If the configuration being migrated is only used Okta for Multi-Factor Authentication (specifically, the service supported by the RADIUS connection performed primary authentication and Okta provided MFA), clear the Okta performs primary auth checkbox on the Sign On settings tab of the application in Okta.

     • Advanced RADIUS Settings: For each RADIUS application, make sure that Advanced RADIUS Settings are configured in the Sign On settings tab to match the experience of the prior configuration.

       • Inline Enrollment: If users need to be able to enroll in MFA through the RADIUS client, select the box next to Enable inline MFA enrollment and save the settings.

       • Windows Users: If users are using the Command Prompt or PowerShell to connect to a service that authenticates via RADIUS, select the Single-line MFA prompt to ensure readability. NOTE: This returns all the MFA options in one line and may be a slightly different user experience than through the RADIUS Legacy Model.

5. Test the configuration.

   • Assign a test user to the new application. If MFA is required for the application, ensure that the app sign-on policy has a rule that prompts for MFA every sign-on.

   • Test the configuration by authenticating the test user to the service to confirm that the migration was successful.

   • Assign the rest of the users or groups who need access to this RADIUS application.

6. Remove any old legacy policies from Security > Authentication > Sign-On Policies.

   • To remove a legacy sign-on policy, ensure that the same users/groups assigned to the legacy sign-on policy are also assigned to the application and its associated sign-on policies.

   • Test removal of legacy sign-on policy for a few users by excluding them from the legacy sign-on policy. Test RADIUS authentication with these users for a few days.

   • If they work, disable the legacy sign-on policy.

   • After a few weeks, delete the legacy sign-on policy.

Related References

• How to Test if Okta RADIUS Agent / RADIUS Application is Working Properly with NTRadPing
• RADIUS applications in Okta
• App sign-on policies