Meet us at Cisco Live Las Vegas 2024

Companies are spending big money on defensive measures against the outside attackers — investing into Next-Generation Firewalls, Intrusion Prevention Systems and Proxies. The inner network, however, was considered safe place, where nothing bad can happen.

This understanding has thankfully changed in recent years, especially with rise of mobility technologies allowing employees to work anywhere and concepts like Bring Your Own Device (and some major incidents as well, of course). Today's network administrator has to think about various types of devices connecting to the internal network and policy, how to treat them to keep the internal network and business critical systems safe.


Solution

Solution to this problem is to deploy network wide 802.1 x protocol, that allows the user to access the network just if he is able to authenticate himself using a username and password, or a valid certificate issued by the company. Various options are available and listing all the details would be worth a book.

It is not always straightforward deployment, as these types of projects tend to be slow and need proper user testing, because otherwise the users won't be able to work at all. Usually there are user machine issues that need to be rectified temporarily by disabling the 802.1 x protocol authentication on the switchport of the affected user and after couple days, no one knows, where the security is applied and where it is not.


Verification

With IP Fabric's platform, finding information about the ports secured by 802.1 x protocol is easy, and you can specify verification to tell you which network edge ports, connecting to end stations, are open and which are secured properly. For example, simple verification could do this:

Setup is actually trivial, with the most complicated part being the selection of what is physical and what is virtual interface. Good news is, that we've configured this already for you. The actual outcome of this verification looks like this:

802.1 x protocol Interfaces Verification
802.1x Interfaces Verification

Instead of manually verifying every interface or developing custom script for every platform out there, hundreds of hours of engineering time can be saved using this continuous verification instead. Also, it can be used as an evidence of how the 802.1 x protocol rollout project is proceeding and that the network is properly secured and there are no open interfaces, that would render your network insecure.

This will ensure the setup of the Interfaces on all devices in the network. In regards to the other part — RADIUS server configuration — this was covered in one of the recent articles, so you may check it out to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

Authentication, Authorization, and Accounting, otherwise known as AAA, or Triple A.

Many individuals who have had to implement AAA on a router or a switch most likely have little knowledge regarding the commands that they copy to the router configuration. Most will simply utilize the AAA configurations from another functioning router or switch. Today, we are going to analyze the best AAA practices and how one can ensure its proper setting with our IP Fabric's platform.

For those who are working with a larger network environment, you are most likely using a form of TACACS+ or ACS server running that is specifically designed for the management of logins to your devices. AAA works in unison with TACACS+ to provide efficient management of your logins’ security. In other words, this monitors who is able to log in (Authentication), what that user can do (Authorization), as well as track the commands that are used (Accounting). In the instance of server failure or reachability issues, it is recommended to have a backup local login user name and password that will allow access to your devices.


We shall now analyze what is considered the best practices for configuration.

aaa new-model
tacacs server ACS1
address ipv4 1.1.1.1
key 0 SECRET-KEY
tacacs server ACS2
address ipv4 2.2.2.2
key 0 SECRET-KEY
aaa group server tacacs+ ACS
server name ACS1
server name ACS2
aaa authentication login default group ACS local
aaa authentication enable default group ACS enable
aaa authorization config-commands
aaa authorization exec default group ACS local if-authenticated
aaa authorization commands 1 default group ACS if-authenticated
aaa authorization commands 15 default group ACS local if-authenticated
aaa accounting exec default start-stop group ACS
aaa accounting commands 1 default start-stop group ACS
aaa accounting commands 15 default start-stop group ACS

Upon dissecting this model by line, we have:

aaa new-model

This new-model essentially turns on the AAA functionality on the network device.

tacacs server <name>

This addresses the setup of the TACACS server details, such as the IP address, shared key, and all other optional details.

aaa group server tacacs+ <group_name>

This is intended for the grouping of specific servers into logical groups.

aaa authentication login default group ACS local

Here, we define how the device is authenticating the users who attempt to log into the device. First, there is the default authentication method with group of TACACS+ servers named “ACS”. Then, if it is unreachable, we shall implement the locally configured user account list.

aaa authentication enable default group ACS enable

This component explains that, for enable mode, the default authentication method with group of TACACS+ servers named “ACS” should be utilized.

aaa authorization config-commands

This is regarding our goal to authorize each command that is being issued to the device.

aaa authorization exec default group ACS local if-authenticated

This sets up the device and places the user directly into enable mode, upon his authentication (the if-authenticated keyword).

aaa authorization commands 1 default group ACS if-authenticated

In this command, we are authorizing the level 1 user commands, which is similar to the non-enable mode.

aaa authorization commands 15 default group ACS local if-authenticated

Here, we are providing authorization for level 15 users against TACACS+. If TACACS+ is unavailable, then the local user account is used, instead. Upon authentication, the user will immediately be placed into exec/enable mode.

aaa accounting exec default start-stop group ACS

AAA Accounting ensures the logging in and access into the device.

aaa accounting commands 1 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 1 commands.

aaa accounting commands 15 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 15 commands.

This provides tracking of user activity on a device, even if they have just logged in.


As you can see from this basic configuration, there is significant variability, resulting in complications of the verification of the proper function. This worsens with regular network operations, when the connectivity to the TACACS server fails, requiring a troubleshoot to determine the error. In such a situation, one would usually remove the TACACS configuration in attempt to resolve the issue. However, during the troubleshoot, it is common to forget about this change and leave the network open with local authentication or, perhaps, no authentication, whatsoever. Luckily, IP Fabric offers the newly released AAA verification, which can be used for the verification of the real live AAA settings.

AAA intent verification tables
AAA intent verification tables

Although our platform includes a few “out of the box” reports, we highly recommend adjusting these default reports in color with your custom verification checks, since the AAA settings differ between various companies. We recommend that you observe and spend time on the following:

For example, let us assume that we want to set up the verification report for the Authentication methods to verify this:

which would be equivalent of the following piece of configuration

aaa authentication login default group ABACS localaaa authentication enable default group ABACS enable

It is generally recommended to have a single detection for all issues on the particular AAA method and to reveal the issue count on the dashboard.

This can be configured in the following manner:

For a more detailed overview of how to set this up, view the video below:

AAA Authentication catch-all-errors rule setting
AAA Authentication catch-all-errors rule setting

Proceed to colorize the columns with specific details to green or orange, so that you will immediately see what is wrong from the dashboard counter created previously. In our case, we would need to setup additional rules as follows:

AAA Authentication Secondary method would look like this:

Secondary method verification for AAA Authentication tab
Secondary method verification for AAA Authentication tab

This will ensure the setup of the Authentication on all devices in the network. In regards to the remaining tabs (servers, lines, authorization, and accounting), you may follow the same logic to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

As a follow-up for previously published tips for first network discovery, we’ll get into some of the details about using basic authentication features and some troubleshooting tips when it discovery itself fails.

Configuring network infrastructure access is mandatory in IP Fabric from the start and we cannot begin discovery without it. We have to have username and password at least. While enable password is optional, so is setting up various credentials per subnet, but can be a great help when not all devices are properly prepared for TACACS+ or other.

Successful Network Discovery
IMG1: Successful discovery

One of many great features are Connectivity Report and Error Summary console. When used together, troubleshooting becomes an easy part of every discovery. The Error Summary provides us with information related to network command failure, timeout issues and help us furthermore investigate why certain command did not provide convenient output etc. On the other hand, the Connectivity report is focused primarily on connectivity issues and is even logging successful attempts.

In my current modified view, I wanted to see a list of currently discovered devices with no issues. I am able to download CLI Output, which was seen by IP Fabric and more.

1*dsvFaDhj1yYMIhT4DP5DKg
IMG2: Connectivity report

The use case

We are going to check if order of multiple username entries matters. The lab is similar to what we had in previous article tips. In the first test, I properly introduced credentials to IP Fabric with USER789, which is the same one I’m using on my network right now. First set is being applied for subnet 10.241.255.0/24. Second username is completely incorrect and shouldn’t be able to connect to device with IP 10.241.255.10.

Authentication configuration per subnet
IMG3: Authentication configuration per subnet

I purposely filtered networks to be included, narrowed it down to only 10.241.255.56/32, to have a straight result. As we can see in following report, device was successfully discovered, which means USER789 was used for mentioned subnet.

Connectivity report
IMG4: Connectivity report

Troubleshooting invalid authentication

Let’s see how to troubleshoot improper authentication in place by completely deleting only the first user (USER789) in the list and let’s try to run discovery again. Unfortunately, IP Fabric wasn’t able to see any device. The best is to check with ‘Connectivity report’. From the output is very easy to determine, what’s gone wrong, as ‘Authentication error’ speaks for itself!

Failed authentication
IMG5: Failed authentication

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
IP Fabric, Inc.
115 BROADWAY, 5th Floor
NEW YORK NY, 10006
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 617-821-3639
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric, Inc. © 2024 All Rights Reserved