• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

AAA

Adding Two-Factor Authentication to TACACS+

06/02/2017 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Several months ago, I covered how to add two-factor authentication (2FA) to FreeRADIUS using Google Authenticator. Today, I will cover the TACACS+ version of it.

Related: What is multi-factor authentication (MFA)?

I’ve written a blog post on how to build tac_plus server using Ubuntu. The guide was written in 2011, while it’s an old blog post, the instructions are still valid using Ubuntu Server 16.04. Please use that guide on how to build one, then use this guide to add multi-factor authentication (MFA) to TACACS+.

Related: Deploying TACACS+ on a Docker container

Installing Google Authenticator PAM

It is super easy to install Google Authenticator on Ubuntu. Below is the command we need to install Google Authenticator PAM on Ubuntu.

$ sudo apt-get install libpam-google-authenticator -y

Configure tac_plus

As mentioned earlier, the instructions in my old blog post are still valid. We’re going to use only some of them in this post for the purpose of demonstration only.

By default, the /etc/tacacs+/tac_plus.conf file looks like this:

accounting file = /var/log/tac_plus.acct
key = testing123
user = DEFAULT {
       login = PAM
       service = ppp protocol = ip {}
}

Let’s change the key and user information fields to look something like this:

accounting file = /var/log/tac_plus.acct
key = tacacskey1234
user = tacacsuser {
        member = Administrators
}
group = Administrators {
        default service = permit
        login = PAM
        enable = file /etc/passwd
}

Restart TACACS+ daemon

Since we made a change to our tac_plus config file, we need to restart the service for our changes to take effect. Issue the command below.

$ sudo /etc/init.d/tacacs_plus restart
[ ok ] Restarting tacacs_plus (via systemctl): tacacs_plus.service.

An alternative command is shown below.

$ sudo service tacacs+ restart

Generating Google Authenticator Secret Key

This step is covered in my old blog post so head over there and skip to the generating the secret key section. Alternatively, we could use the same secret key(s) from another system with Google Authenticator. However, this is not the recommended practice.

To get the secret key from another system, just copy and paste the ~/.google_authenticator file of each user, like the one below.

tacacsuser@tacplus:~$ more .google_authenticator
UXQLCMOLT2QLSMVE
" RATE_LIMIT 3 30 1436015893
" DISALLOW_REUSE 39787632
" TOTP_AUTH
55312114
13740459
80118802
81859009
79311140

If you copy and paste it to a file, make sure that the permission is set to read only.

tacacsuser@tacplus:~$ ls -l .google_authenticator
-rw-rw-r-- 1 tacacsuser tacacsuser 129 May 29 17:54 .google_authenticator
tacacsuser@tacplus:~$ chmod 400 .google_authenticator
tacacsuser@tacplus:~$ ls -l .google_authenticator
-r-------- 1 tacacsuser tacacsuser 129 May 29 17:54 .google_authenticator

Configuring TACACS+ PAM

Since we instructed tac_plus to use PAM, we now need to create a file called /etc/pam.d/tac_plus, so PAM knows what to do. The file should look like:

$ more /etc/pam.d/tac_plus
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass

IOS configuration

Before we can verify that our tac_plus config is working, let’s configure a CSR1000V router running IOS-XE.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#aaa authentication login default group tacacs+ enable
R1(config)#aaa authentication enable default group tacacs+ enable
R1(config)#aaa session-id common
R1(config)#tacacs-server host 192.168.250.250
 Warning: The cli will be deprecated soon
 'tacacs-server host 192.168.250.250'
 Please move to 'tacacs server <name>' CLI
R1(config)#tacacs-server directed-request
R1(config)#tacacs-server key tacacskey1234
R1(config)#end
R1#

While the configuration above still works, it is a good idea to move towards the new way of doing things. Here’s the new way of configuring TACACS+:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#aaa authentication login default group tacacs+ enable
R1(config)#aaa authentication enable default group tacacs+ enable
R1(config)#aaa session-id common
R1(config)#tacacs server tac_plus
R1(config-server-tacacs)# address ipv4 192.168.250.250
R1(config-server-tacacs)# key tacacskey1234
R1(config-server-tacacs)#end
R1#

Verification

This CSR1000V router is using version 15.4(2)S image. The output may vary depending on what platform and the IOS version.

$ ssh tacacsuser@192.168.250.250
Password & verification code:
R1>en
Password:
R1#

For completeness sake, I will list the passwords entered in the example above. The tacacsuser account is a valid account on the Ubuntu server running TACACS+ daemon. For example, the tacacsuser account has a password of tacacsuserpassword1234. Next, the verification code is the six-digit number displayed on Google Authenticator app. For example, the six-digit number is 567 890. With this example, the user will enter tacacsuserpassword1234567890 in the password & verification prompt.

For entering the privileged EXEC mode, we’ll again use tacacsuser’s password. If we look at the tac_plus config file, the enable = file /etc/passwd is what we defined.

Final Words

I am quite biased towards TACACS+. One of the reasons why is because of the command authorization piece. TACACS+ authentication and authorization are completely separate. That said, we could assign different command authorization level for the user or group.

With RADIUS, it combines authentication and authorization. Once the user authenticates successfully, the access-accept packet sent by RADIUS server to the device contain authorization information as well. If we configure the device similar to the example here, then the user will have full access.

To overcome RADIUS’ drawback, we could configure the device to use a local enable secret. This password is then shared only with the necessary user(s) or group(s). The issue with this approach is that the password is then a shared password. A lot of information security professionals do not like shared passwords because it is insecure.

Having said all that, I think it’s better to use TACACS+, especially with the Cisco-centric environment. While a lot of vendors support TACACS+, there might be some limitations on the authorization piece.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

How to build tac_plus server
TACACS+ (tac_plus daemon) ACL
How to configure AAA on Cisco router/switches
Enabling AAA on Cisco ASA
Deploying TACACS+ on a Docker container

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

TACACS+ (tac_plus daemon) ACL

10/29/2012 By Andrew Roderos 15 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I covered how to install and configure TACACS+ (tac_plus) on Ubuntu here. In this blog post, I am going to cover how to deny a group in accessing a network device or group of network devices. Yes, you can certainly restrict IPs using ACL on routers, switches, or ASA firewalls. However, if your security policy is to use a jump server to connect to network devices, then that jump server’s IP will not be blocked and users are still allowed. With this guide, you’ll be able to restrict access to network devices by user or group using your tac_plus server.

Configuration

This guide assumes you know how to configure TACACS+ (tac_plus) daemon. If you haven’t had a chance to work on this then please feel free to visit it here. Without further ado, here’s the configuration on how to restrict a group of users on a particular network device.

group = Test {
        default service = deny
        acl = test_acl
        service = exec {
        priv-lvl = 2
        }
}
acl = test_acl {
        deny = 192.168.12.100
        permit = .*
}

The above configuration restricts the group called Test in accessing a network device with an IP address of 192.168.12.100. The IP address that is needed in the tac_plus.conf needs to be the IP address of the source interface (ip tacacs source-interface interface_type_here) that you configured on your network device. If the TACACS+ source interface IP address doesn’t match the one in the tac_plus.conf, then any other IP address of that network device can be used to connect and the group will be allowed to access it.

Below is an example of a user that is member of the Test group trying to access the network device and was denied.

networkjutsu@tacacs:~$ ssh -l test 192.168.12.100
test@192.168.12.100's password:
Permission denied, please try again.
test@192.168.12.100's password:
Permission denied, please try again.
test@192.168.12.100's password:
Permission denied (password).

The example config below is how to restrict group(s) using regex (regular expressions). If you’re not a scripter/programmer like me then please feel free to use cheat sheet found here. For more detailed info, regex is covered in CCIE Routing and Switching Certification Guide book by Wendell Odom.

group = Test {
        default service = deny
        acl = test_acl
        service = exec {
        priv-lvl = 2
        }
}
acl = test_acl {
        deny = 172.17.99.[0-9]
        deny = 172.24.64\.50$
        permit = .*
}

Here’s an attempt of a member of Test group being denied.

networkjutsu@tacacs1:~$ ssh -l test 172.17.99.50
Password:
Password:
Password:
test@172.17.99.50's password:
Permission denied, please try again.
test@172.17.99.50's password:
Permission denied, please try again.
test@172.17.99.50's password:
Permission denied (keyboard-interactive,password).
networkjutsu@tacacs1:~$ ssh -l test 172.17.99.17
test@172.17.99.17's password:
Permission denied, please try again.
test@172.17.99.17's password:
Permission denied, please try again.
test@172.17.99.17's password:
Permission denied (password).
networkjutsu@tacacs1:~$ ssh -l test 172.17.99.3
test@172.17.99.3's password:
Permission denied, please try again.
test@172.17.99.3's password:
Permission denied, please try again.
test@172.17.99.3's password:
Permission denied (password).
networkjutsu@tacacs1:~$ ssh -l test 172.24.64.50
Password:
Password:
Password:
test@172.24.64.50's password:
Connection closed by 172.24.64.50

If you noticed, the first attempt (172.17.99.50) had more prompts than others. This might be a bug on an IOS, due to the device type, or just how this particular IOS/device behaves with the tac_plus. Unfortunately, I didn’t dig deeper enough. In any case, tac_plus denied access to the device.

With this config, it allows an organization to give out privilege access to certain users or groups but still be able to deny access to certain devices. For example, an organization may allow the NOC employees to make changes on access layer routers/switches but are not allowed to connect to distribution and core routers/switches and ASA firewalls.

Hope this has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

How to build and configure tac_plus
Adding two-factor authentication to TACACS+

Reference

TACACS+ daemon

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Enabling AAA on Cisco ASA

03/07/2012 By Andrew Roderos 7 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Enabling AAA on Cisco routers and switches were covered a while back in this guide. As previously mentioned, I am quite new to Cisco ASAs since my old environment was pure routing and switching. Firewalls were handled by IT Security and the firewalls weren’t ASAs. Having said all of that, I enjoy playing with ASAs whenever I get a chance. A couple of days ago, I started teaching myself using the CLI since I’ve always used the ASDM for making changes. I occasionally use the CLI, but not heavily since I am still a newbie in using ASAs. If you are in the same situation as I am, one of the books that are very helpful for non-full time network security engineer is Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide. I have no experience with this book so please read through the reviews to make sure it is the one you need.

As I was teaching myself on how to configure an ASA from scratch using CLI, I decided to play around with AAA since I need to get our production ASAs to communicate to our TACACS+ server anyway. After playing around with it and reading the AAA section of Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance, I came up with a configuration that will be our standard when building ASAs.

Related: How to configure tac_plus (TACACS+ daemon) on Ubuntu Server

Without further delay, here are the steps to enable AAA on ASA using CLI:

This command enables the TACACS+ protocol and use the name TACACS+ as the AAA server group.

ciscoasa (config)# aaa-server TACACS+ protocol tacacs+

To specify the maximum number of failures that will be allowed for any server in the group before that server is deactivated. The default value is three.

aaa-server TACACS+ max-failed-attempts 3

There are two different AAA server reactivation modes in ASA: timed mode and depletion mode. The command below is the timed mode. With the timed mode, it reactivates a failed server after 30 seconds of downtime. In my limited testing, it continuously tried to reactivate the server after 30 seconds when I bring the TACACS+ server down.

ciscoasa(config-aaa-server-group)# reactivation-mode timed

With the depletion mode shown below, the failed TACACS+ server will stay down until all servers in the group are in the failed state. The default deadtime is 10 minutes.

ciscoasa(config-aaa-server-group)# reactivation-mode depletion

To check the status of the TACACS+ server on a particular ASA.

ciscoasa# show aaa-server proto tacacs | i status
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012

This command specifies the TACACS+ server’s IP address. If you notice there’s a (inside) keyword in the command. This basically tells the ASA which interface to send the TACACS+ traffic. If the TACACS+ server is actually on the outside interface, then you just change it to outside. In this scenario, the TACACS+ is part of the inside network.

aaa-server TACACS+ (inside) host 192.168.100.200 tacacs-key timeout 3
aaa-server TACACS+ (inside) host 192.168.100.201 tacacs-key timeout 3

By issuing this command, it instructs the ASA to use the user’s enable password stored in the TACACS+ server first and then use the local enable password as a backup if the TACACS+ servers are unavailable.

aaa authentication enable console TACACS+ LOCAL

Don’t get confused with the keyword console and serial console. The serial is the actual physical console port in the ASA. If you do not issue this command, ASA will use the user local user database for authentication. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication serial console TACACS+ LOCAL

This is a good idea to enable if you want to manage your ASA using ASDM. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication http console TACACS+ LOCAL

This is for managing your ASA using SSH. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account. If you want to manage your ASA using telnet, just change the ssh keyword to telnet. I honestly do not recommend using telnet.

aaa authentication ssh console TACACS+ LOCAL

Once the authentication part is finished, now you need to enable the authorization. This tells the ASA what commands are available for the authenticated user. To enable authorization, issue the command below. Again, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authorization command TACACS+ LOCAL

Once done with the authorization, you may want to monitor the commands that have been issued in the ASA. To enable accounting, issue the command below. This command will only monitor issued commands that are listed in the privilege level 15. If you want to monitor all commands, feel free to change the level to 1.

aaa accounting command privilege 15 TACACS+

There you have it, a step by step guide on how to enable AAA on Cisco ASAs. There’s no good reason to not enable AAA especially if you can get the TACACS+ server for free!

I hope this has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

Related blog posts:

How to build and configure tac_plus
TACACS+ (tac_plus daemon) ACL

Reference

Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

How to configure tac_plus (TACACS+ daemon) on Ubuntu Server

10/01/2011 By Andrew Roderos 9 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

In this blog post, I will cover on how to build and configure TACACS+ on Ubuntu Server using tac_plus. While this is an old blog post, the instructions covered here are still valid in Ubuntu Server 16.04 LTS. I highly recommend that you integrate two-factor authentication (2FA) as well, which is covered here.

If you are looking for an alternative to Cisco Secure Access Control Server (ACS) and how to implement it, then you came to the right place. Since you are looking for an alternative, I think it is safe to assume that you’ve seen how much is the price tag of Cisco Secure ACS (EoS/EoL now – functionality is now on Cisco ISE) and you think it’s too expensive for your network – my quote was $17K. A lot of companies do not have a budget for something like that. The Great Recession also didn’t help since a lot more companies are tightening their belt, especially in IT projects and that’s not something new.

Related: Adding Two-Factor Authentication (2FA) to TACACS+ running on Ubuntu 16.04

Having said all of that, how can Network Engineers harden the networking devices that is also cost efficient? Well, let’s thank Cisco for that by releasing the source code of TACACS+ back in the day and of course the open source community. The source can still be downloaded from Cisco’s FTP site. Cisco has not updated this source code for probably more than a decade but Open Source community has made some changes to it so features may be better than the source code. However, if you’re just looking for a simple AAA (Authentication Authorization Accounting) then tac_plus will be fine. This is actually one of the topics in a Cisco Press book called Network Administrators Survival Guide.

Tac_plus is a TACACS+ daemon for Linux that is based on the original Cisco TACACS+ source code.

Security is paramount to any organization, so hardening the organization’s networking devices add a layer to organization’s security. A security enthusiast once told me that security is more effective if you deploy in several layers. By deploying security in layers, organizations can mitigate security risks. Cisco Secure ACS can add a layer to organization’s security by providing AAA. The appliance or software serves as NAS (Network Access Server) and it supports two security protocols, RADIUS (Remote Access Dial-In User Service) and TACACS (Terminal Access Controller Access Control Server).

Related: Deploying TACACS+ on a Docker container

The main difference between the two protocols is how they encrypt the packet. RADIUS only encrypts the password and the rest are unencrypted, so the username, authorized services, and accounting can be captured. On the other hand, TACACS+ encrypts the entire packet which is more secure. If you are tasked to deploy AAA in your organization, make sure that you opt with the TACACS+ implementation and not RADIUS.

This article will talk about how to deploy TACACS+ using the publicly available source code from Cisco. Without further delay, here’s the tutorial on how to implement TACACS+.

What’s needed

In this tutorial, you will need the following:

  • Know how to download, install, and update the latest Ubuntu Linux (latest at this time of writing is Ubuntu 11.04 – preferably  Server Edition).
  • Know how to use VI editor or any text editor under Linux environment.
  • Physical machine(s) or virtual machine(s)
  • 6GB hard drive space is more than enough. Though, if you’re concern of keeping tons of accounting logs, then please feel free to increase the size.
  • 256MB of RAM should be enough. Start small and monitor your memory usage.

Instructions

Below are the steps in successfully implementing TACACS+ to your routers and switches.

Download, Install and Update

Download, install and update Ubuntu 11.04 Server Edition on your machine(s). While one machine is enough, I suggest deploying two for backup. If getting another physical/virtual machine is an issue, then do not worry about it. There is a backup user account that will be created in this tutorial, so when the TACACS+ is not available Network Administrators/Technicians/Engineers can still authenticate and issue commands.

Download and install  TACACS+. To download TACACS+, issue the command below:

sudo apt-get install tacacs+

Edit tac_plus Configuration File

Once installed, you’re now ready to edit the tac_plus configuration file. I will try to break down the configuration file to explain what it does.

Using VI editor to edit the configuration file. Feel free to use nano or other text editors available.

admin@ubuntu:~$ vi /etc/tacacs+/tac_plus.conf

The default configuration of the TACACS+ accounting log is /var/log/tac_plus.acct. Feel free to change this to your liking. However, I suggest you change the read and write permissions using chmod, so that only certain users or groups are allowed to edit or view the file.

accounting file = /var/log/tac_plus.acct

Define TACACS+ Key

Define your TACACS+ key here. Remember this key since it will be used later on your AAA configuration.

key = tacacskey123

User Accounts And Groups

In this section, I will create three user accounts and assign them to their proper group.

#*************************
#***USERS ACCOUNTS HERE***
#*************************
user = NetworkEngineer1 {
        member = Network_Engineers
}
user = FieldTech1 {
        member = Field_Techs
}
user = Manager1 {
        member = Managers
}

In this tutorial, I will not use the built-in DES encryption of TACACS+ daemon. Due to the fact that DES has been cracked back in the late 90s. I will be using Linux’s default authentication and incorporate that to tac_plus.conf.

This section will create groups, specify their authentication method (in this case using /etc/passwd – Linux user authentication), and what authorized commands are available to the groups.

Network engineers have all commands available to them. The default service = permit parameter tells TACACS+ daemon that all commands are allowed for this group. The login = file /etc/passwd parameter tells the daemon to look for the user account and password matches in the file. If it matches, allow the account to log in to the router and switch. The enable = file /etc/passwd tells the daemon that it needs to match the password of the user account. If it matches, allow to enter privileged EXEC mode, also known as enable mode.

#*************************
#***   GROUPS HERE     ***
#*************************
group = Network_Engineers {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
}

Permissions

Field Technicians, on the other hand, has a default service = deny parameter which tells the daemon that all other commands except for user EXEC commands are allowed. Having said that, you will need to permit the commands that they’re allowed to use. Service = exec and priv-lvl = 2 allows us to give a higher privilege than an ordinary user. We do not want to give this group a privilege level of 15, meaning the same level as the network engineers. I will not explain all the parameters here since I believe they’re pretty much self-explanatory for an IT professional who knows Cisco IOS.

group = Field_Techs {
        default service = deny
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
        priv-lvl = 2
        }
        cmd = enable {
                permit .*
        }
        cmd = show {
                permit .*
        }
        cmd = do {
                permit .*
        }
        cmd = exit {
                permit .*
        }
        cmd = configure {
                permit terminal
        }
        cmd = interface {
                permit .*
        }
        cmd = shutdown {
                permit .*
        }
        cmd = no {
                permit shutdown
        }
        cmd = speed {
                permit .*
        }
        cmd = duplex {
                permit .*
        }
        cmd = write {
                permit memory
        }
        cmd = copy {
                permit running-config
        }
}

Managers are given access as well, however, the only privilege EXEC mode allowed is show running-config. Feel free to add more commands necessary for your boss and/or your boss’ boss.

group = Managers {
        default service = deny
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
        priv-lvl = 2
        }
        cmd = enable {
                permit .*
        }
        cmd = show {
                permit .*
        }
        cmd = exit {
                permit .*
        }
}

Creating a test user account and the group might be a good idea, so you can test things out that have been added to this configuration. This particular test user will only have a cleartext password.

user = test {
        member = Test_Group
}
group = Test_Group {
        default service = deny
        service = exec {
        priv-lvl = 2
        login = password1
        enable = password1
}

Restart tac_plus Daemon

Most of the time in Linux/Unix environment, you need to restart the daemon before your configuration will take effect.

admin@ubuntu:~$ sudo /etc/init.d/tacacs_plus restart
password for admin:
 * Restarting TACACS+ authentication daemon tacacs+                      [ OK ]
admin@ubuntu:~$

User Accounts

It is now time to create the user account under Linux.

admin@ubuntu:~$ sudo adduser test
Adding user `test' ...
Adding new group `test' (1001) ...
Adding new user `test' (1001) with group `test' ...
The home directory `/home/test' already exists.  Not copying from `/etc/skel'.
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
	Full Name []:
	Room Number []:
	Work Phone []:
	Home Phone []:
	Other []:
Is the information correct? [Y/n] y

Change Password

For the password, please use the organization’s standard on default passwords. Always remind the users to change their password when they first log in. To change the password, have the user issue the command below.

test@ubuntu:~$ passwd
Changing password for test.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

If I am showing you how to add a Linux user account, then I should be showing you how to remove an account as well, since all organizations lose good and/or bad employees all the time. Not deleting an account is a big no-no and obviously a huge security risk.

admin@ubuntu:~$ sudo deluser test
 password for admin: Removing user `test' ... Warning: group `test' has no more members. Done.

Changing IP Address

When you first install Ubuntu, it uses DHCP and that’s not a great idea for a server – at the time of writing. You will need to change the IP configuration on this server, so you can specify the IP of the TACACS server(s) on routers and switches.

admin@ubuntu:~$ sudo vi /etc/network/interfaces

Look for the following:

# The primary network interface
auto eth0
iface eth0 inet dhcp

Once found, change it to something similar:

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.10.100
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.254

Again, if you change something it needs to be restarted.

admin@ubuntu:~$ sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces...                                   [ OK ]
admin@ubuntu:~$

If you chose to have two TACACS+ servers and you used a VM, then you don’t need to do a whole lot. Just clone your TACACS+ VM, change the hostname and IP address and you’re done. Make sure your two TACACS+ VMs are not on the same physical host, so your implementation is fault tolerant.

Cisco Configuration

The how to configure AAA on Cisco routers and switches is covered here and the how to configure AAA on Cisco ASA is covered here. To create ACL on tac_plus, please see this post.

Final Words

TACACS+ is now ready to go. Congratulations, you just accomplished one part of hardening your organization’s networking devices!

Do not be afraid of Linux. There are a lot of freebies out there that can help your organization to save money on network tools and etc. Being free, it won’t be as fancy as the paid software but it will get the job done.

I hope this tutorial has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

TACACS+ (tac_plus daemon) ACL
Adding two-factor authentication (2FA) to TACACS+
How to configure AAA on Cisco router/switches
Enabling AAA on Cisco ASA

Reference

TACACS+ and RADIUS Comparison

Want to learn more about AAA?

AAA Identity Management Security

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

How to configure AAA on Cisco router/switches

10/01/2011 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I talked about tac_plus here which talks about how to build and configure TACACS+ server. In this blog post, I will cover how to configure AAA on Cisco routers and switches that worked in conjunction with the tac_plus covered in the previous blog.

Backup Local Account

I think the first important step before enabling AAA on Cisco routers and switches is to create a backup local account. Though, one could also configure the device to just use the enable secret as a way to log in. I personally prefer the local account.

username backup password strongpassword

Pointing Cisco device to TACACS+ server

Once local user account is configured, you also need to point your networking devices to the TACACS+ server.

tacacs-server host 192.168.10.100
tacacs-server host 192.168.10.101
!
tacacs-server directed-request
tacacs-server key tacacskey123

Configuring AAA

Now, you’re going to configure the AAA to our networking devices. Start by enabling AAA in the global configuration mode

aaa new-model

These two lines enable authentication part and will tell our networking devices to use TACACS first before using local account. Should both of your TACACS+ servers go down, allow local user account to be used.

aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable

These commands enable the authorizing commands for the user or group. In some TACACS+ implementation, you do not need to use aaa authorization commands 0 default group tacacs+ none but for our implementation, we’re going to include it.

aaa authorization commands 0 default group tacacs+ none
aaa authorization commands 15 default group tacacs+ none
aaa authorization config-commands

These commands will start recording what commands are being issued to our networking devices. If you do not have a tool for tracking configuration changes like RANCID, then this can be a valuable tool to see what was done. However, reading the accounting log in the TACACS+ is messy. I suggest you implement RANCID if the organization does not have tools like AlterPoint Network Authority or Solarwinds Network Configuration Manager.

aaa accounting update newinfo periodic 5
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting send stop-record authentication failure
aaa accounting network default start-stop group tacacs+
aaa session-id common

Now, we need to pick a source interface on how to talk to our TACACS+ server. There are scenarios where our routers and/or multilayer switches have two or more links going to our data center, so using a loopback is always a good idea. For layer two switches, our management VLAN interface will be just fine.

ip tacacs source-interface loopback0

Congratulations, you just accomplished one part of hardening your organization’s networking devices!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

How to configure tac_plus (TACACS+ daemon) on Ubuntu Server
TACACS+ (tac_plus daemon) ACL
Adding two-factor authentication (2FA) to TACACS+

Want to learn more about AAA?

AAA Identity Management Security

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use