This netlab has been configured using the official available documentation for the JUNOS vSRX appliance. This is my first ever JUNOS netlab, so if there are any obvious errors, send me and email.
I have been thinking about methods explaining specific JUNOS TACACS+ configuration steps. So it would make sense for someone not familiar with AAA JUNOS configuration, but maybe familiar with others vendors RBAC concepts.
This IP networking example uses clear text protocols like
- telnet
- cleartext password
- etc.
This is about IP protocols, not about security. The JUNOS vSRX in acts as a router in a trusted networking environment. Everything is allowed, to focus on the most simple example setup.
- Everything allowed
- IP forwarding first
- Packet filtering disabled
This is a sandbox IP networking solution.
Topology
IP addressing
The IP addressing used in this netlab. 4 appliances:
| Node | Interface | IP address | Function |
|---|---|---|---|
| R1 | eth0/0 | 10.100.200.50/30 | router |
| AAA-49 | eth0 | 10.100.200.49/30 | AAA daemon |
| R1 | eth0/2 | 10.100.100.1/24 | router |
| FW170 | ge-0/0/0 | 10.100.100.170/24 | TACACS+ client |
| R1 | eth0/3 | 10.100.250.1/24 | router |
| node-10 | eth0 | 10.100.250.10 | linux management client |
Authenticating example demo[0-3] users connecting from node-10 to FW170.
VSA's and RBAC roles
Finding the default RBAC or roles using RADIUS/TACACS+ VSA's vendor specific attributes. Most vendors publish VSA's on the RADIUS section in the documentation only. Sometimes VSA's are found on the TACACS+ documentation section.
The generic search terms in the vendors documentation, to have search results quickly:
- VSA
- RADIUS VSA
- TACACS+ VSA
- Vendor Specific Attribute
Configure the TACACS+ deamon using vendor's VSA's.
IOS-XR example VSA's
Vendors Cisco IOS-XR - Predefined Task Groups:
Table overview:
| Role Name | Description |
|---|---|
| cisco-support | Cisco support personnel tasks |
| netadmin | Network administrator tasks |
| operator | Operator day-to-day tasks (for demonstration purposes) |
| root-lr | Secure domain router administrator tasks |
| root-system | System-wide administrator tasks |
| sysadmin | System administrator tasks |
| serviceadmin | Service administration tasks, for example, SBC |
I have failed at finding IOS-XR command(s) to display these shown above in a handy overview. This is the closest of a IOS-XR command to display the defaults:
show aaa usergroup ?
Showing following output:
RP/0/0/CPU0:ios#show aaa usergroup ?
| Output Modifiers
root-lr Name of the usergroup
netadmin Name of the usergroup
operator Name of the usergroup
retrieve Name of the usergroup
sysadmin Name of the usergroup
maintenance Name of the usergroup
root-system Name of the usergroup
provisioning Name of the usergroup
read-only-tg Name of the usergroup
serviceadmin Name of the usergroup
cisco-support Name of the usergroup
WORD Name of the usergroup
<cr>
VRP example VSA's
VRP, depending on the hardware platfrom, most differences are between switches and routers. This is from a VRP routing platform much like f.e.: NE-40,NE5000E, NE9000 :
Huawei VRP - NE9000 AAA and User Management Configuration Commands
Handy VRP CLI command to show the RBAC defaults:
display aaa user-group
Since the documentation above will most probably disappear in the future, here the output direct from the command line. Here a overview of the VRP router default RBAC groups:
<HUAWEI> display aaa user-group
------------------------------------------------------
User-group-name User-group-id
------------------------------------------------------
manage-ug 1
system-ug 2
monitor-ug 3
visit-ug 4
------------------------------------------------------
Total 4, 4 printed
Offer a ready to use pre-configured default-state 4 level RBAC framework, using vendors RADIUS and TACACS+ VSA's.
JUNOS example VSA's - Vendor Specific Attributes
JUNOS has something very similar, it results in the same state as above, but needs a bit more configuration at the end. It is not out-of-the box usable in the shipped state. The JUNOS configuration lacks additional glue information to get active.
This is the list of the JUNOS/vSRX availble VSA's needed for the TACACS+ daemon configuration. This is from JUNOS docs
...
service = junos-exec {
local-user-name = <username-local-to-router>
allow-commands = "<allow-commands-regex>"
allow-configuration-regexps = "<allow-configuration-regex>"
deny-commands = "<deny-commands-regex>"
deny-configuration-regexps = "<deny-configuration-regex>"
}
...
This section above will be used to some part in the TACACS+ configuration. The prefix service = junos-exec setting.
The local available class is shown when trying to configure a example user:
demo0@FW170# set system login user NET-ent class ?
Possible completions:
<class> Login class
operator permissions [ clear network reset trace view ]
read-only permissions [ view ]
super-user permissions [ all ]
unauthorized permissions [ none ]
[edit]
TACACS+
Prior the JUNOS vSRX configuration setup, the mandatory working TACACS+ daemon configuration.
TACACS+ server IP settings:
| Setting | Value |
|---|---|
| eth0 | 10.100.200.49 |
| TCP port | 49 |
| TACACS+ key | 123-my_tacacs_key |
Overview of the TACACS+ configured users and groups.
The default password is
demo for ALL users shown in the example| username | groupname |
|---|---|
| demo0 | NET-exp |
| demo1 | NET-pro |
| demo2 | NET-ent |
| demo3 | NET-tac |
TACACS+NG Configuration
The resulting configuration, fully working. Please mind this configuration has debug option set, to see the authentication and authorization process while configuring.
Do not run TACACS+ debug in production. Set to # debug = AUTHEN AUTHOR after configuration is finished and working in your netlab.
Fully working preconfigured tac_plus-ng.cfg settings for user authentication and authorization:
#!/usr/sbin/tac_plus-ng
id = spawnd {
listen = { address = 0.0.0.0 port = 49 }
}
id = tac_plus-ng {
# enable debugging for the first
debug = AUTHEN AUTHOR
# disable debugging when running in production.
# generic host, match all IPv4 switches and routers
host generic {
address = 0.0.0.0/0
welcome banner = "\n ${server.name} running TACACS+NG authenticates JUNOS\n\n"
motd banner = " device: ${device}\n device.address: ${device.address}\n nac: ${nac}\n nas: ${nas}\n server.address: ${server.address}\n server.name: ${server.name}\n user: ${user}\n profile: ${profile}\n"
key = 123-my_tacacs_key
}
# profiles
profile junos-lvl3 {
script {
if (service == junos-exec) {
set local-user-name=NET-exp
permit
}
}
}
profile junos-lvl2 {
script {
if (service == junos-exec) {
set local-user-name=NET-pro
permit
}
}
}
profile junos-lvl1 {
script {
if (service == junos-exec) {
set local-user-name=NET-ent
permit
}
}
}
profile junos-tac {
script {
if (service == junos-exec) {
set local-user-name=NET-tac
permit
}
}
}
# groups
group NET-exp
group NET-pro
group NET-ent
group NET-tac
# users
user demo0 {
password { login = clear demo }
member = NET-exp
}
user demo1 {
password { login = clear demo }
member = NET-pro
}
user demo2 {
password { login = clear demo }
member = NET-ent
}
user demo3 {
password { login = clear demo }
member = NET-tac
}
# rules
ruleset {
rule {
script {
if (member == NET-exp) { profile = junos-lvl3 permit }
if (member == NET-pro) { profile = junos-lvl2 permit }
if (member == NET-ent) { profile = junos-lvl1 permit }
if (member == NET-tac) { profile = junos-tac permit }
}
}
}
}
Below a optional setting. If you do not understand it you do not need to configure this.
If you have a LDAP backend running, match the group name in TACACS+ configurtation with the according LDAP group name the interesting TACACS+ users reside, right at the beginning. It does not need to be connected to LDAP to work. This way it will document a LDAP setting, and when once endabled it will match right on at the start.
Ready to start the TACACS+ daemon. For the first interactive with debug output to the terminal.
/usr/bin/tac_plus-ng -b -1 -f /etc/tac_plus-ng/tac_plus-ng.cfg
The TACACS+
group setting is important here. NET-ent will be one of the 4 the created usernames on the JUNOS platform.This is explained here below in the following JUNOS configuration, read about JUNOS - Login Class
JUNOS
This is the most basic JUNOS vSRX router configuration part.
IP connectivity
Simple IP initial configuration. IP connectivity first, vSRX appliance is a router.
configure
#
set system root-authentication plain-text-password
JuN1p3r
JuN1p3r
#
set interfaces ge-0/0/0 unit 0 family inet address 10.100.100.170/24
#
set system host-name FW170
set system login message "user pass root JuN1p3r"
#
set routing-options static route 0.0.0.0/0 next-hop 10.100.100.1
#
set security zones security-zone trust tcp-rst
set security zones security-zone trust interfaces ge-0/0/0 host-inbound-traffic system-services all
set security zones security-zone trust interfaces ge-0/0/0 host-inbound-traffic protocols all
#
set system services telnet
#
commit check
#
commit
JUNOS AAA configuration, and everything else IP related must work out of the box.
Verify
Show trusted zones:
show security zones trust
Security zone: trust
Send reset for non-SYN session TCP packets: On
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Verify connectivity to the TACACS+ daemon or service using the ping 10.100.200.49 command:
root@FW170> ping 10.100.200.49
PING 10.100.200.49 (10.100.200.49): 56 data bytes
64 bytes from 10.100.200.49: icmp_seq=0 ttl=63 time=1.113 ms
64 bytes from 10.100.200.49: icmp_seq=1 ttl=63 time=0.737 ms
^C
--- 10.100.200.49 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.737/0.925/1.113/0.188 ms
Login Class
The JUNOS configuration process uses login classes to put a local user into a predefined local system role. login class is a group of JUNOS default settings and default levels assigned to user.
JUNOS Predefined System Login Classes:
Login Class - Permission Flag Set
- operator - clear, network, reset, trace, view
- read-only - view
- super-user - all
- unauthorized - none
From the official JUNIPER documentation
The important part that explains how JUNOS RBAC is configured first and how it is working:
... 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. ...
Generic JUNOS RBAC Configure process:
- Create a local JUNOS user named as the TACACS+ group f.e.:
NET-exp - Add user named
NET-expto a locallogin-class-**super-user**
The AAA solution works same way as configured on IOS-XR or NX-OS or VRP, using the VSA's and applying RBAC based roles to authenticating users.
Configuring local JUNOS users
Overview over the pre-provisioned , or always available default state using JUNOS. Every JUNOS has these 4 default user-classes shown below. Using the set system login user NET-ent class configuration command and using ? to list the available classes:
demo0@FW170# set system login user NET-ent class ?
Possible completions:
<class> Login class
operator permissions [ clear network reset trace view ]
read-only permissions [ view ]
super-user permissions [ all ]
unauthorized permissions [ none ]
[edit]
The vendor specific information is now in place, to create the local users on the JUNOS appliance (vSRX).
Configuration process using JUNOS for RBAC based AAA configuration with TACACS+:
- local-user-name
useris named identical to the TACACS+ groupname, or LDAP groupname, or AD groupname, or groupname - local-user-name has a
classassigned
Each local JUNOS
user is named identical to the TACACS+ group. local JUNOS user has a class assigned- TACACS+ groupname - JUNOS classname
- NET-exp - super-user
- NET-pro - operator
- NET-ent - read-only
- NET-tac - unauthorized
Full JUNOS vSRX RBAC/AAA local user configuration:
configure
set system login user NET-ent full-name "NOC 1-st level group"
set system login user NET-ent class read-only
set system login user NET-exp full-name "NOC 3-rd level group"
set system login user NET-exp class super-user
set system login user NET-pro full-name "NOC 2-nd level group"
set system login user NET-pro class operator
set system login user NET-tac full-name "NOC TAC level group"
set system login user NET-tac class unauthorized
commit check
commit
The user MUST match TACACS+ group name NET-ent AND have the class read-only set, to work properly. This for each defined user in the list.
TACACS+ authentication
This configuration step sets the TACACS+ specifics. It does not change to the currently active local AAA mechanism in JUNOS.
Configure the TACACS+ server and configure the preferred source-address for the TACACS+ requests:
config
set system tacplus-server 10.100.200.49 secret 123-my_tacacs_key
set system tacplus-server 10.100.200.49 source-address 10.100.100.170
commit check
commit
It is safe to commit. AAA will still be working as before when applied to production.
Set system authentication order
Needless to say, you know what you are doing when applying this configuration step.
This is always the most critical configuration step on every operating system. In the worst case it will result in loss of vSRX management. Do not apply this configuration step in a running IP environment without having a way to set to the default setting.
Choosing the priority order of available authentication mechanisms on JUNOS. Right after commiting the line below, the vSRX starts to send AAA requests to the TACACS+ server:
config
set system authentication-order tacplus
set system authentication-order password
commit check
commit
When committed, JUNOS FW170 is sending incoming user request to the TACACS+ daemon or server.
Verify configuration
Show AAA configuration state
show configuration system login
related output:
demo0@FW170> show configuration system login
user NET-ent {
full-name "NOC 1-st level group";
uid 2000;
class read-only;
}
user NET-exp {
full-name "NOC 3-rd level group";
uid 2001;
class super-user;
}
user NET-pro {
full-name "NOC 2-nd level group";
uid 2002;
class operator;
}
user NET-tac {
full-name "NOC TAC level group";
uid 2003;
class unauthorized;
}
message "user pass root JuN1p3r";
This way both sides of the TACACS+ communication are prepared JUNOS and the TACACS+ daemon running.
Only thing that is missing is a willing user to authenticate to the JUNOS platform for inline management. A example demo NOC user. Now is the time to test the setup.
Verify AAA
Working authentication and authorization requests in the AAA daemon log. TACACS+ daemon is ran using the debug = AUTHEN AUTHOR setting:
tac_plus-ng -1 -f tac_plus-ng.cfg
2035: 20:01:24.444 0/e787acc4: 10.100.100.170 authen: hdr->seq_no: 1
2035: 20:01:24.444 0/e787acc4: 10.100.100.170 looking for user demo1 realm default
2035: 20:01:24.444 0/e787acc4: 10.100.100.170 user lookup succeded
2035: 20:01:25.330 0/e787acc4: 10.100.100.170 authen: hdr->seq_no: 3
2035: 20:01:25.330 0/e787acc4: 10.100.100.170 looking for user demo1 realm default
2035: 20:01:25.330 0/e787acc4: 10.100.100.170 user lookup succeded
2035: 20:01:25.330 0/e787acc4: 10.100.100.170 shell login for 'demo1' from 192.0.2.10 on pts/1 succeeded (profile=junos-lvl2)
2035: 20:01:25.352 1/8a57a6cc: 10.100.100.170 Start authorization request
2035: 20:01:25.352 1/8a57a6cc: 10.100.100.170 user 'demo1' found
2035: 20:01:25.352 1/8a57a6cc: 10.100.100.170 nas:service=junos-exec (passed thru)
2035: 20:01:25.352 1/8a57a6cc: 10.100.100.170 nas:absent srv:local-user-name=NET-pro -> add local-user-name=NET-pro (k)
2035: 20:01:25.352 1/8a57a6cc: 10.100.100.170 added 1 args
The authentication process on the command line using a example linux node-10. Authenticating user is demo1.
zebra@node-10 ~ % telnet 10.100.100.170
Trying 10.100.100.170...
Connected to 10.100.100.170.
Escape character is '^]'.
user pass root JuN1p3r
login: demo1
Welcome JUNOS to TACACS+NG
Password:
device: generic
device.name: AAA-49
device.address: 10.100.100.170
device.dnsname:
nac: 10.100.250.10
nac.name: 10.100.250.10
nas: 10.100.100.170
nas.name: AAA-49
server.address: 10.100.200.49
server.name: AAA-49
user: demo1
profile: junos-lvl2
--- JUNOS 19.2R1.8 Kernel 64-bit XEN JNPR-11.0-20190517.f0321c3_buil
Show which commands are available using to the user:
show cli authorization
This lists all the available commands with its RBAC role assigned, which is called class on JUNOS. This is a small output of the user demo2:
demo2@FW170> show cli authorization
Current user: 'NET-ent' login: 'demo2' class 'read-only'
Permissions:
view -- Can view current values and statistics
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none
Output of the user demo1 with class operator set:
demo1@FW170> show cli authorization
Current user: 'NET-pro' login: 'demo1' class 'operator'
Permissions:
clear -- Can clear learned network info
network -- Can access the network
reset -- Can reset/restart interfaces and daemons
trace -- Can view trace file settings
view -- Can view current values and statistics
Individual command authorization:
Allow regular expression: none
Deny regular expression: none
Allow configuration regular expression: none
Deny configuration regular expression: none
Troubleshooting
These are configuration issues happened during setup of this example IP networking topology.
login denied
In case the login is denied. Check for a missing permit entry in the profile configuration. Verify permit at the end in the (service == junos-exec) section like shown:
# tag: JUNOS
# This is the 3-rd level support.
profile junos-lvl3 {
script {
if (service == junos-exec) {
set local-user-name = NET-exp
permit
}
}
}
Skip uid setting
Use following configuration example without uid set:
configure
set system login user NET-ent full-name "NOC 1-st level group"
set system login user NET-ent class read-only
set system login user NET-exp full-name "NOC 3-rd level group"
set system login user NET-exp class super-user
set system login user NET-pro full-name "NOC 2-nd level group"
set system login user NET-pro class operator
set system login user NET-tac full-name "NOC TAC level group"
set system login user NET-tac class unauthorized
set system login message "user pass root JuN1p3r"
commit check
commit
Skip setting the uid in setups.
Using the show system login displays the local uid which generated by the local JUNOS operating system. The uid is only a local random generated JUNOS index value.
demo0@FW170# show system login
user NET-ent {
full-name "NOC 1-st level group";
uid 2000;
class read-only;
}
user NET-exp {
full-name "NOC 3-rd level group";
uid 2001;
class super-user;
}
user NET-pro {
full-name "NOC 2-nd level group";
uid 2002;
class operator;
}
user NET-tac {
full-name "NOC TAC level group";
uid 2003;
class unauthorized;
}
message "user pass root JuN1p3r";
Use encryption
TACACS+ encryption and obfuscation options are ALWAYS determined by the used operating system. The TACACS+ protocol implementation uses ALWAYS the default linux/UNIX or other running operating system
crypt() library.Generate encrypted passwords using for example the linux mkpasswd. Crypto hash linux generation tools
This netlab uses clear login passwords in the TACACS+NG configuration. Change to encrypted passwords. Read the TACACS+ blog articles using simple configuration and run TACACS+NG for various networking vendors.
See also
GNS3 networking IP example AAA configurations using TACACS+NG and other vendors networking operating systems, and vendor specific configuration options.
References
- JUNOS login class overview
- Michael O’Brien's - JUNIPER vSRX setup initial confifiguration guide
- petenetlive - Knowledgebase - JunOS – Using TACACS+ With Cisco ACS
- networkcuriosity - CLI-authentication-using-RADIUS
- Juniper Supportportal - M-series - How to configure TACACS+
- Juniper Documentation - User_access_TACACS_authentication
- Juniper Documentation - Platform TACACS+ server configuring
- Juniper Supportportal - Configuring a user for TACACS authentication
