Cisco Nexus

27 10 2011

The nexus seems to asks for pap authentication. I have no clue why, but adding a simple “pap = des -hash-” to your tac_plus makes it work. (doesn’t seem to be necessary if you are setting a default authentication)

Tacacs on Nexus is different. However, you can still continue to use tacacs the way you always have. Example configuration is as such:

tacacs-server key -key-
tacacs-server host -host-
aaa group server tacacs+ private
    server -host, yes again-
    use-vrf management
    source-interface mgmt0
aaa authentication login default group private
aaa authorization config-commands default group private
aaa authorization commands default group private
aaa accounting default group private

Gone are the priviledge levels, but adding a simple “conf t.*” to the denied commands in do_auth accomplishes pretty much the same thing.

Cisco changed the tac keys. (Because… standardization is bad?) They also changed the accounting format, meaning I had to rewrite my search cgi. (post if you are interested in front end to search log) Hence, a new version of do_auth.

v1.8 http://pastie.org/2769727

If anybody has any luck successfully passing roles to the nexus, please post on the tac_plus list.



do_auth – av_pairs

7 09 2011

One of the long promised features has finally been added, the ability to modify av pairs. Let’s say you have a group which you simply want a user to have enable access to. Simply add this to the group:

av_pairs =
    priv-lvl=1

This assumes you have priv-lvl in your tac_plus.conf. (Like examples previous) Note, of course, you’ll also need to add a command_deny for enable or they’ll just type ‘en’ if they have an enable password. Now, this should open all sorts of opportunities for wlc and roles. For reasons unknown, this does not work. If you have a wlc that you can lab up & wireshark, please contact me on the tac_plus listserv.

v1.7 http://www.pastie.org/2499657

One last thing, don’t use v1.6 – it had a bug. Also sorry if you’re comments don’t get approved, apparently I don’t have rights to do that.



Password Hash CGI

26 08 2011

I threw this cgi together quick so users could send me a SHA-512 hashed password generated from a webpage instead of command line. (For use in tac_plus) Suggestions welcome.

http://pastie.org/2433995



New do_auth (again)

23 08 2011

I finally got a chance to play with some tac pairs that weren’t exec=shell when I needed to put tacacs on the cisco wireless controller. (See post below, it uses the concept of “roles” which can be looked up) Had to make adjustments to make sure the keys set in tac_plus.conf worked. New code here:

V 1.6 – removed



Misc TACACS+ questions

6 07 2011

I’ve received a couple of comments posing questions, but they’ve been hiding out on the “About” page.   I’m going to move them to this post so others can see and answer.

This is hopefully where new questions can be posed.



Brocade

16 03 2011

My first time putting tacacs on a Brocade. Pretty similar to cisco, the tac pairs that cisco use seem to work just fine. Worked great with do_auth. Keep in mind, although they honor priv-15, they map it to 0, just to be different. I used the following:

username admin password yerpasswordhere
ip tacacs source-interface loopback 1
tacacs-server retransmit 2
tacacs-server timeout 2
tacacs-server host yerhosthere
tacacs-server key yerkeyhere
enable super-user-password againpasswordhere
aaa authentication login default tacacs+ enable
aaa authentication login privilege-mode
aaa authentication enable default tacacs+ enable
aaa authorization commands 0 default tacacs+ none
aaa authorization exec default tacacs+
aaa accounting commands 0 default start-stop tacacs+
aaa accounting exec default start-stop tacacs+
enable aaa console



Securing Rancid with do_auth

2 03 2011

Rancid can be made much more secure by using doauth. A quick example of the doauth.ini file is as follows:

[users]
rancid =
     rancidaccess
[rancid
access]
hostallow =
     10.0.0.1
device
permit =
     .*
command_permit =
     show.*
     dir.*
     more.*
     write t.*

Now, rancid can only login from 10.0.0.1, and only type commands that match those regular expressions. Technically, you could limit the commands in tacplus.conf without doauth. Might take longer, but you could do it. However, you could not limit it to 10.0.0.1 without an after authorization script such as do_auth.

NOTE: This assumes you only authorize config/Level 15 commands. I never authorize level 1 commands or, heaven forbid, level 0 commands as these commands can not change anything on the router, nor allow you to see the configuration. Now, if YOU choose to do so, the above example will still probably work. A quick look at log.txt will tell you any additional commands you will need to add.



Easier Tacacs Configurations with do_auth

26 09 2009

We’ve gone over how you can make your tacacs configuration really secure but complicated. Let’s show how doauth can actually make configuration easier. It’s much easier to edit the doauth.ini file than the tac_plus.conf file. In fact, we can make adding a default user as easy as typing “adduser”.

I would post the compiled code, but it’s too difficult to get a hold of John these days. (Something about a baby, I dunno) It’s trivial to compile: dan@dan-desktop:~$ python
Python 2.5.2 (r252:60911, Jul 22 2009, 15:35:03)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pycompile
>>> py
compile.compile("doauth.py")
>>> quit()

First, a starting tac
plus.conf file. Which, we’ll never have to edit again:

# My simple tacplus config that never needs to change
key = my
key
accounting file = /var/log/tacplus.acct
default authentication = file /etc/passwd
user = DEFAULT {
     member = do
authaccess
}
group = do
authaccess {
     default service = permit
     service = exec { priv-lvl = 15
          idletime = 10 }
     enable = file /etc/passwd
     after authorization "/usr/bin/python /root/do
auth.pyc -i $address -u $user -d $name -l /root/log.txt -f /root/do_auth.ini" }

Most important – after authorizaion line is one line, not two. The $ means it wrapped.

Now, we add homer and give him access to some show commands. Fist, we do a adduser homer on linux to add the user. This way, when the user wants to change is password, he can any time he wants to with passwd. Next, we edit the do_auth.ini file

[users]
homer =
     fewcommands
[few
commands]
hostallow =
     .*
device
permit =
     .*
command_permit =
     show users
     show int.*
     show ip int.*
     show controllers.*

And, you’re done. Well, I’d add some tabs to each command that got stripped above(blogs/wiki’s can be annoying), but that’s about it.

Let’s compare that to the tac_plus.conf config:

user = homer {
     member = limitedaccess
}
group = limited
access {
     default service = deny
     acl = limited_acl
     service = exec {
          priv-lvl = 15
          idletime = 10
     }
     cmd = show {
          permit "running-config.*"
          permit "ip int*"
          permit "inter.*"
          permit "controllers.*"
     }

In my small do_auth python program, we have no permits, no “”, and no {}. Much easier and the no need to restart the daemon. To add an admin user is even easier. Adduser admin in linux, then add:

admin =
     adminuser
[admin
user]
hostallow =
     .*
device
permit =
     .*
command_permit =
     .*

So, our final config is very easy:

[users]
homer =
     fewcommands
admin =
     admin
user
[fewcommands]
host
allow =
     .*
devicepermit =
     .*
command
permit =
     show users
     show int.*
     show ip int.*
     show controllers.*
[adminuser]
host
allow =
     .*
devicepermit =
     .*
command
permit =
     .*

As if this weren’t easy enough, let’s say 99% of your users are these limited access users. Wouldn’t it be nice to just do an adduser and be done without any config modification? All we need is a default user. In our example above we would change to this:

[users]
default =
     fewcommands
[few
commands]
hostallow =
     .*
device
permit =
     .*
command_permit =
     show users
     show int.*
     show ip int.*
     show controllers.*

Now, whenever we do an adduser, it automatically gets this level of access.

From here, we can make it as simple or as complicated as we want. Restrict them to certain device, make them connect from connect from certain IP’s, ect. We can maybe even begin to work on a web front end. (Maybe someday when I get time…..)

-Dan Schmidt



Granular Tacacs Control (Yes, you can do multiple groups)

8 05 2009

By using an authorization script, we can make tacplus to do very granular authentication, having different permissions granted to different switches defined by user, source IP and device IP.  However, writing/editing a script to change access can be difficult.  Hard coded authorization scripts are not very flexible, hence, I decided to implement a python program to facilitate flexibility.  It is now included in the tacplus package.

Configuration is fairly simple; as an example, let’s say I wanted to have user Homer have full access to 192.168.1.1 and 10.1.1.0/24, but only do show commands for everything else in 10.0.0.0/8.  For the heck of it, let’s say we only want Homer to connect from 192.168.1.0/24, but never 192.168.1.4, which host can only do the show commands.   The config file would simply be as follows:

[users]
homer =
     simpsongroup
     television
group
[simpsongroup]
host
deny =
     192.168.1.4
hostallow =
     192.168.1.*
device
permit =
     192.168.1.1
     10.1.1.*
commandpermit =
     .*
[television
group]
hostallow =
     192.168.1.*
device
permit =
     10.*
command_permit =
     show.*

Example line to put in tacplus user or group: after authorization “/usr/bin/python /root/doauth.pyc -i $address -u $user -d $name -l /root/log.txt -f /root/do_auth.ini” (that’s all ONE line)

On my server, I set homer’s password file to /etc/passwd and enable cracklib.  Homer can change his password any time he wants just by logging to Linux and typing passwd – he does not need root access.  Homer is also forced to pick a secure password, and has different access based on different devices.  Given these abilities, combined with the quick administration, tac_plus makes purchasing Cisco’s tacacs server seem like a waste of money.

In the future, I may alter the program to have the ability to send back additional av-pairs, and/or completely new av-pairs.   However, currently I simply don’t need this feature as I pass these pairs back to tacplus.  The source code is very simple and is GPL’ed for all to see at: http://pastie.org/506002 and is available in compiled/ready to use form here.   For more instructions, you can download this compiled pyc and type “python doauth.pyc” If I ever get time, I may consider a gui or web interface.

Update: New version 1.2 Fixed pix. Also, apparently there is a bug in the pix that makes it necessary to add a 0.0.0.0 to your allowed hosts.

-Dan Schmidt