Detections
Analytics

6.6.7 Ensure Remote Login Class for Authorization through External AAA - login class

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

External AAA servers should be utilized to provide Authorization via a single 'Remote' template account.

Rationale:
JUNOS routers ship with 4 Predefined Login Classes for user Authorization, these are:
- super-user
- read-only
- operator
- unauthorized
These classes provide basic Authorization, restricting what users in each class can or cannot do, to allow organizations to get a router up and running, but do not provide fine grained control needed by all but very smallest organizations.
The built in classes also do not meet the other recommendations in this section. For example, the super-user class (which is the only built in class with read/write permissions) also has permission to start a Unix Shell and does not have an Idle Session Timeout.
Because of these limitations it is recommended that Custom Login Classes be defined following the principle of least privilege, where each class of users is granted only those permissions needed to complete their job role.
However, defining and maintaining Custom Login Classes locally on each router, switch, firewall or other network device can quickly become difficult and error prone in a larger environment.
For larger networks JUNOS provides for extremely fine grained access control rules to be defined on an External AAA server running either RADIUS or TACACS+ through the use of Vendor Specific Attributes which map to the same permissions that can be set locally for a class.
Vendor Specific Attributes (or VSAs) are standards based extensions to the RADIUS and TACACS+ protocols and are supported on most implementations by defining an appropriate dictionary.
When performing Authorization using External RADIUS or TACACS+ services, it is recommended that a single 'remote' user is configured on the device and mapped to a 'remote' class with minimal permissions set. The user should be named 'remote' where possible, as this name is reserved by JUNOS as the account to which users are mapped when authenticated through External AAA and for whom the Juniper-Local-User-Name VSA is not set.
When a user is authenticated by RADIUS or TACACS+ the server can return a number of VSAs including:
- Juniper-Local-User-Name - Maps the user to a local user 'template account', if this is not specified the single 'remote' user account is used.
- Juniper-User-Permissions - Allows the server to set the same permissions as would be set in a login class locally. These permission are added to those of the remote user's configured class.
- Juniper-Allow-Commands - Uses an Extended Regular Expression to grant Operational Mode commands in addition to those allowed by the user's class.
- Juniper-Deny-Commands - Uses an Extended Regular Expression to deny Operational Mode commands which would otherwise be allowed by the user's class.
- Juniper-Allow-Configuration - As with the Allow Commands, but to grant Configuration Mode commands not normally allowed by the user's class.
- Juniper-Deny-Configuration - As with Deny Commands, but to deny Configuration Mode commands which would otherwise be allowed by the user's class.

NOTE - This is not a complete list of all attributes and uses the RADIUS VSA naming convention. Equivalent TACACS+ VSAs match the above but with slightly different naming.
By combining the use of the above VSAs from either a RADIUS or TACACS+ server, it is possible to define granular access control equivalent to that which can be set using locally configured Login Classes, but without the need to configure and maintain consistent, granular AAA policy across all devices.
Where devices are primarily managed via Software Defined Networking or other centralized management and/or automation platforms rather than through the CLI or other local interfaces, then this may be sufficient to meet requirements for centralized AAA and/or allow for effective management of local template accounts without using external AAA.

Solution

To create a new class you can issue the following commands from the [edit system login] hierarchy. In this example, we create a new class named 'remote', granting only view permissions, and assign the remote user to the new class. More detailed permissions will be added to these permissions
[edit system login]
user@host#set class remote permissions [ view ]
(this class should also have Idle timeouts and other options set in line with other recommendations in this section).
To change the class for a user account, use the following command under the [edit system login] hierarchy:
[edit system login]
user@host#set user remote class remote
A full discussion of RADIUS or TACACS+ configuration and options is beyond the scope of this guide, but a simple example of using a TACACS.net server running on Windows with AD integration for a remote user is shown below.
This example is taken from an anonymized real world deployment, so also includes sections to allow access to different groups of TACACS+ Clients and permissions for Cisco IOS and Netscreen devices. The most relevant section is the <Service> for service=junos-exec, where the VSAs for TACACS+ Clients running JUNOS are defined, but the entire Authorization for this Class is given for context.
<Authorization>
<!--CIS Example remote user Authorization from TACACS.net Authorization.xml-->
 <UserGroups>
 <!-- The UserGroup is defined elsewhere - in this case it maps to an Active Directory Group call GRP-NETOPS -->
 <UserGroup>GRP-NETOPS</UserGroup>
 </UserGroups>
 <ClientGroups>
 <!--Defines the Groups of devices this usergroup can login to -->
 <ClientGroup>CORE-NET</ClientGroup>
 <ClientGroup>ACCESS-NET</ClientGroup>
 <ClientGroup>FIREWALLS</ClientGroup>
 </ClientGroups>
 <Shell>
 <!--note that the login and exit commands are always permitted. (used for Cisco and Netscreen devices) -->
 <Permit>show.*</Permit>
 <Permit>terminal.*</Permit>
 <Permit>get.*</Permit>
 <Deny>.*</Deny>
 </Shell>
 <Services>
 <Service>
 <!-- JUNOS VSAs to set additional user permissions -->
 <Set>service=junos-exec</Set>
 <Set>local-user-name=remote</Set> <!--This will be mapped to a template user on JUNOS devices with 'remote' class permissions -->
 <Set>allow-commands=show.*</Set> <!-- Additional permission (above remote class set above) to allow all 'show' operational commands -->
 <Set>user-permissions=view-configuration</Set> <!-- Grants additional permission to view the full config (no secrets)-->
 <Set>user-permissions=network</Set> <!-- Grants access to the network for SSH, Ping, etc -->
 </Service>
 </Services>
 <AutoExec>
 <!--Set the Priv lvl to 15 for Cisco devices, ignored by JUNOS devices -->
 <Set>priv-lvl=15</Set>
 </AutoExec>
</Authorization>

Impact:
Careful configuration of permissions following the least privilege principle is essential for secure and reliable management of the network.
When configuring remote AAA, it is recommended that a local Emergency Access Account also be configured to allow management of the device in the event that AAA services are unavailable.

Default Value:
By default all users are, in effect, members of the super-user class.

See Also

https://workbench.cisecurity.org/files/2278

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-2(7), CSCv7|16.2

Plugin: Juniper

Control ID: 5443ecc112abdbf873370f26017b12ee21cc06a8a6124a4a1711182ff051fedd