tacacstrianingforwirelessnetworkengineers

What are we trying to accomplish?
Where you should be in your TACACS+ journey after this
slide deck
This is not meant to be completely comprehensive deck
on TACACS+ and Cloudpath. We will get you started!
This deck is meant to build on each step, so don’t expect
to be able to start at slide 23 and complete this if this is
your first time through it.
Code used in presentation:
SZ Version used = 5.2.1.0.515
ICX = 7150 Router Code 80.95ba

TACACS+
Provides Authentication, Authorization, and Accounting
for access to Network Devices.
Provides centralized authentication and identify access
management to network devices.
Supported in ICX and SmartZone (as well as other
network devices)
Allows per-command authorization (as a network user,
these are the commands I am allowed to run); precise
access control
Allows accounting to log all user commands
Encrypt all traffic
Network Admin
1. Connects to Network Device
for Administration
2. Switch forwards
authentication to TACACS+
server
3. Returns accept/reject
Policies, command authorization

RADIUS vs TACACS+
https://www.networkworld.com/article/2838882/radius-versus-tacacs.html
RADIUS TACACS+
Protocol and
Port(s) Used
UDP: 1812 & 1813
-or- UDP: 1645 & 1646
TCP: 49
Encryption Encrypts only the Password Field Encrypts the entire payload
Authentication &
Authorization
Combines Authentication and
Authorization
Separates Authentication &
Authorization
Primary Use Network Access Device Administration

Building Blocks
1. TACACS+ does not ensure that what you are entering is VALID for your configuration. It will accept any
typos no matter what.
Ex: Setting a privilege level for a USER or a GROUP.
ICX uses the command “set foundry-privlvl x”
• If you entered in by accident “set foundrypriv-lvl x” Cloudpath will allow you to enter
that command, but ICX will not understand it
2. Extensive Documentation is available here TACACS+ (pro-bono-publico.de)
3. Certain commands can ONLY be entered in a certain context. For instance, setting the foundry-privlvl
command can be entered in for a USER a GROUP and a SERVICE. You cannot set that in the ACL context.
4. Things can be TEMPLATED and BUILT on each other. In the documentation there is extensive writeups on
these.
5. Cloudpath TACACS+ server is device agnostic! We encourage you to use it for RUCKUS deployments but
can be used with other manufacturers as well. This guide covers ICX and SZ

TACACS+ Menu
Configuration Profiles Status and Profiles are listed here
TACACS+ Devices Your end devices
Access Control Time Specification and ACLs
TACACS+ Services Services that a user and group can use
TACACS+ Users Defined Users and Groups
Authentication Backends LDAP Server listed here
NOTE: You must create an apply a configuration profile before TACACS+ is useable. Please follow slides to create one.
TACACS+ (pro-bono-publico.de) -> Documentation for TACACS+ Daemon

LDAP Authentication Server
Cloudpath only supports a LDAP as authentication server. This needs to be setup first.

Add LDAP Auth Server
Type Configuration Details
Display Name Enter a memorable name, this will be used when
building the configuration profile
Description Description of the server(s)
LDAP Server Type
(setup the schema)
Choose from:
• Microsoft – If you are using Active Directory
• Generic – No LDAP modification, only
authenticates user does not authorize them
• Tacacs_schema – if using OpenLDAP or FedoraDS
LDAP Host Enter in the IP address or hostname of the server or
servers. Can have multiple servers in this field,
seperated by a <space>
LDAP DN Where to start the search from, this is considred the
BASE search
LDAP Scope • Sub – Start from base and include all
subordinates
• Base – only search in the base
• One – only children of the base entry should be
considered and not the base itself
Bind Username: Username for lookups
Bind User Password: Password for the Bind Username

Test LDAP Authentication backend

Results of Test
RESULT
ERR LDAP Connection Error
NFD LDAP User not found
NAK LDAP User found, but password is incorrect or
user is not member of any TACACS Group
ACK LDAP user found and you can see Groups
(TACMEMBER)

After Successful Auth; let’s configure Devices!
In Device Configuration, you set up which devices can connect, or which network can
connect, their shared key, prompts, etc…
These pertain to the Device.

Add a Device
Type Configuration Details
Display Name Enter the name, this is used for reference when
building the configuration profile, must contain
no spaces
Description Memorable Description
Device Context This is where we add the host address, the
shared key, prompt and an enable password.

Device Configuration Example
Simple Device configuration shows:
Host has a network address of 10.100.0.0/16
The shared key between that network and the TACACS+ server is “ruckus123”
If you are using special characters, you can put the passphrase in quotes, this will allow you to enter it in.

Let us configure a Service… SKIP Access Control, we will
come back to that in a later topic

Create a service that is basic and allows SUPER USER
privileges Topic Configuration Details
Display Name No Spaces
Service Type shell is default, leave this as “shell”. Do not
put in “exec”, this will not work with ICX,
leave this as “shell”
Service Context: Privilege Levels are defined here, but you can
define other things such as ACL, messages.
Let’s just define the privilege level now.
Value for non-"foundry-privlvl" A-V pair RUCKUS privilege level
15 0 (super-user)
From 14 - 1 4 (port-config)
Any other number or 0 5 (read-only)
Note: You can set “priv-lvl” instead of
“foundry-privlvl” ICX will
automatically translate it to the ICX
level.

Create a USER and APPLY the Service that you created

Create the User; Add the Service
Topic Configuration Details
User Context You can configure Command Authorization
here, as well as other attributes that
Service Context You created a service in the previous step,
click the drop-down box to select the
previous service item

Congratulations!
You have now created a TACACS+ configuration, this will enable a single user (John1 in my case) access to
the switches on the network 10.100.0.0/16. When they login they will be a “super-user”.
Let’s apply the configuration now in TACACS+. We will create a new Configuration Profile, Test It, then
Apply it.
NOTE: you can have MULTIPLE configuration files available, HOWEVER only 1 is active at a time.

Configuration Profile
LDAP Authentication
Backend:
Select your authentication server backend
TACACS+ Devices: Select your Device(s) that you created.
TACACS+ Timespec: Time templates that are created
Access Control Lists: Select your ACLs that you had created
TACACS+ Groups User Groups, if created are selected here
TACACS+ Users Users, selected here
NOTE: The “+” button allows you to add multiple devices; we will be
adding to this configuration

Configuration Profiles
Press this to TEST your configuration. If
you are missing anything or there are
dependencies on the configuration, then
the test will show here
Apply this configuration to
TACACS+ here. You can have
multiple profiles, but only 1 is
active at a time.

ICX Configuration
Configure TACACS+ HOST and KEY values first (all in context of “config t”:
Configure the Switch to use TACACS+ server for Authentication:
Command Description
tacacs-server host 10.100.0.2 Set Cloudpath IP as TACACS+ server
tacacs-server key <shared key> Shared key that you set in the HOST setting previously
Command Description
aaa authorization exec default
tacacs+
Allow TACACS+ user to use EXEC (Shell) access
aaa authentication login default
tacacs+ local
Authentication order for login, switch will use TACACS+ first followed by a local user
aaa authentication login privilege-
mode
User will automatically be logged into priviledge mode after a successful aaa authentication
aaa accounting commands 0 default
start-stop tacacs+
Send TACACS+ accounting for commands
aaa accounting exec default start-
stop tacacs+
Send TACACS+ accounting for EXEC (Shell) commands
aaa accounting system default Send TACACS+ accounting for system level (reboot etc…) commands

TEST!
Open a SSH session to your ICX switch, login with your username/credentials from your LDAP server.
C:Hopes and Dreams>ssh john1@10.100.0.254
Password:
SSH@TACACS+#
//use the command “show who” to show the user that is currently logged in and their privilege
level that you created:
SSH connections (inbound):
2 established, client ip address 192.168.200.220, server hostkey RSA, user is john1,
privilege super-user using vrf default-vrf.
you are connecting to this session
5 second(s) in idle

TEST Continued – Accounting Packets

Expanding Functionality
We will now add a GROUP for READ ONLY view; any user that is a part of this GROUP will be allowed access to
the ICX Lab switches, but ONLY given READ ONLY view
You will be required to have a GROUP created in LDAP. TACACS+ will utilize this group when doing
Authentication. If the user is part of this group, they will be granted READ ONLY access to the ICX switch.
In this example, I have a “helpdesk1”user defined in AD and
they are part of the “level1-tac” group in AD. This is the
group that we will use in the TACACS+ configuration.
We do NOT need to define the “helpdesk1” user at all in
TACACS+ configuration. The helpdesk1 user will be granted
access based on the group membership

Create a new TACACS+ Service
This will create a service that is READ ONLY, now lets create the GROUP to leverage it

Services updated
You should have 2 services. If you see, there is an X beside read_only and a stop sign
beside Super_User. That is because Super_User is referenced by a configuration
profile. Want to delete it; remove it from the configuration profile first.
Currently In Use; cannot delete

Create a GROUP in TACACS+ Configuration
Match your LDAP/AD Group
Select the service you just created

New Group
You will have created a Group. You do NOT have to create a USER in that group in
TACACS+. Once TACACS+ looks to the authentication server, it will scrape the Groups, if
your user is part of this group it will assign it here.

Configuration Profiles
Let’s modify the configuration profile
Manage this configuration profile

Add your Group to your Configuration Profile

Verify and Apply your Configuration … TEST!
After changing your configuration, you need to REAPPLY it… don’t forget to test on you ICX Switch.
C:Hopes and Dreams>ssh helpdesk1@10.100.0.254
Password:
SSH@TACACS+#show who
2 established, client ip address 192.168.200.220,
server hostkey RSA, user is helpdesk1, privilege read-
only
using vrf default-vrf.
1 second(s) in idle
Verify configuration
button before
deploying it

LOCAL Accounts
If you want to demo functionality, Cloudpath’s TACACS+ server allows you to create a local user.
Let’s create a port-configuration user only, that is local to Cloudpath’s TACACS+ server, so for demoing you do not need to
have an Auth Server.
Let’s GO!

Local User – Demo Purposes – Port Control ONLY (foundry-prvlvl = 4)
LDAP Authentication
Backend:
Select your authentication server backend
User Context: Set the password with the command login = clear “password”.
This can be hashed using the switch “crypt” instead of clear.
You can also add SERVICES here without predefining it.
Assign Service to User: Services pre-defined in previous step can be added here.
NOTE: We created the SERVICE context within the user. You can apply this to any user that you created! So,
no need to add it here. In the example above, we could of created a separate Service and assigned it with
the “+” sign. But we defined it here as “set foundry-privlvl = 4” which is port config only.

Add the user to your configuration:
Add the user using the + button.
Save this and APPLY it!

Test! – User is only allowd
show who
2 established, client ip address 192.168.200.220, server hostkey RSA, user
is demo_user, privilege port-config
using vrf default-vrf.
2 second(s) in idle
SSH@TACACS+(config)#
end End Configuration level and go to
Privileged
level
exit Exit current level
interface Port commands
no Undo/disable commands
quit Exit to User level
show Show system information
<cr>
**NOTE: Limited commands available to the port-config user “helpdesk1”**

Add some User Limits!
We can use TIMESPEC to allow/disallow users for a specific time.

Enter in Time Specifics
ChangeWindow
- From 22:00 to 23:00
- Any Day of the month
- Any Month
- Only available on Saturday

Apply TimeSpec to an ACL
ACL context:
Specify your ACL with context such as:
time = timespec name that we specified previously
nac = the client originating IP address
nas = device destination IP address

Apply the ACL to a user
Let’s create a new user that is local, that is tied to that ACL.
Training wheels off here… this is what you should create, make sure you ADD the user to your configuration profile and
APPLY it.
If you get an ERROR when applying it, MAKE SURE you have added the timespec and ACL into your configuration profile

Hint Slide for Configuration Profile

Test!
SSH to the switch and see what happens! Make sure your ACL is correct, ensure that your timespec setting is correct. If
you run into problems, try stripping down the ACL and figure out where you went wrong. Also, check the logs in
Cloudpath.
Destination IP
User
Source IP
Details

Command Authorization
TACACS+ supports Command Authorization, let’s create a new SERVICE that users can use that only allows them
certain access to commands.
On ICX enable COMMAND AUTHORIZATION
aaa authorization commands 0 default tacacs+ //command authorization for Super-Users
Let’s modify our changewindow_user to use command authorization to be allowed to:
1. Enable/Disable inline power on a port
2. Create only VLAN 800
3. ONLY allow ethernet port 1/1/1 to be configured

Edit the POE servce
I’ve edited the POE_Only service that we created previously, gave it a new name and added commands
that are permitted. By default, any commands not explicitly permitted are denied.

Users Info Page
You can see that you do not have to edit the user “changewindow_user”, the configuration did all of
this for you, you just need to APPLY the configuration… go do this now.

Test!
C:Hopes and Dreams>ssh changewindow_user@10.100.0.254
Password:
SSH@TACACS+#show run
Not authorized to execute this command.
SSH@TACACS+#wr me
SSH@TACACS+#config t
SSH@TACACS+(config)#vlan 699
SSH@TACACS+(config-vlan-800)#untag e 1/1/1
Added untagged port(s) ethe 1/1/1 to port-vlan 800.
SSH@TACACS+(config-vlan-800)#exit
SSH@TACACS+(config)#no inline power ethernet 1/1/1
SSH@TACACS+(config)#inline power ethernet 1/1/1
SSH@TACACS+(config-vlan-800)#untag e 1/1/9
SSH@TACACS+(config-vlan-800)#no inline power ethernet 1/1/2
//As you can see, the user cannot do a show run or a wr me
//User can only create the VLAN 800
//User can only add the VLAN to port 1/1/1
//inline power can only be manipulated on eth 1/1/1

Authorization Logs
2020-12-21 16:34:56 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny show running-config <cr>
2020-12-21 16:34:59 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny write memory <cr>
2020-12-21 16:35:02 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit configure terminal <cr>
2020-12-21 16:35:09 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny vlan 699 <cr>
2020-12-21 16:35:12 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit vlan 800 <cr>
2020-12-21 16:35:16 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit untagged ethernet 1/1/1 <cr>
2020-12-21 16:35:31 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit inline power ethernet 1/1/1 <cr>
2020-12-21 16:35:35 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit inline power ethernet 1/1/1 <cr>
2020-12-21 16:35:40 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 permit vlan 800 <cr>
2020-12-21 16:35:47 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny untagged ethernet 1/1/9 <cr>
2020-12-21 16:36:12 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny show who <cr>
2020-12-21 16:39:25 -0500 10.100.0.254 changewindow_user tty17 192.168.200.220 deny inline power ethernet 1/1/2 <cr>

A note about Command Authorization
If you recall, we had already a super-user called “john1”. We have enabled Command Authorization for privlvl =
0, which john1 is part of, logging in and trying to run commands, john1 receives the following messages from the
switch:
SSH@TACACS+#show run
SSH@TACACS+#conf t
Let’s fix the user john1. We will add the simple command of “default command = permit” to john1’s service:
*apply config after adding this

What if WE ONLY want the user to be able to use those
commands during a certain stop and start dates
In the user and group configuration items, you can add the statement(s)
“valid from = yyyy-mm-dd” and / or “valid until = yyyy-mm-dd” to setup access times.
Example: today is 2020-12-21, I have configured the user to ONLY have access between 2020-12-23 and 2020-12-
25. If a user tries to logon, they are unable to:
C:Hopes and Dreams>ssh changewindow_user@10.100.0.254
Password:
Password:
Password:
changewindow_user@10.100.0.254's password:
Received disconnect from 10.100.0.254 port 22:11: Too many password authentication attempts from
user
Disconnected from 10.100.0.254 port 22

Service…
This is where we define things that the user can access or not access, or how their shell looks… In this PPT we used it to
setup default access and commands for command authorization. What services the SHELL for that user can support.
Can be defined at the SERVICE level. If you
notice, the syntax is different, no need to use
service = shell {set foundrypriv-lvl = 0}, the
syntax is predefined
Create a predefined Service Level
Apply to a user
and or a group

Service… OR Manually Create it in a USER or a GROUP
If you create it in the USER and GROUP context, no need to apply the service as well

But what If I create them in multiple spots and apply
them???
Look at the VERIFY
configuration, the
Configuration should be
applied top down. Lets look
at JOHN1 who has been
manipulated to have
foundrypriv-lvl 0,4 and 5 at
different levels.
Group level set to port config only
User level configured to read-only
As a service definition applied to the USER
*John1 login result:

Your configuration profile contains all your elements for that TACACS+ to work. If
you make a mistake and not add a component, your configuration profile will tell
you all about it. It is important to understand this relationship. If I referenced a
GROUP in the USER configuration, if I do not add it in the Configuration Profile, it
would error out.

No Group In Configuration
Added the user “helpdesk”
Helpdesk was configured with a group, but I
did not add it to the configuration .

Use the VERIFY button before deploying to TEST
Cloudpath will let you know if you made a mistake and prompt you with
what this mistake maybe (for us, a missing group that the user was being
referenced by).

SZ Admin With TACACS+
SmartZone can use TACACS+ for Admin AAA. Let’s set one up!

Add Cloudpath as a TACACS+ Server
This has to match you SERVICE
DECLARATION IN CLOUDPATH
Disable this, we will use TACACS+ to
put a user into a defined role in
SmartZone

Create a Group and a User to MAP to in SmartZone

Modify Permissions if you require

Add or Create a user(s)
If you have a user, you can add
them here, if not you can create
one here by pressing the “+”
button.
We will create a new user

Create a user
This is the name that we will use to
MAP users to in Cloudpath TACACS+
configuration.
We are not technically using this account
to login, so this password can be
anything.

TACACS+ Configuration
For this, we are going to create a new Group. Within the Group Context, we are going to configure the Service Declaration
to map to SmartZone. We will then put a local user into that Group, but you can use LDAP as well.

Configure the Group
Can be any value; make it meaningful
Remember the SZ REALM? The “service
= smartzone realm” must be the same.
The SZ administrator that we
just created that is part of the
readonly_users group in SZ.
We do not need to define any
services, we did it in the
context of the group

Create a user and make it a member of the new group
User LOGIN name
TACACS+ Group membership
and Password

Add to your configuration and apply the profile!

Test!!
You need to add your realm, this test has:
“sz_readonly_admin@readonly” as the user name.
If you have done everything correctly, you will get the
response stating that the user is associated with the
correct SZ User; readonly_account.
If not, you will get a message stating that the AAA was
a success, but the user is NOT mapped to a SZ account.
Check your REALM; make sure that it MATCHES in
Cloudpath’s SERVICE DECLARATION

Logs
SZ Admin Activities Log
Cloudpath TACACS+ Authentication Log

Troubleshooting
telnet@TACACS+>show aaa
TACACS default key: ...
TACACS retries: 3
TACACS timeout: 3 seconds
TACACS+ Server: IP=10.100.0.2 Port=49 Usage=any Key=
opens=695 closes=663 timeouts=14 errors=18
packets in=800 packets out=800
You can modify the RETRY and TIMEOUT interval in ICX using these commands:
tacacs-server retransmit 5
tacacs-server timeout 5
telnet@TACACS+>show web
HTTP server status: Enabled
HTTPS server status: Enabled
Web management Sessions:
User Privilege IP address Timeout(secs) Connection
demo_user super-user 192.168.200.150 239 HTTP

tacacstrianingforwirelessnetworkengineers

More Related Content

Similar to tacacstrianingforwirelessnetworkengineers

Recently uploaded

tacacstrianingforwirelessnetworkengineers