RADIUS integration and redundancy

RADIUS secondary IP address has changed since we moved some of our production nodes to a new data center.

Please, refer to Infrastructure - IP Addresses to know more about the migration.

In this documentation will take for granted that you already have your Appliance / RADIUS client (VPN concentrator, Authentication servers ...) up and running.

Connector configuration

Create and configure the TrustBuilder MFA RADIUS connector.

1. Connect to the administration console https://www.myinwebo.com/console

2. Go to “Secure Sites” tab

3. In the “Connectors” part, choose “Radius Push” in the drop-down list of possible connectors

4. Fill in the “IP Address” field with the IP of the public interface of your device (or NAT address if behind a firewall).

5. Enter a “secret” and keep that secret in mind for a later use in the configuration of your device.
   (As a reminder, a shared secret is a text string that serves as a password to secure communication between a RADIUS server and a RADIUS client)

6. Validate your connector configuration by pressing “Add” or “Update” button.

Any modification made to your radius configuration will be applied within the next 15 minutes.

RADIUS server parameters

Read about the RADIUS server parameters available for client configuration.

Authentication Mechanism

Most of radius clients configuration allow to configure a primary and a secondary server for fail-over purpose.

1. If the primary server does not respond client request within the specified “timeout”, it tries to send the authentication request again to the same server (retry).

2. If a response from the primary RADIUS server is not received after the maximum number of attempts, the RADIUS client (appliance or server) contacts the secondary RADIUS server (fail-over).

3. If the RADIUS client cannot contact the secondary RADIUS server after the timeout and retries, authentication fails: The user will be prompted to restart the authentication process.

Recommended Addresses and pair configuration

To cope with the evolution constraints of our platform and in order to increase resilience, we are providing you with two Radius server pool. Each radius server pool load-balance the workload on several radius servers located in different data-center:

• Primary: radius-a.myinwebo.com (95.131.139.137)

• Secondary: radius-b.myinwebo.com (217.180.130.59)

See Infrastructure IP Addresses documentation to know more.

These addresses allow you to access our RADIUS internal servers.

See below “Monitoring Radius services“ for more information about failover and monitoring.

Configuration items

The successful redundancy of the radius-based authentication service depends on the “radius client” configuration.
As a prerequisite for this documentation, we indicate the following items description:

• Timeout /Server timeout period: the time allowed for one server to answer one request (below 28s to avoid UDP idle timeout)

• Retries: Number of times the request is re-transmitted (same login and same OTP)

• Fail-over or Failover: Switching mechanism between the primary server and the secondary server when all attempts on the primary RADIUS server have failed

RADIUS authentication modes

TrustBuilder proposes two configuration modes a “standard” mode and a “Push” mode:

• in "standard" RADIUS configuration, RADIUS servers waits for a login with a correct OTP as the password in the authentication request from the start. Consequently, the RADIUS authentication time can be short between 3-10s (see chapter "Standard" RADIUS authentication mode)

• in “Push” RADIUS authentication mode, a correct OTP is not required, as this authentication request is sent to trigger a push authentication request on the user's smartphone / authenticator PC (for this login and service). As the OTP is incorrect, RADIUS authentication will wait for user acceptance. As such, the RADIUS authentication configuration should match the duration of the push authentication request for this user, which is 60 seconds.

Some appliances can met with troubles in "push" authentication mode as they do not accept custom RADIUS timeout configuration.

“Push” RADIUS authentication mode

In this case, the "Push" RADIUS authentication mode is selected.

When our platform receives a RADIUS authentication request and the password is incorrect (not a valid OTP) for this TrustBuilder connection:

• This request will be put on hold and a Push authentication request is sent to the TrustBuilder Authenticator application for this TrustBuilder login (mobile or desktop).

• Upon receipt of this push authentication request, the user must respond (accept or decline) on their mobile phone or on their Windows desktop application.

• When validating this authentication request on their Authenticator application, an OTP will be generated and transferred to complete the initial authentication request.

• A RADIUS Access-Accept response will be returned to this RADIUS client authentication request.

“Push” RADIUS configuration

The push authentication trigger a 60 seconds push authentication on the user's smartphone/activated device, however we often we see a “UDP idle timeout” that drop automatically UDP packets at 30s. To reach a 60 seconds authentication time, the request have to be retried before this 30s limit or the RADIUS answer won’t be accepted.

Recommendations

You can select one of this recommended configuration timeout/ retries for this RADIUS configuration

• Timeout (seconds) : 28s and Retries : 2

• Timeout (seconds) : 20s and Retries : 3

Compared the previous TrustBuilder infrastructure, there is no need to distribute the load on your side. The endpoints radius-a and radius-b will automatically distribute the load internally.

“Standard” RADIUS authentication mode

In standard RADIUS configuration, the RADIUS is awaiting a login with a correct OTP in the authentication request from the beginning. The OTP generated before the authentication request)

As such the OTP should be generated prior to the RADIUS request attempt, (in a customized logon page / see next chapter)

As we often we see a “UDP idle timeout” that drop automatically UDP packets at 30s, we propose the following RADIUS authentication time configuration.

“Standard” RADIUS configuration

The Radius Authentication time (global response time), including retries, must be less than the duration of the OTP.

• With an invalid OTP, (Outdated or wrong) all authentication requests will be systematically refused with a direct “access-reject” with a RADIUS connector (Legacy)

• With a “Push” RADIUS connector an invalid OTP will be considered as a PUSH authentication but the timeout can be too short

• Radius Authentication time : the global response time = (Server timeout period*(Retries+1)

• Radius Authentication time < 28 sec. OTP duration (standard RADIUS authentication times on Firewall are around 3s-10s)

Recommendation

If you are using a standard radius mode (without push), with a server pair:

• the OTP is sent in the request, so we recommend configuring a "Server timeout period" of 15 to 20 seconds to enable validation of the authentication request by the Secondary server before the OTP expires.

Logon page customization solutions for generating an OTP in standard mode

If your Appliance or authentication server allows logon page HTML customization, for VPN or Web accesses, you can decide to use our browser token to generate OTPs,

• Please refer to Virtual Authenticator integration and send a RADIUS request to validate the OTP with our platform.

• You can also find Third parties / specific Appliance configuration (Pulse, Citrix, Palo Alto, F5,…) in our Vendor specific integration section.

Accepted OTP / password format

When testing the RADIUS access please be sure to format the password correctly:

Regular expression: /^[a-zA-Z0-9]+$/ 

• lowercase: a to z

• uppercase: A to Z

• Digits: 0 to 9

In addition, any string longer than 8 characters won’t be considered as an OTP and will be automatically rejected.

Monitoring Radius services

Failover

inWebo offers 2 Radius endpoints: radius-a.myinwebo.com and radius-b.myinwebo.com. These 2 endpoints are loadbalancing Radius queries to the same pool of Radius servers but they are accessible through 2 different network routing paths.

Client should choose radius-a.myinwebo.com as primary access. The failover on radius-b.myinwebo.com must be done if any of the following:

• radius-a.myinwebo.com is not responding to ICMP queries

• radius-a.myinwebo.com is on Radius timeout. This can be detected by:

  • sending wrong authentication request on a regular basis (every few minutes) and checking the service is responding “Access-Reject”

  • monitoring the service response on real user authentication requests

Detecting Radius service unavailability

TrustBuilder offers a very high level of availability, public TrustBuilder Radius endpoints are loadbalancing queries on several internal servers that are independant from eachover and located in different datacenters.

However, you need for business continuity reasons to monitor the availability of TrustBuilder Radius services. The inner nature of the TrustBuilder technology (providing dynamic tokens that are tied to physical devices) makes it very hard to automatically test valid authentications, therefore we recommend the following methods:

1. TrustBuilder StatusPage contains all information about potential incidents on our services. There is a Radius component that is triggered as not operational in case of an incident on our Radius endpoints.

   1. You can either go on the TrustBuilder StatusPage and subscribe to incidents via various means depending on your need (Slack, email, webhook..).

   2. Or monitor the status page API on a regular basis for incident information, see https://status.inwebo.com/api for details.

2. Access-Reject / Access-Accept rate - we recommend to our clients to monitor the Radius authentication success rate. This is the best way to actually cover any potential issue in the integration with TrustBuilder. Depending on the complexity of the integration, the type of the Radius connector that you use and the traffic, you will have to adapt the alerting threshold.

Troubleshooting

We encourage tests with RADIUS application (NTRadPing, RadTest…) to verify your RADIUS connection and your authentication portal as to verify the response time and redundancy measures when you don’t answer to the initial authentication in RADIUS push.

Support and legacy addresses migration

If you have any doubts about your radius configuration or robustness, do not hesitate to contact the TrustBuilder support team support@inwebo.com .

Legacy addresses and pair configuration (for record tracking)

The legacy addresses are provided to follow previous TrustBuilder configurations.
If you are using these legacy addresses, we strongly recommend that you upgrade to the new configuration to improve your resiliency, or contact our support for more assistance.

Please refer to Infrastructure - IP Addresses documentation.