How to understand the user authentications with Radius in ULO mode with Radius Access Challenge
search cancel

How to understand the user authentications with Radius in ULO mode with Radius Access Challenge

book

Article ID: 268381

calendar_today

Updated On:

Products

VIP Service

Issue/Introduction

There may be some confusion with a user Transaction Report when the VIP Radius is setup in ULO mode with Radius Access Challenge mode enabled.

The 'beginAuthentication' operation may show a false negative with the message "Authentication failed", but the user succeeds with the 'continueAuthentication' operation.

Environment

VIP Radius in ULO Mode with "Radius Access Challenge" mode enabled

Cause

The radius server is setup for ULO mode (Username + Password + OTP code). We are essentially doing both the first factor (AD username + password) and second factor (username + OTP code). By design, our radius expects all 3 at one time. The user is expected to input the username in the first field, and the password+OTP code in the same line for the second field.

Here is how the flow works for this type of setup:

  1. When we receive an authentication request, we use the username for both AD username and VIP userID (VIP Manager name). We then test the password input against the VIP cloud services to see if the user did include the OTP code from a VIP Credential. We automatically truncate the last 6 digits of the password input and test to see if it was a valid OTP code. This gets logged as the "beginAuthentication". If there was a valid code, then we validate 2FA and move to step 3 below.

  2. If the last 6 digits are not a valid OTP code, then we assume the user did not include the OTP code with their password and Access Challenge Mode then uses the Javascript integration script to "prompt the user to input an OTP code." We also check in VIP Manager to see if the user needs to be sent a PUSH, SMS, or Voice code. This 60 seconds keeps the radius request alive and gives the user time to receive/respond to the access challenge.

  3. We then initiate the first factor request. If the beginAuthentication came back successul, we send the rest of the password to AD without the last 6 digits. If the beginAuthentication failed, then we send the entire password input to AD.

  4. After the user responds to the Access Challenge, we log that as the continueAuthentication results and the radius waits for both first factor and second factor responses before responding to the application that the user succeeded or failed authentication.

*Note: This is why sometimes you may see that the 2FA succeeded, but we are still awaiting first factor response in the Transaction Reports

 

Resolution

Working as designed. Radius Access Challenge mode is needed if you want the user to input the VIP code in a separate "pop-up" window after they input the first factor credentials. It is also often necessary if you use PUSH, SMS, or Voice for 2FA delivery.