| Home Prev |  InControl 3.19.01 Administration Guide
|
Next |
|---|
InControl RADIUS authentication allows clients to have their login credentials authenticated against an external RADIUS server via the InControl server.
![[Note]](images/note.png) |
Note: The API does not support RADIUS authentication |
|---|---|
|
The InControl API does not support user authentication using RADIUS. |
The following list summarizes the RADIUS authentication setup steps:
Configure a suitable external RADIUS server to authenticate InControl user credentials. This is described in more detail later in this section. The server might be running the Clavister EasyAccess software product and may also provide multi-factor authentication such as using Clavister OneTouch.
Open the InControl server manager interface and configure the RADIUS server to use. This is also described in more detail towards the end of this section.
When a user now opens the InControl client and tries to log in using credentials, InControl will try to authenticate the credentials against the configured RADIUS server.
The following should be noted about RADIUS authentication:
If RADIUS authentication fails, InControl will try to authenticate the entered user credentials against the local user database, but only if local authentication is also enabled in the InControl server management interface.
If RADIUS authentication succeeds, a user with the name RADIUS:<username> is created in the InControl local user database, if it does not exist already. This user can only be deleted if the administrator does it manually. Below is a screenshot of an example listing of the contents of the local user database. In this case, a user with the username erho has logged in and has been authenticated using the configured RADIUS server.
A RADIUS:<username> user has a group membership defined by the RADIUS server. This property, like the others defined by the RADIUS server such as the password, cannot be changed manually through the InControl client.
The RADIUS: prefix on the username indicates that the user was created in the local database through successful RADIUS authentication. It is not possible to manually add a user with the RADIUS: prefix.
The new RADIUS:<username> user can coexist with a non-RADIUS user called just <username>. These should be regarded as two entirely separate users. In fact, it is possible to have one user logged in as RADIUS:<username> and another logged in at the same time as just <username> if the two users have different passwords.
![[Caution]](images/caution.png) |
Caution: Always have one non-RADIUS administrator |
|---|---|
|
If RADIUS authentication is used extensively, do not delete all non-RADIUS administrator users in the local user database. At least one should exist otherwise the administrator could get locked out if RADIUS authentication is not working for some reason. |
Enabling Client RADIUS Authentication in the InControl Server
RADIUS authentication is enabled in InControl by opening the InControl server settings interface, selecting RadiusAuthentication and setting the property EnableRadiusAuthentication to a value of True and entering the other details for communicating with the RADIUS server.
Finally, save the new settings and restart the server.
The following should be noted about the values entered for RADIUS configuration:
The ExplicitLocalAddress can be left empty.
A NasIdentifier must be specified, even if it is not used by the server. If it is not specified, the InControl server will not start.
The RequireMessageAuthenticator setting should remain set to True in order to mitigate the BlastRadius (CVE-2024-3596) exploit (this must also be supported on the server side).
The ServerAddress must be a correctly formatted and valid IPv4 address.
The SharedSecret must match the secret of the RADIUS server.
If, after enabling RADIUS authentication, the InControl server will not run, carefully check all of the RADIUS values entered in the InControl server settings. In addition, check the server log file for messages that may indicate the source of the problem.
The following should be noted when configuring the external RADIUS server itself:The RADIUS server must be configured to send back the group membership for a user and the group should be a group defined in InControl. A user can belong to more than one group in which case the data sent back should be a comma or semicolon separated list of groups. The general use of groups and the predefined groups are discussed in Chapter 20, User Accounts and Groups.
Since group membership is sent, it is necessary to use the Clavister-User-Group vendor specific attribute when configuring the server. The Clavister Vendor ID is 5089 and the Clavister-User-Group is defined as vendor-type 1 with a string value type.
The RADIUS server should support Message Authentication in order to mitigate the BlastRadius (CVE-2024-3596) exploit. It is highly recommended to ensure that the RADIUS server being used supports this option.
The Need to Re-authenticate After Client/Server Communication Loss
Should communication between the InControl client and server be lost then in certain circumstances, a warning will be displayed that the user is longer authenticated. Following the warning, the user will have to re-authenticate. This might happen if, for example, the RADIUS server authenticated using Clavister OneTouch. It could also happen if the password has changed since the original authentication.