User Authentication Overview
Junos OS supports different authentication methods that you (the network administrator) use to control user access to the network. These methods include local password authentication, RADIUS, and TACACS+. You use one of these authentication methods to validate users and devices that attempt to access the router or switch using SSH and Telnet. Authentication prevents unauthorized devices and users from gaining access to your LAN.
User Authentication Methods
Junos OS supports three methods of user authentication: local password authentication, RADIUS and TACACS+.
With local password authentication, you configure a password for each user allowed to log in to the router or switch.
RADIUS and TACACS+ are authentication methods for validating users who attempt to access the router or switch using any of the login methods. They are distributed client/server systems—the RADIUS and TACACS+ clients run on the router or switch, and the server runs on a remote network system.
You can configure the router or switch to be a RADIUS, or TACACS+ client, or a combination. You can also configure authentication passwords in the Junos OS configuration file. You can prioritize the methods to configure the order in which the software tries the different authentication methods when verifying user access.
Configure Local User Template Accounts for User Authentication
You use local user template accounts to assign different login classes, and thus grant different permissions, to users who are authenticated through a remote authentication server. Each template can define a different set of permissions appropriate for the users assigned to that template. You define the templates locally on the router or switch, and the TACACS+ and RADIUS authentication servers reference the templates. When an authenticated user is assigned to a template account, the CLI username is the login name, but the user inherits privileges, file ownership, and effective user ID from the template account.
When you configure local user templates and a user logs in, Junos OS
issues a request to the authentication server to authenticate the user’s login name.
If the user is authenticated, the server returns the local username to Junos OS (
local-user-name for TACACS+, and
Juniper-Local-User-Name for RADIUS ). Junos OS then determines
whether a local username is specified for that login name, and if so, Junos OS
assigns the user to that local user template. If a local user template does not
exist for the authenticated user, the router or switch defaults to the
remote template, if configured.
To configure a local user template, define the template username at the [edit
system login] hierarchy level. Assign a class to specify the privileges
you want to grant to the local users to whom the template applies:
[edit system login]
user local-username {
full-name "Local user account";
uid uid-value;
class class-name;
}
To assign a user to the local user template, configure the remote
authentication server with the appropriate parameter (
local-user-name for TACACS+, and
Juniper-Local-User-Name for RADIUS), and specify the username
defined for the local user template. To configure different access privileges for
users who share the local user template account, you can use vendor-specific
attributes in the authentication server configuration file to allow or deny specific
commands and configuration hierarchies for a user.
This example configures the sales and engineering
user templates on the local device. The TACACS+ server configuration file then
assigns users to specific templates.
[edit]
system {
login {
user sales {
uid 6003;
class sales-class;
}
user engineering {
uid 6004;
class super-user;
}
}
}
When the users Simon and Rob are authenticated, the router or switch applies the
sales local user template. When login users Harold and Jim are
authenticated, the router or switch applies the engineering local
user template.
user = simon {
...
service = junos-exec {
local-user-name = sales
allow-commands = "configure"
deny-commands = "shutdown"
}
}
user = rob {
...
service = junos-exec {
local-user-name = sales
allow-commands = "(request system) | (show rip neighbor)"
deny-commands = "clear"
}
}
user = harold {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "monitor | help | show | ping | traceroute"
deny-commands = "configure"
}
}
user = jim {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "show bgp neighbor"
deny-commands = "telnet | ssh"
}
}
Configure Remote User Template Accounts for User Authentication
The network device can map remotely-authenticated users to a locally defined user
account or user template account, which determines authorization. The
remote template account is a special user template. By default,
Junos OS assigns remotely-authenticated users to the
remote template account, if configured, when:
-
The authenticated user does not have a user account configured on the local device.
-
The remote authentication 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.
To configure the remote template account, include the user
remote statement at the [edit system login] hierarchy
level, and specify the login class for users assigned to the remote
template:
[edit system login]
user remote {
full-name "remote users";
uid uid-value;
class class-name;
}
To configure different access privileges for users who share the
remote template account, you can use vendor-specific attributes
in the authentication server configuration file to allow or deny specific commands
and configuration hierarchies for a user.
Example: Create Template Accounts
This example shows how to create template accounts.
Requirements
No special configuration beyond device initialization is required before configuring this feature.
Overview
You can create template accounts that are shared by a set of users when you are using RADIUS, or TACACS+ authentication. When an authenticated user is assigned to a template account, the CLI username is the login name, but the user inherits privileges, file ownership, and effective user ID from the template account.
By default, Junos OS assigns remotely-authenticated users to
the remote template account when:
-
The authenticated user does not have a user account configured on the local device.
-
The remote authentication 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.
In this example, you create the remote template
account and set the username to remote and the login class for the
user as operator. The device assigns the remote
template to users who are authenticated by RADIUS, or TACACS+ but who
do not have a local user account or belong to a different local template
account.
You then create a local template account and set the username as admin and the login class as superuser. You use local template accounts when you need to assign remotely authenticated users to different login classes. Thus, each template can grant a different set of permissions appropriate for the users assigned to that user template.
Configuration
Create a Remote Template Account
Step-by-Step Procedure
To create the remote template account:
-
Set the username and the login class for the
remoteuser.[edit system login] user@host# set user remote class operator
Results
In configuration mode, confirm your configuration by entering the
show system login 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 login
user remote {
class operator;
}
After you configure the device, enter commit in
configuration mode.
Create a Local Template Account
Step-by-Step Procedure
To create a local template account:
-
Set the username and the login class for the user template.
[edit system login] user@host# set user admin class superuser
Results
In configuration mode, confirm your configuration by entering the
show system login 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 login
user admin {
class super-user;
}
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 specify a system authentication order. For more information, see the following tasks:
-
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 system authentication order. See Example: Configure Authentication Order.
What Are Remote Authentication Servers?
You probably already use a remote authentication server (or servers) in your network. Using these servers is a best practice, because they allow you to create a consistent set of user accounts centrally for all devices in your network. Managing user accounts is much easier when you use remote authentication servers to implement an authentication, authorization, and accountability (AAA) solution in your network.
Most enterprises use one or more of three basic remote authentication methods: RADIUS, and TACACS+. Junos OS supports all three methods, and you can configure Junos OS to query any type of remote authentication server. The idea behind a RADIUS, or TACACS+ server is simple: Each acts as a central authentication server that routers, switches, security devices, and servers can use to authenticate users as they attempt to access these systems. Think of the advantages that a central user directory offers for authentication auditing and access control in a client/server model. The RADIUS and TACACS+ authentication methods offer comparable advantages for your network infrastructure.
Using a central server has multiple advantages over the alternative of creating local users on each device, a time-consuming and error-prone task. A central authentication system also simplifies the use of one-time password systems such as SecureID, which offer protection against password sniffing and password replay attacks. In such attacks, someone can use a captured password to pose as a system administrator.
-
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 than TACACS+. For this reason, network engineers generally prefer RADIUS over TACACS+.
-
-
TACACS+—You should use TACACS+ when your priorities are security and flexibility.
-
Security—TACACS+ is more secure than RADIUS. Not only is the full session encrypted, but authorization and authentication are done separately to prevent anyone from trying to force their way into your network.
-
Flexibility—Transmission Control Protocol (TCP) is a more flexible transport protocol than UDP. You can do more with TCP in more advanced networks. In addition, TACACS+ supports more of the enterprise protocols, such as NetBIOS.
-