Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RADIUS Authentication

Junos OS supports RADIUS for central authentication of users on network devices. To use RADIUS authentication on the device, you (the network administrator) must configure information about one or more RADIUS servers on the network. You can also configure RADIUS accounting on the device to collect statistical data about the users logging in to or out of a LAN and send the data to a RADIUS accounting server.

Configure RADIUS Server Authentication

RADIUS authentication is a method of authenticating users who attempt to access a network device. The following sections describe why you would use RADIUS and how to configure it.

Why Use RADIUS

You (the network administrator) can use different protocols for the central authentication of users on network devices including RADIUS and TACACS+. We recommend RADIUS because it is a multivendor IETF standard and its features are more widely accepted than those of TACACS+ or other proprietary systems. In addition, we recommend using a one-time-password system for increased security, and all vendors of these systems support RADIUS.

You should use RADIUS when your priorities are interoperability and performance:

  • Interoperability—RADIUS is more interoperable than TACACS+, primarily because of the proprietary nature of TACACS+. While TACACS+ supports more protocols, RADIUS is universally supported.

  • Performance—RADIUS is much lighter on your routers and switches. For this reason, network engineers generally prefer RADIUS over TACACS+.

Configure RADIUS Server Details

To use RADIUS authentication on the device, configure information about one or more RADIUS servers on the network by including one radius-server statement at the [edit system] hierarchy level for each RADIUS server. The device queries the RADIUS servers in the order in which they are configured. If the primary server (the first one configured) is unavailable, the device attempts to contact each server in the list until it receives a response.

The network device can map RADIUS-authenticated users to a locally defined user account or user template account, which determines authorization. By default, Junos OS assigns RADIUS-authenticated users to the user template account remote, if configured, when:

  • The authenticated user does not have a user account configured on the local device.

  • The RADIUS server either does not assign the user to a local user template, or the template that the server assigns is not configured on the local device.

The RADIUS server can assign an authenticated user to a different user template to grant different administrative permissions to that user. The user retains the same login name in the CLI but inherits the login class, access privileges, and effective user ID from the assigned template. If the RADIUS-authenticated user does not map to any locally defined user account or user template, and the remote template is not configured, then authentication fails.

Note:

The remote username is a special case in Junos OS and must always be lowercase. It acts as a template for users who are authenticated by a remote server but do not have a locally configured user account on the device. Junos OS applies the permissions of the remote template to those authenticated users without a locally defined account. All users mapped to the remote template are in the same login class.

Because you configure remote authentication on multiple devices, it is common to configure it inside of a configuration group. The steps shown here are in a configuration group called global. Using a configuration group is optional.

To configure authentication by a RADIUS server:

  1. Configure the IPv4 address or the IPv6 address of the RADIUS authentication server.

    For example:

  2. (Optional) Configure the packet source address for requests sent to the RADIUS server.

    For example:

    The source address is a valid IPv4 address or IPv6 address configured on one of the router interfaces or switch interfaces. If the network device has several interfaces that can reach the RADIUS server, assign an IP address that the device can use for all its communication with the RADIUS server. Doing this sets a fixed address as the source address for locally generated IP packets.

  3. Configure the shared secret password that the network device uses to authenticate with the RADIUS server.

    The configured password must match the password that is configured on the RADIUS server. If the password contains spaces, enclose it in quotation marks. The device stores the password as an encrypted value in the configuration database.

    For example:

  4. (Optional) Specify the port on which to contact the RADIUS server, if different from the default.

    The default port is 1812 (as specified in RFC 2865).

    For example:

    Note:

    You can also configure the accounting-port statement to specify to which RADIUS server port to send accounting packets. The default is 1813 (as specified in RFC 2866).

  5. (Optional) Configure the number of times that the device attempts to contact the RADIUS server and the amount of time that the device waits to receive a response from the server.

    By default, the device attempts to contact the server three times and waits three seconds. You can configure the retry value from 1 through 100 times and the timeout value from 1 through 1000 seconds.

    For example, to contact a RADIUS server 2 times and wait 10 seconds for a response:

  6. Specify the authentication order, and include the radius option.

    In the following example, whenever a user attempts to log in, Junos OS first queries the RADIUS server for authentication. If that fails, it queries the TACACS+ server. If that fails, it attempts authentication with locally configured user accounts.

  7. Assign a login class to RADIUS-authenticated users who do not have a locally defined user account.

    You configure a user template account in the same way as a local user account, except that you do not configure a local authentication password because the RADIUS server authenticates the user.

    • To use the same permissions for all RADIUS-authenticated users, configure the remote user template.

      For example:

    • To use different login classes for different RADIUS-authenticated users, granting them different permissions:

      1. Create multiple user templates in the Junos OS configuration. For example:

      2. Configure the RADIUS server to map the authenticated user to the appropriate user template.

        Set the Juniper-Local-User-Name Juniper VSA (vendor-specific attribute) (Vendor 2636, type 1, string) to the name of a user template configured on the device, which in the previous example is RO, OP, or SU. The RADIUS server includes the attribute in the RADIUS Access-Accept message. Authentication fails if the device cannot assign a user to a local user account or user template, and the remote user template is not configured.

Configure RADIUS to Use the Management Instance

By default, Junos OS routes authentication, authorization, and accounting packets for RADIUS through the default routing instance. You can also route RADIUS packets through a management interface in a non-default VRF instance.

To route RADIUS packets through the mgmt_junos management instance:

  1. Enable the mgmt_junos management instance.

  2. Configure the routing-instance mgmt_junos statement for the RADIUS authentication server and the RADIUS accounting server, if configured.

Example: Configure a RADIUS Server for System Authentication

This example configures system authentication through a RADIUS server.

Requirements

Before you begin:

  • Perform the initial device configuration. See the Getting Started Guide for your device.

  • Set up at least one RADIUS server on your network.

Overview

In this example, you add a new RADIUS server with an IP address of 172.16.98.1. You specify the shared secret password of the RADIUS server as Radiussecret1. The device stores the secret in the configuration database as an encrypted value. Finally, you specify the source address that the device uses in RADIUS server requests. In most cases, you can use the loopback address of the device, which in this example is 10.0.0.1.

You can configure support for multiple user authentication methods, such as local password authentication, RADIUS, and TACACS+, on the network device, When you configure multiple authentication methods, you can prioritize the order in which the device tries the different methods. In this example, you configure the device to use RADIUS authentication services first and then, if that fails, to attempt local password authentication.

A RADIUS-authenticated user must map to a local user account or a local user template account on the network device, which determines authorization. By default, if a RADIUS-authenticated user does not map to a local user account or a specific user template, the user is assigned to the remote user template, if configured. This example configures the remote user template.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure a RADIUS server for system authentication:

  1. Add a new RADIUS server and set its IP address.

  2. Specify the shared secret (password) of the RADIUS server.

  3. Specify the device’s loopback address as the source address.

  4. Specify the device's order of authentication, and include the radius option.

  5. Configure the remote user template and its login class.
Results

In configuration mode, confirm your configuration by entering the show system command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

The following output includes only those portions of the configuration hierarchy that are relevant to this example.

After configuring the device, enter commit in configuration mode.

Verification

Confirm that the configuration is working properly.

Verify the RADIUS Server Configuration

Purpose

Verify that the RADIUS server authenticates users.

Action

Log in to the network device, and verify that the login is successful. To verify that the device uses the RADIUS server for authentication, you can attempt to log in with an account that does not define a local authentication password in the configuration.

Configure RADIUS Authentication (QFX Series or OCX Series)

RADIUS authentication is a method of authenticating users who attempt to access the router or switch. Tasks to configure RADIUS authentication are:

Note:

The source-address statement is not supported at [edit system-radius-server name] hierarchy level on the QFabric system.

Configure RADIUS Server Details

To use RADIUS authentication on the router or switch, configure information about one or more RADIUS servers on the network by including one radius-server statement at the [edit system] hierarchy level for each RADIUS server:

server-address is the address of the RADIUS server.

You can specify a port on which to contact the RADIUS server. By default, port number 1812 is used (as specified in RFC 2865). You can also specify an accounting port to send accounting packets. The default is 1813 (as specified in RFC 2866).

You must specify a password in the secret password statement. If the password contains spaces, enclose it in quotation marks. The secret used by the local router or switch must match that used by the server.

Optionally, you can specify the amount of time that the local router or switch waits to receive a response from a RADIUS server (in the timeout statement) and the number of times that the router or switch attempts to contact a RADIUS authentication server (in the retry statement). By default, the router or switch waits 3 seconds. You can configure this to be a value from 1 through 90 seconds. By default, the router or switch retries connecting to the server three times. You can configure this to be a value from 1 through 10 times.

You can use the source-address statement to specify a logical address for individual servers or multiple RADIUS servers.

To configure multiple RADIUS servers, include multiple radius-server statements.

To configure a set of users that share a single account for authorization purposes, you create a template user. To do this, include the user statement at the [edit system login] hierarchy level, as described in Example: Configure Authentication Order.

You can also configure RADIUS authentication at the [edit access] and [edit access profile] hierarchy levels. Junos OS uses the following search order to determine which set of servers is used for authentication:

  1. [edit access profile profile-name radius-server server-address]

  2. [edit access radius-server server-address]

  3. [edit system radius-server server-address]

Configure MS-CHAPv2 for Password-Change Support

Before you configure MS-CHAPv2 for password-change support, ensure that you:

  • Configure the RADIUS server authentication parameters.

  • Set the authentication-order to use the RADIUS server for the initial password attempt.

You can configure the Microsoft implementation of the Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) on the router or switch to support changing of passwords. This feature provides users accessing a router or switch the option of changing the password when the password expires, is reset, or is configured to be changed at the next login.

To configure MS-CHAP-v2, include the following statements at the [edit system radius-options] hierarchy level:

The following example shows statements for configuring the MS-CHAPv2 password protocol, password authentication order, and user accounts:

Specify a Source Address for the Junos OS to Access External RADIUS Servers

You can specify which source address Junos OS uses when accessing your network to contact an external RADIUS server for authentication. You can also specify which source address Junos OS uses when contacting a RADIUS server for sending accounting information.

To specify a source address for a RADIUS server, include the source-address statement at the [edit system radius-server server-address] hierarchy level:

source-address is a valid IP address configured on one of the router interfaces or switch interfaces.

Juniper Networks Vendor-Specific RADIUS and LDAP Attributes

Junos OS supports configuring Juniper Networks RADIUS and LDAP vendor-specific attributes (VSAs) on the authentication server. These VSAs are encapsulated in a RADIUS or LDAP vendor-specific attribute with the vendor ID set to the Juniper Networks ID number, 2636.

Table 1 lists the Juniper Networks VSAs that you can configure.

Some of the attributes accept extended regular expressions, as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. For more information, see:

Table 1: Juniper Networks Vendor-Specific RADIUS and LDAP Attributes

Name

Description

Type

Length

String

Juniper-Local-User-Name

Indicates the name of the user template assigned to this user when the user logs in to a device. This attribute is used only in Access-Accept packets.

1

≥3

One or more octets containing printable ASCII characters.

Juniper-Allow-Commands

Contains an extended regular expression that enables the user to run commands in addition to those commands authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

2

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

Juniper-Deny-Commands

Contains an extended regular expression that denies the user permission to run commands authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

3

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

Juniper-Allow-Configuration

Contains an extended regular expression that enables the user to view and modify configuration statements in addition to those statements authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

4

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

Juniper-Deny-Configuration

Contains an extended regular expression that denies the user permission to view or modify configuration statements authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

5

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

Juniper-Interactive-Command

Indicates the interactive command entered by the user. This attribute is used only in Accounting-Request packets.

8

≥3

One or more octets containing printable ASCII characters.

Juniper-Configuration-Change

Indicates the interactive command that results in a configuration (database) change. This attribute is used only in Accounting-Request packets.

9

≥3

One or more octets containing printable ASCII characters.

Juniper-User-Permissions

Contains information the server uses to specify user permissions. This attribute is used only in Access-Accept packets.

Note:

When the RADIUS or LDAP server defines the Juniper-User-Permissions attribute to grant the maintenance permission or all permission to a user, the user’s list of group memberships does not automatically include the UNIX wheel group. Some operations such as running the su root command from a local shell require wheel group membership permissions. However, when the network device defines a local user account with the permissions maintenance or all, the user is automatically granted membership to the UNIX wheel group. Therefore, we recommend that you create a user template account with the required permissions and associate individual user accounts with the user template account.

10

≥3

One or more octets containing printable ASCII characters.

The string is a list of permission flags separated by a space. The exact name of each flag must be specified in its entirety.

See Access Privilege Levels Overview.

Juniper-Authentication-Type

Indicates the authentication method (local database, LDAP or RADIUS server) used to authenticate a user. If the user is authenticated using a local database, the attribute value shows 'local'. If the user is authenticated using a RADIUS or LDAP server, the attribute value shows 'remote'.

11

≥5

One or more octets containing printable ASCII characters.

Juniper-Session-Port

Indicates the source port number of the established session.

12

size of integer

Integer

Juniper-Allow-Configuration-Regexps
(RADIUS only)

Contains an extended regular expression that enables the user to view and modify configuration statements in addition to those statements authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

13

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

Juniper-Deny-Configuration-Regexps
(RADIUS only)

Contains an extended regular expression that denies the user permission to view or modify configuration statements authorized by the user’s login class permission bits. This attribute is used only in Access-Accept packets.

14

≥3

One or more octets containing printable ASCII characters, in the form of an extended regular expression.

For more information about the VSAs, see RFC 2138, Remote Authentication Dial In User Service (RADIUS).

Use Regular Expressions on a RADIUS or TACACS+ Server to Allow or Deny Commands

Junos OS can map RADIUS- and TACACS+-authenticated users to a locally defined user account or user template account, which defines the user's access privileges. You can also optionally configure a user's access privileges by defining Juniper Networks RADIUS and TACACS+ vendor-specific attributes (VSAs) on the respective authentication server.

A user's login class defines the set of permissions that determines which operational mode and configuration mode commands a user is authorized to execute and which areas of the configuration a user can view and modify. A login class can also define regular expressions that allow or deny a user the ability to execute certain commands or view and modify certain areas of the configuration, in addition to what the permission flags authorize. A login class can include the following statements to define user authorization:

  • permissions

  • allow-commands

  • allow-commands-regexps

  • allow-configuration

  • allow-configuration-regexps

  • deny-commands

  • deny-commands-regexps

  • deny-configuration

  • deny-configuration-regexps

Similarly, a RADIUS or TACACS+ server configuration can use Juniper Networks VSAs to define specific permissions or regular expressions that determine a user's access privileges. For the list of supported RADIUS and TACACS+ VSAs, see the following:

You can define user permissions on the RADIUS or TACACS+ server as a list of space-separated values.

  • A RADIUS server uses the following attribute and syntax:

    For example:

  • A TACACS+ server uses the following attribute and syntax:

    For example:

A RADIUS or TACACS+ server can also define Juniper Networks VSAs that use a single extended regular expression (as defined in POSIX 1003.2) to allow or deny a user the ability to execute certain commands or view and modify areas of the configuration. You enclose multiple commands or configuration hierarchies in parentheses and separate them using a pipe symbol. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. When you configure authorization parameters both locally and remotely, the device merges the regular expressions received during TACACS+ or RADIUS authorization with any regular expressions defined on the local device.

  • A RADIUS server uses the following attributes and syntax:

    For example:

  • A TACACS+ server uses the following attributes and syntax:

    For example:

RADIUS and TACACS+ servers also support configuring attributes that correspond to the same *-regexps statements that you can configure on the local device. The *-regexps TACACS+ attributes and the *-Regexps RADIUS attributes use the same regular expression syntax as the previous attributes, but they enable you to configure regular expressions with variables.

  • A RADIUS server uses the following attributes and syntax:

  • A TACACS+ server uses the following attributes and syntax:

    For example, the TACACS+ server configuration might define the following attributes:

On a RADIUS or TACACS+ server, you can also define the attributes using a simplified syntax where you specify each individual expression on a separate line.

For a RADIUS server, specify the individual regular expressions using the following syntax:

For a TACACS+ server, specify the individual regular expressions using the following syntax:

Note:
  • In the TACACS+ server syntax, numeric values 1 through n must be unique but need not be sequential. For example, the following syntax is valid:

  • The RADIUS or TACACS+ server imposes a limit on the number of individual regular expression lines.

  • When you issue the show cli authorization command, the command output displays the regular expression in a single line, even if you specify each individual expression on a separate line.

Users can verify their class, permissions, and command and configuration authorization by issuing the show cli authorization operational mode command.

Note:

When you configure the authorization parameters both locally on the network device and remotely on the RADIUS or TACACS+ server, the device merges the regular expressions received during TACACS+ or RADIUS authorization with any locally configured regular expressions. If the final expression contains a syntax error, the overall result is an invalid regular expression.

Juniper-Switching-Filter VSA Match Conditions and Actions

Devices support the configuration of RADIUS server attributes specific to Juniper Networks. These attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138, Remote Authentication Dial In User Service (RADIUS).

Through VSAs, you can configure port-filtering attributes on the RADIUS server. VSAs are cleartext fields sent from the RADIUS server to the device as a result of authentication success or failure. Authentication prevents unauthorized user access by blocking a supplicant at the port until the device is authenticated by the RADIUS server. The VSA attributes are interpreted by the device during authentication, and the device takes appropriate actions. Implementing port-filtering attributes with authentication on the RADIUS server provides a central location for controlling LAN access for supplicants.

These port-filtering attributes specific to Juniper Networks are encapsulated in a RADIUS-server VSA with the vendor ID set to the Juniper Networks ID number, 2636.

As well as configuring port-filtering attributes through VSAs, you can apply a previously configured port firewall filter directly to the RADIUS server. Like port-filtering attributes, the filter is applied during the authentication process, and its actions are applied at the device port. Adding a port firewall filter to a RADIUS server eliminates the need to add the filter to multiple ports and devices.

The Juniper-Switching-Filter VSA works in conjunction with 802.1X authentication to centrally control access of supplicants to the network. You can use this VSA to configure filters on the RADIUS server. These filters are sent to the switch and applied to users that have been authenticated using 802.1X authentication.

The Juniper-Switching-Filter VSA can contain one or more filter terms. Filter terms are configured using one or more match conditions with a resulting action. Match conditions are the criteria that a packet must meet for a configured action to be applied on it. The configured action is the action that the switch takes if a packet meets the criteria specified in the match conditions. The action that the switch can take is to either accept or deny a packet.

The following guidelines apply when you specify match conditions and actions for VSAs:

  • Both the match statement and the action statement are mandatory.

  • If no match condition is specified, any packet is considered a match by default.

  • If no action is specified, the default action is to deny the packet.

  • Any or all options can be included in each match and action statement.

  • The AND operation is performed on fields that are of a different type, separated by commas. Fields of the same type cannot be repeated.

  • For the forwarding-class option to be applied, the forwarding class must be configured on the switch. If the forwarding class is not configured on the switch, this option is ignored.

Table 2 describes the match conditions that you can specify when you configure a VSA attribute as a firewall filter by using the match command on the RADIUS server. The string that defines a match condition is called a match statement.

Table 2: Match Conditions

Option

Description

destination-mac mac-address

Destination media access control (MAC) address of the packet.

source-dot1q-tag tag

Tag value in the 802.1Q header, in the range 0 through 4095.

destination-ip ip-address

Address of the final destination node.

ip-protocol protocol-id

IPv4 protocol value. In place of the numeric value, you can specify one of the following text synonyms:

ah, egp (8), esp (50, gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6), or udp (17)

source-port port

TCP or User Datagram Protocol (UDP) source port field. Normally, you specify this match statement in conjunction with the ip-protocol match statement to determine which protocol is being used on the port. In place of the numeric field, you can specify one of the text options listed under destination-port.

destination-port port

TCP or UDP destination port field. Normally, you specify this match statement in conjunction with the ip-protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed):

afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cvspserver (2401), cmd (514), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), telnet (23), tacacs-ds (65), talk (517), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103), zephyr-hm (2104)

When you define one or more terms that specify the filtering criteria, you also define the action to take if the packet matches all criteria. Table 3 shows the actions that you can specify in a term.

Table 3: Actions for VSAs

Option

Description

(allow | deny)

Accept a packet or discard a packet silently without sending an Internet Control Message Protocol (ICMP) message.

forwarding-class class-of-service

(Optional) Classify the packet in one of the following forwarding classes:

  • assured-forwarding

  • best-effort

  • expedited-forwarding

  • network-control

loss-priority (low | medium | high)

(Optional) Set the packet loss priority (PLP) to low, medium, or high. Specify both the forwarding class and the loss priority.

Understanding RADIUS Accounting

Network devices support IETF RFC 2866, RADIUS Accounting. You can configure RADIUS accounting on a device to collect statistical data about users logging in to or out of a LAN and send the data to a RADIUS accounting server. The statistical data can be used for general network monitoring, analyzing and tracking usage patterns, or billing a user based on the duration of the session or type of services accessed.

To configure RADIUS accounting, specify:

  • One or more RADIUS accounting servers to receive the statistical data from the device

  • The type of accounting data to collect

You can use the same server for both RADIUS accounting and authentication, or you can use separate servers. You can specify a list of RADIUS accounting servers. The device queries the servers in the order in which they are configured. If the primary server (the first one configured) is unavailable, the device attempts to contact each server in the list until it receives a response.

The RADIUS accounting process between the device and a RADIUS server works like this:

  1. A RADIUS accounting server listens for User Datagram Protocol (UDP) packets on a specific port. The default port for RADIUS accounting is 1813.

  2. The device forwards an Accounting-Request packet containing an event record to the accounting server. The event record associated with this supplicant contains an Acct-Status-Type attribute whose value indicates the beginning of user service for this supplicant. When the supplicant’s session ends, the accounting request contains an Acct-Status-Type attribute value indicating the end of user service. The RADIUS accounting server records this as a stop-accounting record containing session information and the length of the session.

  3. The RADIUS accounting server logs these events in a file as start-accounting or stop-accounting records. On FreeRADIUS, the filename is the server’s address, such as 192.0.2.0.

  4. The accounting server sends an Accounting-Response packet to the device confirming that it has received the accounting request.

  5. If the device does not receive an Accounting-Response packet from the server, it continues to send accounting requests until the server returns a response.

You can view the statistics collected through this process on the RADIUS server. To see those statistics, access the log file configured to receive them.

Configure RADIUS System Accounting

When you enable RADIUS accounting, Juniper Networks devices, acting as RADIUS clients, can notify the RADIUS server about user activities such as software logins, configuration changes, and interactive commands. The framework for RADIUS accounting is described in RFC 2866, RADIUS Accounting.

Configure Auditing of User Events on a RADIUS Server

To configure RADIUS accounting:

  1. Configure the events to audit.

    For example:

    events can include one or more of the following:

    • login—Audit logins

    • change-log—Audit configuration changes

    • interactive-commands—Audit interactive commands (any command-line input)

  2. Enable RADIUS accounting.
  3. Configure the address for one or more RADIUS accounting servers.

    For example:

    Note:

    If you do not configure any RADIUS servers at the [edit system accounting destination radius] hierarchy level, the device uses the RADIUS servers configured at the [edit system radius-server] hierarchy level.

  4. (Optional) Configure the source address for RADIUS accounting requests.

    For example:

    The source address is a valid IPv4 address or IPv6 address configured on one of the router interfaces or switch interfaces. If the network device has several interfaces that can reach the RADIUS server, assign an IP address that the device can use for all its communication with the RADIUS server. Doing this sets a fixed address as the source address for locally generated IP packets.

  5. Configure the shared secret password that the network device uses to authenticate with the RADIUS accounting server.

    The configured password must match the password that is configured on the RADIUS server. If the password contains spaces, enclose it in quotation marks. The device stores the password as an encrypted value in the configuration database.

    For example:

  6. (Optional) If necessary, specify to which RADIUS accounting server port to send accounting packets, if different from the default (1813).
    Note:

    If you enable RADIUS accounting at the [edit access profile profile-name accounting-order] hierarchy level, accounting is triggered on the default port of 1813 even if you do not specify a value for the accounting-port statement.

  7. (Optional) Configure the number of times that the device attempts to contact a RADIUS accounting server and the amount of time that the device waits to receive a response from a server.

    By default, the device attempts to contact the server three times and waits three seconds. You can configure the retry value from 1 through 100 times and the timeout value from 1 through 1000 seconds.

    For example, to contact a server 2 times and wait 10 seconds for a response:

  8. (Optional) To route RADIUS accounting packets through the non-default management instance instead of the default routing instance, configure the routing-instance mgmt_junos statement.
  9. (Optional) Configure the enhanced-accounting statement at the [edit system radius-options] hierarchy level to include additional accounting attributes, including access method, remote port, and access privileges, for user login events.
    Note:

    To limit the number of attribute values to audit, configure the enhanced-avs-max <number> statement at the [edit system accounting] hierarchy level.

The following example configures three servers (10.5.5.5, 10.6.6.6, and 10.7.7.7) for RADIUS accounting:

Release History Table
Release
Description
18.1R1
Starting in Junos OS Release 18.1R1, existing RADIUS behavior is enhanced to support a management interface in a non-default VRF instance.