...
Overview
The
is configurable using CLI and EMA interfaces, and the access to these interfaces are authenticated using the user credentials. User credentials can be verified using local or external authentication. For local authentication, the user credentials are validated against locally stored user database and for external authentication, the user credentials are sent to an remote RADIUS server and authenticated
.Since 3.1 release,
platforms have included the ability to configure one remote server per for the purpose of authenticating users from this server using Remote Authentication Dial In User Service (RADIUS) protocol.
The username and encrypted password are sent to the remote RADIUS server in an ACCESS_REQUEST packet. The user is allowed/denied access to the based on the response from the RADIUS server. users are currently segregated into the following groups which define the privileges of each user. Access to data/commands is allowed/prevented based on the group of the user who is trying to acquire the access.
- Administrator
- Operator
- FieldService
- Guest
- SecurityAuditor
- Calea
Since the RADIUS protocol does not provide a means to assign users to a group, the implementation currently hard codes every RADIUS authenticated user to the Administrator group.
The
is enhanced in this release with the following RADIUS authentication improvements:- Obtain Correct Privileges via RADIUS Transaction – When a user is authenticated using RADIUS, the correct privilege is obtained via RADIUS transaction itself using a Vendor Specific Attribute (VSA).
- Configure Multiple RADIUS Servers – Up to three RADIUS servers are now configurable per .
To configure RADIUS authentication for
, you must first enable external authentication and then configure the remote
RADIUS server.Obtain Correct Privileges via RADIUS TransactionWhen a user is authenticated via RADIUS, the user is assigned to a group provided by the RADIUS server as part of the ACCESS_ACCEPT packet.
Note |
---|
If EMS is used for RADIUS authentication, the group information is passed in a VSA message as plain text after the vendor ID. The string start with "Sonus-Groups". No Vendor-specific formatting is used by EMS. |
For SBC RADIUS authentication, RADIUS server is configured to return the group name using a VSA in ACCESS_ACCEPT packet. The VSA should be in the following format.
Code Block |
---|
|
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
The Vendor-Id is a SMI Network Management Private Enterprise Code of the vendor Sonus as specified in RFC 2865.
- Vendor ID for Sonus is "2879".
- Vendor type can be "1" considering this is the first instance of using VSAs. Type "1" can be the identifier for a group name from server.
- Vendor length is the length of the group name itself. This is followed by a string consisting of a case-sensitive group name.
If the RADIUS server does not provide a group or provides a group name which is not present in the SBC in the ACCESS_ACCEPT response, the user is denied access, and a log is written to the SECURITY event log stipulating that SBC received an invalid group name from the RADIUS server.
Anchor |
---|
| multiple servers |
---|
| multiple servers |
---|
|
Configure Multiple RADIUS ServersThe SBC is enhanced in this release to configure up to three RADIUS servers per SBC with the addition of radiusServer
and retryCriteria
parameters to radiusAuthentication
configuration object.
When more than one RADIUS server is configured and RADIUS authentication is attempted, the server configured with the least priority value is tried first. If fallback is configured, the inverse priority order is followed to pick the next server for authentication. SBC allows a configurable number of retries and time-outs before retry.
Once the SBC sends an ACCESS_REQUEST, it waits until a configured amount of time (retryTimer
) before resending the ACCESS_REQUEST. After a configurable number of failed attempts (retryCount
), the RADIUS server is marked as unavailable, or out of service (OOS) for a configured amount of time (oosDuration
), and the SBC moves to the next configured RADIUS server based on the configured priority. Once all RADIUS servers are attempted and deemed unreachable (or no responses are received), the SBC falls back to Local Authentication (if Local Authentication is enabled).
Note |
---|
An administrator can manually return an OOS RADIUS server back into service by setting radiusServer state flag first to disabled , and then back to enabled setting. |
SBC includes statistics to check the status of a RADIUS server, as well as the time when an unavailable server automatically becomes available again. See CLI Statistics for details.
Enabling Remote Authentication
...
To configure the remote RADIUS Server:
- Login Log on to SBC CLI.
Change to the Configuration mode:
Code Block |
---|
|
> configure private |
Execute the following command:
Code Block |
---|
|
% set oam radiusAuthentication
radiusServer <server name>
mgmtInterfaceGroup <string>
priority radiusServerIp <serverIP> radiusSharedSecret <shared_secret> radiusNasIp <nas IP> radiusServerPort <radius_server_port><#>
radiusNasIp <x.x.x.x>
radiusServerIp <x.x.x.x>
radiusServerPort <#>
radiusSharedSecret <8-128>
state <disabled | enabled>
retryCriteria
oosDuration <# minutes>
retryCount <#>
retryTimer <# milliseconds> |