Access via a Radius server

Application of RADIUS

 RADIUS - a program that works with a centralized user database. It is used for authentication (verification of authenticity) and authorization (determining access rights) of users. In our case, it may be used to provide centralized control access to multiple monitoring devices on a network. It may be needed when an individual user configuration on each monitoring device separately, is too time-consuming.

Configuration of Radius in the device's web interface

Configuration is carried out via the device's web interface: "Main menu" >> "Preferences" >> "RADIUS".

Open

To enable user authentication via a Radius server, you need to check the box "Enable", and fill in the following fields:

• Server address - IP address to access the server;

• Server port - server port (usually 1812);

• Server password - the password of the device to access the server.

Then, save the configuration by clicking "Save". The device will automatically reboot and changes will take effect.

Configuring the server using FreeRADIUS as an example 

FreeRADIUS server version 3.0 and higher uses the /etc/freeradius/3.0 directory for configuration files. Older versions may use other directories, like /etc/raddb.

Authentication method - unencrypted authentication (PAP, SPAP).

To configure the Radius server you must install:

1. Vendor glossary (Vendor-Specific Attributes).

2. Set up access (IP address and password) for server clients (monitoring devices). 

3.  Fill in the user list with the appropriate access attributes.

1. Vendor glossary (for example, file "dictionary.local) must be placed in the directory /etc/freeradius/3.0,

dictionary.local

as well as to ensure that the dictionary file is included in the main dictionary (file dictionary):

dictionary

2. The list of server clients is in the file  /etc/freeradius/3.0/clients.conf. The client's record looks like this:

clients.conf

The records indicate an IP address of the client and a password to connect to the server. In our case, clients are the monitoring master units. Password in attribute "secret" should be coordinated with the field "Server password" when you configure the client (see. Above).

a

3. User records are in the file /etc/freeradius/3.0/mods-config/files/authorize and are as follows:

authorize

The entries are:

• user name - in our case username 01;

• Cleartext-Password - user's password, which is SHA-1 hash code entered by a user with a plain text password;

• SRead, SWrite, CRead, CWrite, GRead, GWrite - system access permissions (described below);

• RFU1 и RFU2 - reserved attributes (currently not used).

If the attribute is not used, it must be removed from the records. Leaving the attribute in the following form is not allowed :

RFU2 = ""

because the FreeRADIUS client does not handle this situation correctly.

In this example with the user record, all of the devices which log in through a single FreeRADIUS server will receive the same configuration of user permissions. If you need different user rights on different devices, you need to add checking for the IP address of a logging device.

Such records would look like this:

authorize

Here, when authorizing the user username01 through the device with IP address 192.168.1.88, he will get full access rights to the device (all fields "all"). When authorization under the same username username01 from other devices (all IP addresses except 192.168.1.88), the user will be limited in the rights of recording resources and groups of a device.

Run free radius server by command freeradius -X to view full debug messages.

System access permissions

Each user profile in the system can have access to system resources in a "read-only" or "read-write" mode.

Each resource in the system is compared with its corresponding access ID.

Access control is carried out by means of lists. The list is a text string, which consists of access IDs separated by commas.

Accordingly, in the user profile, there are two types of lists: lists for read access and for write access  (both recording and reading).
The system allows three types of permission lists :

1) Server permission lists:

• SRead — read access list;

• SWrite — write access list;

The list of identifiers of server resources:

• accesskeys — management of iButton access keys and other compatible;

• cameras — management of video cameras;

• canbus — management of CAN bus;

• devvirt — management of virtual devices (timers, PINGs, triggers);

• elements — management of elements;

• groups — group management;

• gsm — management of GSM-modem;

• languages — management of installed localization files;

• log — management of system log;

• logics — management of logic schemes;

• modules — management of modules;

• notify — management of notifications (mail, trap, SMS);

• relays — Relay management (global functions);

• sdcard — SD card management;

• system — runtime management (OC Linux);

• users — user management;

• view — control the appearance of the web interface.

Do not specify identification users, otherwise, a user without administrative rights may see the records of other users. In addition, the user is logged in through the RADIUS server, and can not edit or delete user accounts stored in the internal memory of the monitoring device.

2) Client permission lists (web interface):

• CRead — read access list;

• CWrite — write access list;

The list of resource identifiers of the client (Web Interface) is formed and is used solely by the client (by web interface) under its logical organization. Now it is not used and should be listed as "all,".

3) Lists of permits for groups of objects:

• GRead — a list of identifiers of groups with read-only access;

• GWrite — a list of identifiers of groups with write-only access;

Lists of permissions for groups consist of group IDs (a positive integer) and are intended to limit the client (web interface) access to the group objects.

The format of these lists - identifiers separated by commas, in this case, there are special control words:

• all — full access to all identifiers implies full administrative access;

• none — access is completely forbidden.

By default, there are no groups in the system, elements, and modules are not in groups, and access to them is possible only with the rights of "all".