What is a RADIUS Server and How is it Integrated?

Published on 25 Feb 2021

· Around 7 minutes to read

When looked at it by definition, RADIUS is one of the application layer protocols that takes its initials from the definition of "Remote Authentication Dial-in User Service". It uses the Network UDP protocol as a communication method. And it uses the Server / Client architecture.

The RADIUS server implements the basic authentication, authorization and accounting transactions received from the user. It simply encrypts the communication with a "Secret" (secret key info). In case of a conflict problem, the communication does not continue.

One of the main uses of RADIUS is deduplication of session processes in network devices. Radius is used to allow login via Active Directory / LDAP servers. RADIUS application protocol support allows managing difficult-to-manage environments with simple configurations.

Note that RADIUS uses ports 1812 and 1813 (some systems 1645 and 1646) on the UDP protocol.

RADIUS Standard Communication Messages

RADIUS Server has a mechanism that can be extended using variables. But here we shouldn't think of a building mechanism that we can stretch as we want. By simplifying RADIUS, we can examine the messages it uses for request and response.

Access-Request (Client)

This is the standard request made by the client to the server. The client requests access to RADIUS. Here, "Access Request" could take a place in our minds as a package definition.

Access-Reject (Server)

First, let's go over the rejection message. The server sends this message when it wants to reject a request. For example, this message is sent when the Username or Password is entered incorrectly. Or, if it does not meet the obligations requested by the server, the same message will be received.

Reply-Message can also be added to this communication package for notification. This message may indicate why this request was denied.

Access-Accept (Server)

When all requests are received, the server returns this message as an answer. Receiving this message, the Client can now accept that all transactions are correct and proceed with the request. At this point, the person is considered to have entered the session information requested correctly.

Access-Challenge (Server)

The server may state that the access request needs another secondary verification. Or, in case of a situation, the user can be notified via the Access-Challenge with Reply-Message.

Access-Challenge message is sent for secondary or multi-factor authentication methods. At this point, the information contained in the Reply-Message is directly displayed to the us

As an example; "Enter your verification code sent to the phone number 5XX XXX XX 45."

Using RADIUS as a Two-Factor or Multi-Factor Authentication Method

RADIUS has many using areas. One of these areas is that it helps us with secondary or multi-factor authentication. At this stage, the RADIUS server offers us a verification mechanism that can be described as active or passive after the primary option (username and password) during the authentication (session).

Let's assume that SSL VPN device is configured over Active Directory / LDAP. All of our primary session requests are handled first by Active Directory / LDAP. When the confirmation from this section (username and password is correct), it shows the option configured as secondary authentication to the user. Of course, we are not talking about an interactive screen here. We are simply talking about a login box that the user faces and can enter the verification code.

The Access-Challenge and Reply-Message that we mentioned in the previous topic are enough for this process, but the server should be informed that it is a continuation of the current request. State feature is used to make this information. RADIUS Server is informed about an existing process.

Using RADIUS with MFA Push Notifications

RADIUS does not have an Event-Driven architecture. Operations such as Push Notifications or MFA over Phone Call require active communication. To give a small example, such an architecture is unfortunately not possible to install using the existing features on RADIUS.

[CLIENT] -> Username and Password are entered. [SERVER] -> Username and Password are sent to the server. [SERVER] -> Please tap on the notification on your phone. [CLIENT] -> Wait until Notification is touched. [SERVER] -> Notice Approved / Rejected, notify CLIENT again. [CLIENT] -> I got the answer, user can login.

At this point the server should inform the client that it has received approval. But, unfortunately, such a notification seems to be only available in active communication. However, it is possible to manipulate this method over the `Timeout, value. At this point, some products (MonoSign is one of these products) can hold the request until it gets an answer, and execute the relevant operations after the response is received. If you wish, let's continue this section by sampling through MonoSign.

Using Radius Server on MonoSign

MonoSign is an Identity and Access Management application hosting RADIUS Server built-in. We can perform all authentication, authorization, role, multi-step authentication (MFA), single sign-on operations with MonoSign.

We first create an application to authenticate with MonoSign via RADIUS Server. We named the application Radius Server at this point.

After creating an application, we need to define an Access Key. After defining it, the system generates two key values produced specifically for the application.

MonoSign-AppId : Key ID
MonoSign-AppKey : Key Value

We will use these values in the Environment Variables section of the application we set up for MonoSign Radius Server.

Our sample environment variables are as follows;

# RANDOM GENERATED SECRET
MONOSIGN_RADIUS_SECRET=beb84da9-dbf5-420b-b86f-e7ed90a50f28
# MONOSIGN API URL
MONOSIGN_RADIUS_API_URL=https://monosign-api.eu.ngrok.io/
# MONOSIGN APPID and APPKEY
MONOSIGN_RADIUS_APPID=19c68120-4ba7-44cf-825d-7b44f4482892
MONOSIGN_RADIUS_APPKEY=91d4b0b1-9385-4079-81cf-da8ee64b9be1
# YOU CAN PROVIDE CUSTOM PORTS IF YOU WANT
MONOSIGN_RADIUS_AUTHENTICATION_PORT=1812
MONOSIGN_RADIUS_ACCOUNTING_PORT=1813

After writing this data, we can now write our RADIUS Server information to any application. For example, let's use these values in Pulse Secure SSL VPN (here you can also use any application that supports RADIUS as an application).

MonoSign provides all of the information here. At this point, we just need to enter this information. Let's do our testing now.

First I choose my method;

Then I enter the requested information;

First, we entered our Username and Password. The account we use here has an MFA definition. The method he chose is "Google Authenticator". Now let's examine the screen that welcomes us after logging in.

If we pay attention, it has appeared in a box where we can write information. In this box, the requested information is written above.

Type your Google Authenticator Token/Code.

Here, if the SMS wanted a token, it would state it. However, we do not see this screen at all in the process that comes for Push Notification. The screen is keeping us waiting and waiting for us to confirm the Push Notification. Then it takes us in directly. The same goes for the Phone Call too.

MonoSign also allows you to confirm your session information from your watch using your smart watch.

How to do It?

With MonoSign, you can quickly connect to RADIUS Server and manage your entire Identity and Access Management (IAM) process. For more detailed information, you can visit https://monosign.com.