AKCP RADIUS Authentication

AKCPBlog

What is RADIUS Server and how does it relate to AKCP?

RADIUS (Remote Authentication Dial-In User Service) is a standardized client-server networking protocol for passing authentication requests to an identity management system. In this article we will explore RADIUS Server Authentication and it’s use with AKCP base units.

Basically, it’s a set of predefined rules that govern the communication between a device (RADIUS Client) and a user database (RADIUS Server) for authentication.

This is very useful in a diverse network because it is robust and generalized, allowing many different devices from various vendors to communicate authentication with completely unrelated identity management systems that they would ordinarily not work with.

Radius Architecture Diagram

A RADIUS Server is a server or network appliance or device that receives the authentication requests from a RADIUS Client (also called a NAS or Network Access Server), then passes these requests on to the configured identity management system (user/account database). It’s a translator or a proxy that will help network devices to communicate with the identity management system, when they don’t natively use the same protocol (language). 

All RADIUS Servers have AAA capabilities (Authentication, Authorization, and Accounting), offering businesses the ability to preserve the privacy and security of their system and their users, thus helping in centrally managing security.

If a RADIUS Server is used for authentication on all devices in the network, it guarantees that you have control over who can connect with your network.

RADIUS Server Authentication and Authorization

A RADIUS Server can be configured to support a variety of methods to authenticate a user.

The Authentication and Authorization process goes hand in hand and usually starts when a user tries to connect to the RADIUS Client using a username and password.

RADIUS is a very extensible protocol. The RADIUS Server returns authorization information in the Access-Accept response; this way the RADIUS Client (NAS) will be able to know what the user account has rights to do.

It is important to note that RADIUS Server only accepts requests from RADIUS Clients which are using the same configured Shared Secret – if this doesn’t match, any requests to the RADIUS Server will fail.

RADIUS Authentication and Authorization Flow

RADIUS Authentication and Authorization Flow (image source: Wikipedia)

As an overview, a basic RADIUS Authentication and Authorization process include the following steps:

  1. The user initiates authentication to the network access server (NAS), providing the user credentials.
  2. The NAS or RADIUS Client sends the given username and the uniquely encrypted password to the RADIUS Server for verification – this is the Access-Request message.
  3. The RADIUS Server verifies the user credentials against the user database, and accepts or rejects the user.
  4. If there is a match and the user is accepted, the RADIUS Server extracts additional details from the user database for any configured access or privilege policies.
  5. If there is a matching policy, the RADIUS Server sends an Access-Accept message with the Shared Secret back to the device, and the user is allowed access.
  6. The Access-Accept message consists of a string of text, including a Filter ID attribute. This Filter ID can be used to further granulate user access via groups and additional policies.

RADIUS Server Accounting

RADIUS Servers also have accounting (logging) capability for the authentication process.

This data can be collected for network and account monitoring, billing, or statistical purposes.

The RADIUS Client can communicate with the RADIUS Server for example to determine, how long a user may use the service provided by the RADIUS Client.

The accounting process will typically start when the user is granted access through the RADIUS Server.

However, it is possible to use RADIUS Accounting independently of the RADIUS Authentication and Authorization – the accounting service doesn’t even need to be running on the same server or network device as the other RADIUS server roles.

RADIUS Accounting Flow

RADIUS Accounting Flow (image source: Wikipedia)

A basic RADIUS Accounting process typically includes the following steps:

  1. The Accounting process starts when the user is granted access by the RADIUS Server: the RADIUS Client will send a RADIUS Accounting-Request packet known as “Accounting Start”. This request packet contains the user ID, network address, session identifier, and the point of access (NAS name).
  2. During the login session, the Client may send additional Accounting-Request packets known as “Interim Update” to the RADIUS Server. These packets will include details such as the current login session’s duration, NAS name and data usage. This packet generally serves the purpose of periodically updating the information about the user’s session to the RADIUS Server.
  3. Once the user’s access to the RADIUS Server ends and logs off, the RADIUS Client will send another Accounting-Request packet known as “Accounting Stop”, to the RADIUS Server. This packet will include information such as total logged on time, additional data, number of packets transferred, the reason for disconnection, and other information relevant to the user’s session.

Comparison with Microsoft Active Directory 

RADIUS

RADIUS is an older, simpler authentication protocol for passing authentication requests to an identity management system, which was primarily designed to allow network devices (routers, modems, switches doing Network Access Control (NAC), VPN concentrators etc.) to authenticate users. It was not intended for handling complex membership requirements. If a device has network connectivity and is configured with the proper shared secret, the device has all it needs to handle users’ authentication credentials and test against the RADIUS Server. 

Active Directory 

Active Directory is a full-fledged hierarchical identity management directory and offers complex authentication mechanisms, such as LDAP, NTLM, and Kerberos. Valid credentials are required to use resources within Active Directory.

The Active Directory is basically a list of people (and computers) that are allowed to connect to other resources on the network with configured policies, rights and restrictions.

Combining RADIUS and Active Directory 

Usually, RADIUS is used when the used network clients can’t connect to and authenticate with Active Directory. For example, most wireless routers, WLAN controllers, and access points do not natively support authenticating a logon against Active Directory. RADIUS helps by creating a way for the WAPs or WLAN controllers to take the supplied username and password credentials from a user, and pass those through to Active Directory to be authenticated.

This will help to centralize identity management and provide more secure access control to the network.

Another very common combination of RADIUS and Active Directory is for two-factor authentication with One Time Passwords (OTP). For example RSA SecurID, which primarily processes authentication requests via RADIUS.

It’s also possible to install RADIUS for Active Directory to allow clients (like switches, routers, wireless devices) to authenticate AD users via RADIUS, as part of Microsoft’s Network Policy Server.

This setup can be very useful when an organization does not want to expose their LDAP, or whenever a standardized authorization is required.

Cloud identity providers and RADIUS

Many businesses have begun to use online “cloud” identity providers, such as Office 365, G-Suite, Centrify, etc. Because RADIUS is a generic authentication protocol, it will work well with any kind of identity providers, whether they are on-premises such as Microsoft Active Directory, Red Hat Directory Server, or cloud databases such as Jump Cloud or Office 365.

Comparison with Cisco TACACS 

RADIUS

RADIUS is an open standard protocol (Authentication(RFC 2865) and Accounting(RFC 2866)); the most commonly used solution is FreeRADIUS. RADIUS can be used with different vendors’ devices, while TACACS can only be used with Cisco devices. The Authentication and Authorization roles are combined in the RADIUS protocol.

RADIUS also offers more extensive Accounting support than the TACACS protocol.

However, RADIUS doesn’t offer multiprotocol support, uses UDP, and is most commonly used for providing network access via authentication. 

TACACS 

TACACS (Terminal Access Controller Access Control System) is a Cisco proprietary protocol, and the Authentication, Authorization, and Accounting roles are handled separately. It provides more granular control, for example, it is possible to specify the particular command for authorization.

TACACS+ offers multiprotocol support, uses TCP, and is most commonly used for device administration.

All the AAA packets are encrypted in TACACS+ while only the passwords are encrypted in RADIUS – this makes TACACS more secure.

RADIUS implementation on AKCP devices

sensorProbe+

RADIUS is supported on F7 platform units only. Both IPv4 and IPv6 network addressing is supported.

You can define a total of 4 authentication servers, and 4 accounting servers.

There is a fallback logic when a primary server is unreachable, the device will try to reach the other defined servers. If all servers are unreachable, the unit will fall back to using the built-in local user database (Admin/User/Viewer accounts).

Using RADIUS requires a separate license on SP+ devices.

AKCP sensorProbeX+ Radius

Note: To be able to fully manage the unit when RADIUS is enabled, create an account named Admin in the RADIUS user database. This is necessary because, in the current implementation, SP+ units cannot handle RADIUS user groups and will authenticate users as a read-only “User” account only.

securityProbe 

RADIUS is supported on securityProbe. Both IPv4 and IPv6 network addressing is supported.

You can define a total of 2-2 authentication and accounting servers.

There is a fallback logic when a primary server is unreachable, the device will try to reach the other defined servers. If all servers are unreachable, the unit will fall back to using the built-in local user database (Admin/User accounts).

Using RADIUS doesn’t require a separate license on SEC5 units.

AKCP securityProbe5E

Note: To be able to fully manage the unit when RADIUS is enabled, create an account named Admin in the RADIUS user database. This is necessary because, in the current implementation, SEC5 units cannot handle   RADIUS user groups and will authenticate users as read-only. For handling different user privilege levels, the SEC5 unit’s built-in users and groups management have to be configured (covered in a separate manual).

Conclusion

Implementing a RADIUS Server will help to prevent your organization’s private information from being leaked to snooping outsiders.

It allows for easy, centralized user access management, and enables individual users to be assigned unique network permissions.

RADIUS makes it possible to connect to and interface between different identity management systems.

RADIUS can integrate into an existing system without any significant changes; however, usually, it needs a good deal of configuration to work correctly.

 

AKCPAKCP RADIUS Authentication