Authentication Order for RADIUS TACACS+, and Local Password
Junos OS supports different authentication methods, including local password authentication, RADIUS, and TACACS+, to control access to the network.
When you configure a device to support multiple authentication methods, you can prioritize the order in which the device tries the different methods. This topic discusses how the authentication order works and how to configure it on a device.
Authentication Order Overview
You (the network administrator) can configure the authentication-order
statement to prioritize the order in which Junos OS tries
different authentication methods to verify user access to a router or switch. If you do
not set an authentication order, by default, Junos OS verifies
users based on their configured local passwords.
If the authentication order includes RADIUS or TACACS+ servers, but the servers do not respond to a request, Junos OS always defaults to trying local password authentication as a last resort.
If the authentication order includes RADIUS or TACACS+ servers, but the servers reject the request, the handling of the request is more complicated.
-
If
password
(local password authentication) is included at the end of the authentication order and the remote authentication servers reject the authentication request, the device attempts local password authentication. -
If
password
(local password authentication) is not included in the authentication order and the remote authentication servers reject the authentication request, the request ends with the rejection.
Thus,
the device must include password
as a final authentication order option
for the device to attempt local password authentication in the event that the remote
authentication servers reject the request.
If the authentication order is set to authentication-order password
,
then the device uses only local password authentication.
- Using Remote Authentication
- How to Use Local Password Authentication
- Order of Authentication Attempts
Using Remote Authentication
You can configure Junos OS to be a RADIUS or TACACS+ authentication client (or a combination).
If an authentication method included in the authentication-order
statement is not available, or if the authentication method is available but the
corresponding authentication server returns a reject response, Junos OS tries the next authentication method included in
the authentication-order
statement.
The RADIUS, or TACACS+ server authentication might fail for one or more of the following reasons:
-
The authentication method is configured, but the corresponding authentication servers are not configured. For instance, the RADIUS and TACACS+ authentication methods are included in the
authentication-order
statement, but the corresponding RADIUS or TACACS+ servers are not configured at the respective[edit system radius-server]
and[edit system tacplus-server]
hierarchy levels. -
The authentication server does not respond before the configured timeout value for that server, or before the default timeout, if no timeout is configured.
-
The authentication server is not reachable because of a network problem.
The authentication server might return a reject response for one or both of the following reasons:
-
The user profile of a user accessing a router or switch is not configured on the authentication server.
-
The user enters incorrect logon credentials.
How to Use Local Password Authentication
You can explicitly configure the password
authentication method in
the authentication-order
statement or use this method as a fallback
mechanism when remote authentication servers fail. The password
authentication method consults the local user profiles configured at the
[edit system login]
hierarchy level. Users can log in to a
router or switch using their local username and password in the following
scenarios:
-
The password authentication method (
password
) is explicitly configured as one of the authentication methods in theauthentication-order
statement.In this case, the device tries local password authentication if no previous authentication method accepts the logon credentials. This is true whether the previous authentication methods fail to respond or they return a reject response because of an incorrect username or password.
-
The password authentication method is not explicitly configured as one of the authentication methods in the
authentication-order
statement.In this case, the operating system only tries local password authentication if all configured authentication methods fail to respond. The operating system does not use local password authentication if any configured authentication method returns a reject response because of an incorrect username or password.
Order of Authentication Attempts
Table 1 describes how the authentication-order
statement at the
[edit system]
hierarchy level determines the procedure that
Junos OS uses to authenticate users for access to a device.
Syntax |
Order of Authentication Attempts |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If SSH public keys are configured, SSH user authentication first tries to perform
public key authentication before using the authentication methods configured in
the authentication-order
statement. If you want SSH logins to
use the authentication methods configured in the
authentication-order
statement without first trying to
perform public key authentication, do not configure SSH public keys.
Configure the Authentication Order for RADIUS, TACACS+ and Local Password Authentication
Using the authentication-order
statement, you can prioritize the order
in which Junos OS tries the different authentication methods
when verifying user access to a router or switch. If you do not set an authentication
order, by default, users are verified based on their locally configured passwords.
When configuring a password using plain text and relying on Junos OS to encrypt it, you are still sending the password over the Internet in plain text. Using pre-encrypted passwords is more secure because it means that the plain text of the password never has to be sent over the internet. Also, with passwords, only one user can be assigned to a password at a time.
On the other hand, RADIUS, and TACACS+ encrypt passwords. These authentication methods let you assign a set of users at a time instead of assigning users one by one. But here are how these authentication systems differ:
-
RADIUS uses UDP; TACACS+ uses TCP.
-
RADIUS encrypts only the password during transmission, whereas TACACS+ encrypts the entire session.
-
RADIUS combine authentication (device) and authorization (user), whereas TACACS+ separates authentication, authorization, and accountability.
In short, TACACS+ is more secure than RADIUS. However, RADIUS has better performance and is more interoperable. RADIUS is widely supported, whereas TACACS+ is a Cisco proprietary product and not widely supported outside of Cisco.
You can configure the authentication order based on your system, its restrictions, and your IT policy and operational preferences.
To configure the authentication order, include the
authentication-order
statement at the [edit
system]
hierarchy level.
[edit system] user@host# set authentication-order [authentication-methods ]
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
The following are the possible authentication order entry options:
-
radius
—Verify the user using RADIUS authentication servers. -
tacplus
—Verify the user using TACACS+ authentication servers. -
password
—Verify the user using the username and password configured locally in the authentication statement at the[edit system login user]
hierarchy level.
The Challenge Handshake Authentication Protocol (CHAP) authentication sequence cannot take more than 30 seconds. If it takes longer than 30 seconds to authenticate a client, the authentication is abandoned and a new sequence is initiated.
For example, assume that you configure three RADIUS servers so that the router or switch attempts to contact each server three times. Assume further that, with each retry, the server times out after 3 seconds. In this scenario, the maximum time given to the RADIUS authentication method before CHAP considers it a failure is 27 seconds. If you add more RADIUS servers to this configuration, they might not be contacted because the authentication process might be abandoned before these servers are tried.
Junos OS enforces a limit on the number of standing
authentication server requests that the CHAP authentication can have at one time.
Thus, an authentication server method—RADIUS, for example—might fail to authenticate
a client when this limit is exceeded. If authentication fails, the authentication
sequence is reinitiated by the router or switch until authentication succeeds and
the link is established. However, if the RADIUS servers are unavailable and
additional authentication methods such as tacplus
or
password
are also configured, the next authentication method is
tried.
The following example shows how to configure radius
and
password
authentication:
[edit system] user@switch# set authentication-order [ radius password ]
The following example shows how to insert the tacplus
statement
after the radius
statement:
[edit system] user@switch# insert authentication-order tacplus after radius
The following example shows how to delete the radius
statement from
the authentication order:
[edit system] user@switch# delete authentication-order radius
Example: Configure Authentication Order
This example shows how to configure authentication order for user login.
Requirements
Before you begin, perform the initial device configuration. See the Getting Started Guide for your device.
Overview
You can configure the authentication method order that a device uses to verify user access to the device. For each login attempt, the device tries the authentication methods in the order configured, until the password matches or all authentication methods have been tried. If you do not configure remote authentication, users are verified based on their configured local passwords.
This example configures the device to attempt user authentication with RADIUS authentication services first, then with TACACS+ authentication services, and finally with local password authentication.
When you use local password authentication, you must create a local user account for every user who wants to access the system. However, when you use remote authentication servers, you can create template accounts (for authorization purposes) that a set of users shares. When a user is assigned to a template account, the command-line interface (CLI) username is the login name; however, the user inherits the privileges, file ownership, and effective user ID from the template account.
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.
delete system authentication-order set system authentication-order radius insert system authentication-order tacplus after radius insert system authentication-order password after tacplus
GUI Quick Configuration
Step-by-Step Procedure
To configure authentication order:
-
In the J-Web user interface, select
Configure>System Properties>User Management
. -
Click
Edit
. The Edit User Management dialog box appears. -
Select the
Authentication Method and Order
tab. -
Under Available Methods, select the authentication method the device should use to authenticate users. Use the arrow button to move the item to the Selected Methods list. Available methods include:
-
RADIUS
-
TACACS+
-
Local Password
If you want to use multiple methods to authenticate users, repeat this step to add the other methods to the Selected Methods list.
-
-
Under Selected Methods, use the Up Arrow and Down Arrow to specify the order in which the device should execute the authentication methods.
-
Click
OK
to check your configuration and save it as a candidate configuration. -
After you configure the device, click
Commit Options>Commit
.
Step-by-Step Procedure
To configure authentication order:
-
Delete any existing
authentication-order
statement.[edit] user@host# delete system authentication-order
-
Add RADIUS authentication to the authentication order.
[edit] user@host# set system authentication-order radius
-
Add TACACS+ authentication to the authentication order.
[edit] user@host# insert system authentication-order tacplus after radius
-
Add local password authentication to the authentication order.
[edit] user@host# insert system authentication-order password after tacplus
Results
In configuration mode, confirm your configuration by entering the
show system authentication-order
command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit] user@host# show system authentication-order authentication-order [ radius tacplus password ];
After you configure the device, enter commit
in
configuration mode.
To completely set up RADIUS or TACACS+ authentication, you must configure at least one RADIUS, or TACACS+ server and create user accounts or user template accounts.
-
Configure a RADIUS server. See Example: Configure a RADIUS Server for System Authentication.
-
Configure a TACACS+ server. See Example: Configure a TACACS+ Server for System Authentication.
-
Configure a user. See Example: Configure New User Accounts.
-
Configure template accounts. See Example: Create Template Accounts.
Verification
Confirm that the configuration is working properly.
Verify the Authentication Order Configuration
Purpose
Verify that the device uses the authentication methods in the order configured.
Action
Create a test user that has a different password for each authentication method. Log in to the device using the different passwords. Verify that the device queries subsequent authentication methods when the previous methods reject the password or fail to respond.
Alternatively, in a test environment, you can deactivate the authentication
server configuration or the local user account configuration (or both) to
test each authentication method. For example, to test the TACACS+ server,
you can deactivate the RADIUS server configuration and the user's local
account. However, if you deactivate the user's local account, you must
ensure that the user still maps to a local user template account such as the
remote
user template.
Example: Configure System Authentication for RADIUS, TACACS+, and Password Authentication
The following example shows how to configure system authentication for RADIUS, TACACS+, and password authentication on a device running Junos OS.
In this example, only the user Philip and users authenticated by a
RADIUS server can log in. If a user logs in and is not authenticated by the
RADIUS server, the user is denied access to the router or switch. If the RADIUS server
is not available, the user is authenticated using the password
authentication method and allowed access to the router or switch. For more information
about the password authentication method, see Authentication Order Overview.
When Philip tries to log in to the system, if the RADIUS server authenticates
him, he is given access and privileges for the super-user
class. Local
accounts are not configured for other users. When they log in to the system and the
RADIUS server authenticates them, they are given access using the same user
ID (UID) 9999 and the privileges associated with the operator
class.
[edit] system { authentication-order radius; login { user philip { full-name "Philip"; uid 1001; class super-user; } user remote { full-name "All remote users"; uid 9999; class operator; } } }
For authorization purposes, you can use a template account to create a single account that a set of users can share at the same time. For example, when you create a remote template account, a set of remote users can concurrently share a single UID. For more information about template accounts, see Example: Configure Authentication Order.
When a user logs in to a device, the RADIUS or TACACS+ server uses the user’s
login name for authentication. If the authentication server authenticates the user
successfully and the user is not configured at the [edit system login
user]
hierarchy level, this is the result: The device uses the default
remote template user account for the user, provided a remote template account is
configured at the edit system login user remote
hierarchy level. The
remote template account serves as a default template user account for all users that are
authenticated by the authentication server but lack a locally configured user account on
the device. Such users share the same login class and UID.
To configure an alternate template user, specify the user-name
parameter
returned in the RADIUS authentication response packet. Not all
RADIUS servers allow you to change this parameter. The following shows a sample Junos OS
configuration:
[edit] system { authentication-order radius; login { user philip { full-name "Philip"; uid 1001; class super-user; } user operator { full-name "All operators"; uid 9990; class operator; } user remote { full-name "All remote users"; uid 9999; class read-only; } } }
Assume that your RADIUS server is configured with the following information:
User Philip with password “olympia”
User Alexander with password “bucephalus” and username “operator”
User Darius with password “redhead” and username “operator”
User Roxane with password “athena”
Philip would be given access as a superuser (super-user
) because of having a
unique, local user account. Alexander and Darius share UID 9990 and have access as
operators. Roxane has no template-user override and therefore shares access with all the
other remote users, getting read-only access.