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:

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:

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.

• JUNOS login class overview

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:

Overview of the TACACS+ configured users and groups.

click for more

Wireguard

This is the official WireGuard quickstart setup in a GNS3 netlab. Both linux WireGuard peers are connected using a routed IP connection via encrypted interface wg0. The IP addressing on both peers interface eth0 represent public IP addressing.

In the final step procedure, both linux peers automatically start up the wg0 tunnel connection at boot up sequence, and stop the service when the related wg0 interface has been stopped due to a system shutdown or manually reset as system root user. The procedure explained in this blog entry uses 2 linux system commands only, to configure a secure connection:

• wg
• ip

Topology

IP addressing

State

Traceroute mtr command from peerA to peerB in the current state of network, before interface wg0 is created on both peers.

                             My traceroute  [v0.96]
peerA (192.0.2.10) -> 198.51.100.10 (198.51.100.10)    2026-01-21T12:51:42+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.0.2.1                         0.0%     5    1.1   1.2   1.1   1.3   0.1
 2. 10.100.0.0                        0.0%     4    1.9   1.9   1.7   2.1   0.2
 3. 198.51.100.10                     0.0%     4    2.2   2.3   2.2   2.4   0.3

The full setup is explained if you click for more

Needing a Microsoft AD service for the virtual GNS3 network laboratory . Since i am using linux, installing samba 4 AD DC is a good enough for simple authentication testing. The specific use case for a Active Directory Service is authenticating and authorizing users to networking components using TACACS+ protocol. Networking components like routers and switches. This works for all TACACS+ client implementations as soon as the used TACACS+ server/daemon is able to read the directory service (LDAP), here the Active Directory flavour of LDAP protocol, to get the credentials, and group assignments.

Now let's begin with a citation from the official samba page:

... Starting from version 4.0 (released in 2012,) Samba is able to serve as an Active Directory (AD) domain controller (DC). Samba operates at the forest functional level of Windows Server 2008 R2 w ...

So samba should be able to work as a simple Windows AD DC server

The setup explained below is a samba 4 AD Domain Controller, stand alone, for authentication service only. Stand alone in the sense of the only one AD Domain Controller running samba in that networking environment, no clustering, no FSM roles etc. Not to be mixed up with the samba server role, which is also called stand alone. The samba server role is set to dc when populating the directory service.

Samba version used in this setup

click for more

TACACS+ configuration using Huawei's (VRP) OS. This is about configuring authentication and authorization using the TACACS+ protocol. Usually or the universal approach, that works among all routers, is set a value to the wide used VSA priv-lvl which is explained in Configuring TACACS+NG authentication for VRP - blog entry.

Obvious at the start, I am not much of a VRP expert myself. This blog entry is about how to configure TACACS+NG to assign VRP RBAC roles to authenticating users in a simple nutshell networking lab. So email me please, if you have something to correct in this approach.

Most big vendor's router/switch/firewall OS implementations offer RBAC based profile assignment. Huawei's VRP has RBAC in place to be used. How to configure using TACACS+NG and assign VRP RBAC roles to authenticating users.

The initial VRP basic configuration steps are explained Configuring TACACS+NG authentication for VRP. a blog entry about AUTHENTICATION only, using priv-lvl assignment. The approach that every professional router OS offers when it comes to basic AAA configuration,

The TACACS+ daemon used in this netlab is Marc Hubers's Pro-Bono-Publico: TACACS+NG.

Using both at same time, would add another level of complexity. This example is meant to be simple. The priv-lvl assignment configuration using TACACS+NG is already explained in Configuring TACACS+NG authentication for VRP netlab.

Topology

IP addressing

The IP addressing used in this netlab. 3 appliances:

TACACS+ daemon settings:

R1's connected interfaces:

R1#sh ip int brie | e un
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            10.100.200.50   YES NVRAM  up                    up
Ethernet0/2            10.100.100.1    YES manual up                    up
Ethernet0/3            10.100.250.1    YES manual up                    up

R1 IP connected routes, overview in CIDR notation showing the connected subnet mask to interface:

R1#sh ip route connected | i C
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
C        10.100.100.0/24 is directly connected, Ethernet0/2
C        10.100.200.48/30 is directly connected, Ethernet0/0
C        10.100.250.0/24 is directly connected, Ethernet0/3

Testing authentication is done from the node-10 to the router R108 using telnet protocol.

R1 is forwarding IP packets and has no other role, R1 is a symbol for a dynamic routed enterprise network. IP routing within a secure domain.

User settings overview related to the TACACS+ configuration:

click for more

This is a followup to previous GNS3 netlab Configuring TACACS+NG and LDAP authentication. The goal of the previous netlab was to move user credentials and group management to a LDAP server. The goal was achieved.

Reading the TACACS+NG best practices first entry to use TLS/DTLS wherever possible:

TLS/DTLS

• Use TLS/DTLS wherever possible. tac_plus-ng support certificate based authentication, but also TLS pre-shared keys
• TLS only provides authentication. Use a (possibly and most likely custom) MAVIS backend for certificate-based host details ...

So following this advice and preferring LDAPS over LDAP communication.

But also at the same time:

The necessary information to setup a working LDAP GNS3 netlab are explained in the previous Configuring TACACS+NG and LDAP authentication blog entry. The goal of this GNS3 netlab will is the configuration process to use LDAPS as mandatory protocol to use between the TACACS+ daemon and the LDAP daemon.

Topology

Using the now ready setup and converged network topology from Configuring TACACS+NG and LDAP authentication:

IP topology of connected IP networks to router R1:

R1#sh ip int brie | e un
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/1            198.51.100.1    YES NVRAM  up                    up
Ethernet0/2            203.0.113.1     YES NVRAM  up                    up
Ethernet0/3            10.100.100.1    YES NVRAM  up                    up
Ethernet1/1            10.100.200.50   YES NVRAM  up                    up

Network is converged and ready to use.

click for more

Configure TACACS+ and LDAP authentication and authorization using users from a directory service. This is a GNS3 netlab the router operating system in this netlab is Cisco's IOS-XE. It will work with every other router too. I have written a lot of simple GNS3 TACACS+NG netlabs, that one is more complex but I plan to make it as simple as possible so you can rebuild it in your own network testing area. The components used in the netlab are following:

• TACACS+ appliance (TACACS+NG)
• LDAP appliance (LLDAP)
• IOS-XE router

Build the both appliances using alpine-linux, the resulting size for both appliances is 500MB. You need to build them by yourself, use following build instructions Building 64bit alpine linux GNS3 FRRouting appliance and add the software from above.

This netlab runs without enabling encryption protocol like LDAPS or TLS or HTTPS. It is not in the scope of the netlab to enable encryption at all. You SHOULD be able to add security protocols on top once everything is setup and working. The scope of this netlab is to build a simple environment where you can play with the programs and protocols. This is a sandbox solution.

Regarding LDAP the official TACACS+NG documentation states in section 5.1.LDAP Backends

mavis_tacplus-ng_ldap.pl is an authentication/authorization back-end for the external module. It interfaces to various kinds of LDAP servers, e.g. OpenLDAP, Fedora DS and Active Directory. The server type is detected automatically. Its behaviour is controlled by a list of environmental variables: ...

TACACS+NG has a very long list of environmental LDAP variables that might be worth reading about and tinkering with once everything is working as configured, to name a few:

• LDAP_FILTER
• LDAP_FILTER_GROUP
• LDAP_MEMBEROF_REGEX

Overview of the used IP addressing in this netlab

Overview of the data that needs to be configured in the directory service LDAP in the order of priority:

click for more

This is how to configure TACACS+ authentication and authorisation for the Cisco SSM On-Prem appliance using a free TACACS+ software implementation like below:

• TACACS+NG
• freeRADIUS
• tac_plus

I have found a Cisco forum configuration issue explaining the issue using Aruba's Clearpass and its solution. This is the only article I have found that has useful information and debugging hints leading to a working solution using any kind of TACACS+ protocol implementation.

What is the issue with SSM On-Prem and TACACS+ protocol authentication?

The SSM On-Prem TACACS+ authentication test ran in the web interface always SUCCEEDS but if a TACACS+ user authenticates it FAILS with following error on the SSM On-Prem side shown in the web user interface:

There is no easy way to debug this on the SSM side. To get to the bottom of the issue is run TACACS+ daemon in the debugging mode, debug authentication and debug authorization. The procedure described below will work for any kind of TACACS+ protocol issues with any application offering TACACS+ protocol support.

Running SSM On-Prem in QEMU/GNS3

Settings shown below are to ease your pain when running SSM On-Prem in a netlab environment. Settings are mandatory KVM/QEMU to get a running the SSM On-Prem appliance in GNS3.

• -cpu host setting is mandatory to the appliance being boot-able and install-able. Per default QEMU assigns virtual and emulated generic CPU type which breaks the installation and boot sequence right on. No installation or booting possible this way.

• Setting -enable-kvm imporves the appliance bootup and responce times significantly, much like 200% or even more.

• US keyboard layout is the default and not meant to be changed easy.

Apply these settings to be able to run CSSM in KVM/QEMU and GNS3:

-cpu host -smp 4 -enable-kvm

This will result in successful installation and running of SSM On-Prem if it is ran in GNS3.

TACACS+ protocol debug

click for more