Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

TACACS+ Authentication

Junos OS Evolved supports TACACS+ for central authentication of users on network devices. To use TACACS+ authentication on the device, you (the network administrator) must configure information about one or more TACACS+ servers on the network. You can also configure TACACS+ 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 TACACS+ accounting server.

Configure TACACS+ Authentication

TACACS+ authentication is a method of authenticating users who attempt to access a network device.

To configure TACACS+, perform the following tasks:

Configure TACACS+ Server Details

To use TACACS+ authentication on the device, configure information about one or more TACACS+ servers on the network by including one tacplus-server statement at the [edit system] hierarchy level for each TACACS+ server. The device queries the TACACS+ 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 TACACS+-authenticated users to a locally defined user account or user template account, which determines authorization. By default, Junos OS Evolved assigns TACACS+-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 TACACS+ 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 TACACS+ 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 TACACS+-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 Evolved 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 Evolved 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 remote authentication is configured on multiple devices, it is commonly configured 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 TACACS+ server:

  1. Configure the IPv4 address or IPv6 address of the TACACS+ authentication server.

    For example:

  2. (Optional) Configure the packet source address for requests sent to the TACACS+ 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 TACACS+ server, assign an IP address that the device can use for all its communication with the TACACS+ 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 TACACS+ server.

    The configured password must match the password that is configured on the TACACS+ 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 TACACS+ server, if different from the default port (49).

    For example:

  5. (Optional) Configure the amount of time that the device waits to receive a response from the TACACS+ server.

    By default, the device waits 3 seconds. You can configure the timeout value from 1 through 90 seconds.

    For example, to wait 15 seconds for a response from the server:

  6. (Optional) Configure the device to maintain one open TCP connection to the server for multiple requests rather than opening a separate connection for each connection attempt.
    Note:

    Early versions of the TACACS+ server do not support the single-connection option. If you specify this option and the server does not support it, the device will be unable to communicate with that TACACS+ server.

  7. (Optional) To route TACACS+ packets through a specific routing instance, configure the routing-instance statement and specify a valid routing instance.

    By default, Junos OS Evolved routes authentication, authorization, and accounting packets for TACACS+ through the default routing instance.

  8. Specify the authentication order, and include the tacplus option.

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

  9. Assign a login class to TACACS+-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 TACACS+ server authenticates the user.

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

      For example:

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

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

      2. Configure the TACACS+ server to map the authenticated user to the appropriate user template.

        For example, set the local-user-name Juniper vendor-specific attribute (VSA) to the name of a user template configured on the device, which in the previous example is RO, OP, or SU. 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 TACACS+ to Use the Management Instance

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

To route TACACS+ packets through the mgmt_junos management instance:

  1. Enable the mgmt_junos management instance.

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

Configure the Same Authentication Service for Multiple TACACS+ Servers

You can configure the same authentication service for multiple TACACS+ servers by including statements at the [edit system tacplus-server] and [edit system tacplus-options] hierarchy levels.

To assign the same authentication service to multiple TACACS+ servers:

  1. Configure the TACACS+ servers as described in Configure TACACS+ Authentication.
  2. Configure the service-name statement at the [edit system tacplus-options] hierarchy level.
    service-name is the name of the authentication service, which by default is junos-exec.

    For example:

The following example shows how to configure the same authentication service for multiple TACACS+ servers:

Configure Juniper Networks Vendor-Specific TACACS+ Attributes

Junos OS Evolved can map TACACS+-authenticated users to a locally defined user account or user template account, which determines authorization. You can also optionally configure a user's access privileges by defining Juniper Networks vendor-specific TACACS+ attributes on the TACACS+ server. You define the attributes in the TACACS+ server configuration file on a per-user basis. The network device retrieves these attributes through an authorization request of the TACACS+ server after authenticating a user.

To specify these attributes, include a service statement of the following form in the TACACS+ server configuration file:

You can define the service statement in a user statement or a group statement.

Configure Periodic Refresh of the TACACS+ Authorization Profile

When you configure a device running Junos OS Evolved to use a TACACS+ server for authentication, the device prompts users for login information, which is verified by the TACACS+ server. After a user is successfully authenticated, the network device sends an authorization request to the TACACS+ server to obtain the authorization profile for the user. Authorization profiles specify the access permissions for authenticated users or devices.

The TACACS+ server sends the authorization profile as part of an authorization REPLY message. The remote user configured on the TACACS+ server is mapped to a local user or user template configured on the device running Junos OS Evolved. Junos OS Evolved combines the user's remote authorization profile and locally configured authorization profile, the latter of which is configured at the [edit system login class] hierarchy level.

By default, the exchange of authorization request and reply messages occurs only once, after successful authentication. You can configure the devices so that Junos OS Evolved periodically fetches the remote authorization profile from the TACACS+ server and refreshes the locally stored authorization profile. This periodic refresh ensures that the local device reflects any change in the authorization parameters without requiring that the user restart the authentication process.

To enable periodic refresh of the authorization profile, you must set the time interval at which the local device checks the authorization profile configured remotely on the TACACS+ server. If the remote authorization profile changes, the device fetches the authorization profile from the TACACS+ server and the authorization profile configured under the login class hierarchy. The device refreshes the authorization profile stored locally by combining the remote and locally configured authorization profiles.

You can configure the refresh time interval locally on the device running Junos OS Evolved or directly on the TACACS+ server. The time interval can range from 15 through 1440 minutes.

  • To configure periodic refresh of the authorization profile on the local device, include the authorization-time-interval statement at the [edit system tacplus-options] hierarchy level, as follows:
  • To configure periodic refresh on the TACACS+ server, add the refresh-time-interval parameter in the authorization profile using the following syntax:

Use the following guidelines to determine which time interval configuration takes precedence:

  • If the refresh time interval is configured only on the TACACS+ server or only on the device running Junos OS Evolved, then the configured value takes effect.
  • If the refresh time interval is configured on both the TACACS+ server and the device running Junos OS Evolved, the value configured on the TACACS+ server takes precedence.

  • If no refresh time interval is configured on either the TACACS+ server or the device running Junos OS Evolved, then no periodic refresh occurs.

  • If the refresh time interval configured on the TACACS+ server is out of range or invalid, the locally configured refresh time interval takes effect. If no refresh time interval is configured locally, then no periodic refresh occurs.

After the periodic refresh time interval is set, if the user changes the refresh interval before the authorization request is sent from the local device, the updated refresh interval takes effect after the next immediate periodic refresh.

Example: Configure a TACACS+ Server for System Authentication

This example configures system authentication through a TACACS+ server.

Requirements

Before you begin:

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

  • Set up at least one TACACS+ server on your network.

Overview

In this example, you add a new TACACS+ server with an IP address of 172.16.98.1. You specify the shared secret password of the TACACS+ server as Tacacssecret1. The device stores the secret in the configuration database as an encrypted value. Finally, you specify the source address that the device uses in TACACS+ 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, TACACS+, and RADIUS, 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 TACACS+ authentication services first and, if that fails, to then attempt local password authentication.

A TACACS+-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 TACACS+-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 in configuration mode.

Step-by-Step Procedure

To configure a TACACS+ server for system authentication:

  1. Add a new TACACS+ server and set its IP address.

  2. Specify the shared secret (password) of the TACACS+ server.

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

  4. Specify the device's order of authentication, and include the tacplus 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 you configure the device, enter commit in configuration mode.

Verification

Confirm that the configuration is working properly.

Verify the TACACS+ Server Configuration

Purpose

Verify that the TACACS+ server authenticates users.

Action

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

Juniper Networks Vendor-Specific TACACS+ Attributes

Junos OS Evolved supports configuring Juniper Networks TACACS+ vendor-specific attributes (VSAs) on the TACACS+ server. Table 1 lists the supported Juniper Networks VSAs.

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 TACACS+ Attributes

Name

Description

Length

String

local-user-name

Indicates the name of the user template assigned to this user when the user logs in to a device.

≥3

One or more octets containing printable ASCII characters.

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.

≥3

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

allow-commands-regexps

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.

≥3

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

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.

≥3

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

allow-configuration-regexps

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.

≥3

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

deny-commands

Contains an extended regular expression that denies the user permission to run commands authorized by the user’s login class permission bits.

≥3

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

deny-commands-regexps

Contains an extended regular expression that denies the user permission to run commands authorized by the user’s login class permission bits.

≥3

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

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.

≥3

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

deny-configuration-regexps

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.

≥3

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

user-permissions

Contains information the server uses to specify user permissions.

Note:

When the TACACS+ server defines the 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.

≥3

One or more octets containing printable ASCII characters.

See Access Privilege Levels Overview.

authentication-type

Indicates the authentication method (local database or TACACS+ 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 TACACS+ server, the attribute value shows 'remote'.

≥5

One or more octets containing printable ASCII characters.

session-port

Indicates the source port number of the established session.

size of integer

Integer

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

Junos OS Evolved 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.

Configuring TACACS+ System Accounting

You can configure TACACS+ accounting on a device to collect statistical data about users logging in to or out of a LAN and send the data to a TACACS+ 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 TACACS+ accounting, specify:

  • One or more TACACS+ 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 TACACS+ accounting and authentication, or you can use separate servers. You can specify a list of TACACS+ 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.

When you enable TACACS+ accounting, Juniper Networks devices, acting as TACACS+ clients, can notify the TACACS+ server about user activities such as software logins, configuration changes, and interactive commands.

Configure TACACS+ Server Accounting

To configure TACACS+ server 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 TACACS+ accounting.
  3. Configure the address for one or more TACACS+ accounting servers.

    For example:

    Note:

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

  4. (Optional) Configure the source address for TACACS+ 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 TACACS+ server, assign an IP address that the device can use for all its communication with the TACACS+ 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 TACACS+ accounting server.

    The configured password must match the password that is configured on the TACACS+ 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 TACACS+ accounting server port to send accounting packets, if different from the default (49).
  7. (Optional) Configure the amount of time that the device waits to receive a response from the TACACS+ accounting server.

    By default, the device waits three seconds. You can configure the timeout value from 1 through 90 seconds.

    For example, to wait 15 seconds for a response from the server:

  8. (Optional) Configure the device to maintain one open TCP connection to the server for multiple requests rather than opening a separate connection for each connection attempt.
    Note:

    Early versions of the TACACS+ server do not support the single-connection option. If you specify this option and the server does not support it, the device will be unable to communicate with that TACACS+ server.

  9. (Optional) To route TACACS+ accounting packets through the non-default management instance or another routing instance instead of the default routing instance, configure the routing-instance statement and specify the routing instance.
    For example:
  10. To ensure that start and stop requests for login events are correctly logged in the TACACS+ server Accounting log file instead of the Administration log file, include either the no-cmd-attribute-value statement or the exclude-cmd-attribute statement at the [edit system tacplus-options] hierarchy level.
    Note:

    Both statements support the correct logging of accounting requests in the Accounting file instead of the Administration file. If you configure the no-cmd-attribute-value statement, the value of the cmd attribute is set to a null string in the start and stop requests. If you configure the exclude-cmd-attribute statement, the cmd attribute is totally excluded from the start and stop requests.