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

network 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

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.

📗 Hint
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
📘 Note
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-exp to a local login-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 user is named identical to the TACACS+ groupname, or LDAP groupname, or AD groupname, or groupname
  • local-user-name has a class assigned
📙 Important
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.

📗 Hint
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

📙 Important
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