<div dir="ltr">do_auth.py is a great tool which has given so much more flexibility to our TACACS+ infrastructure.<div><br></div><div>I've modified it to log to a MySQL database and have also modified tac_plus to allow accounting to a script "after authorization" style. I pass the accounting pairs out and read them into STDIN and log those to the MySQL database too. It makes searching through the logs so much more flexible because I'm able to make Arista / Cisco / Juniper accounting records have a consistent format in the database. I can also tell the difference between the three vendors based only on the pairs they send in their accounting records.</div><div><br></div><div>New tac_plus directive:</div><div><br></div><div>accounting script = "/usr/bin/python /someplace/do_accounting.py -f /someplace/do_auth.ini"<br></div><div><br></div><div>And I've added the following directives to do_auth.ini which both scripts use to set up their MySQL config:</div><div><br></div><div><div>[mysql]</div><div>user = tacacs</div><div>password = somepassword</div><div>host = 10.172.192.1</div><div>database = somedatabase</div><div><br></div></div><div>Thanks for all the hard work on do_auth.py! Once I've put my changes through enough testing, I'm planning on providing patches to the community for both do_auth.py and tac_plus in case someone else wants to leverage MySQL for logging TACACS stuff.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>--</div>John Fraizer<div>LinkedIn profile: <a href="http://www.linkedin.com/in/johnfraizer/" target="_blank">http://www.linkedin.com/in/johnfraizer/</a></div><div><br><div><span style="color:rgb(53,53,53);font-family:Arial,sans-serif;font-size:12px;line-height:12px;background-color:rgb(244,244,244)"><br></span></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 16, 2015 at 10:53 AM, Daniel Schmidt <span dir="ltr"><<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jathan and I are planning to improve the JUNOS support. I'm always glad to hear that this little python snippet I started a few years ago has made people's lives easier. </div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Apr 16, 2015 at 11:34 AM, John Fraizer <span dir="ltr"><<a href="mailto:john@op-sec.us" target="_blank">john@op-sec.us</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Here is an example:<br>
<br>
tac_plus.conf:<br>
<br>
key = "blah-blah-blah"<br>
accounting file = /some/location/tacplus.acct<br>
<br>
default authentication = file /etc/passwd<br>
<br>
#<br>
# Default group to run all command authentication through do_auth.<br>
#<br>
group = doauthaccess {<br>
default service = permit<br>
<br>
service = exec {<br>
priv-lvl = 1<br>
optional idletime = 30<br>
optional acl = 2<br>
shell:roles="\"network-operator vdc-operator\""<br>
}<br>
<br>
service = junos-exec {<br>
bug-fix = "first pair is lost"<br>
local-user-name = "remote"<br>
allow-commands = "(.*exit)|(show cli auth.*)"<br>
deny-commands = ".*"<br>
allow-configuration = ""<br>
deny-configuration = ".*"<br>
}<br>
after authorization "/usr/bin/python /some-location/do_auth.py -i<br>
$address -u $user -d $name -l /some-location/do_auth.log -f<br>
/some-location/do_auth.ini"<br>
}<br>
<br>
<br>
#<br>
# Default user - Used when no user specific stanza exists in tac_plus.conf.<br>
#<br>
user = DEFAULT {<br>
member = doauthaccess<br>
login = PAM<br>
}<br>
<br>
<br>
And then, in do_auth.ini:<br>
<br>
[users]<br>
default =<br>
no_authority<br>
<br>
ren =<br>
lab<br>
no_authority<br>
<br>
stimpy =<br>
lab<br>
production_readonly<br>
no_authority<br>
<br>
# Groups start here<br>
<br>
# Default group. Can only log out and check<br>
# privilege level (JUNOS)<br>
[no_authority]<br>
host_deny =<br>
host_allow =<br>
.*<br>
device_deny =<br>
device_permit =<br>
.*<br>
command_deny =<br>
.*<br>
command_permit =<br>
exit.*<br>
av_pairs =<br>
priv-lvl=0<br>
shell:roles="network-operator vdc-operator"<br>
local-user-name = test<br>
allow-commands = (.*exit)|(show cli auth.*)<br>
deny-commands = .*<br>
allow-configuration =<br>
deny-configuration =<br>
<br>
# LAB group can do anything - as long as the device<br>
# they're logging into is in <a href="http://192.168.56.0/24" target="_blank">192.168.56.0/24</a> which is<br>
# the IP address space used for management in the LAB.<br>
[lab]<br>
host_deny =<br>
host_allow =<br>
.*<br>
device_deny =<br>
device_permit =<br>
192.168.56.*<br>
command_deny =<br>
command_permit =<br>
.*<br>
av_pairs =<br>
priv-lvl=15<br>
shell:roles="network-admin vdc-admin"<br>
local-user-name = remote<br>
allow-commands = .*<br>
deny-commands =<br>
allow-configuration = .*<br>
deny-configuration =<br>
<br>
<br>
# This group provides read-only access to ANY device.<br>
[production_readonly]<br>
host_deny =<br>
host_allow =<br>
.*<br>
device_deny =<br>
device_permit =<br>
.*<br>
command_deny =<br>
command_permit =<br>
ping.*<br>
traceroute.*<br>
terminal.*<br>
write terminal.*<br>
copy running-config terminal.*<br>
copy running-config tftp.*<br>
copy startup-config terminal.*<br>
copy startup-config tftp.*<br>
show.*<br>
av_pairs =<br>
priv-lvl=15<br>
shell:roles="network-admin vdc-admin"<br>
local-user-name = remote<br>
allow-commands =<br>
deny-commands = (.*edit)|(.*configure)<br>
allow-configuration =<br>
deny-configuration =<br>
<br>
<br>
<br>
<br>
With the above configuration, user "joe" does not have a user stanza in<br>
do_auth.ini so, he will fall through to the "default" group (no_authority)<br>
no matter which device he logs into. He will only be able to log out. ;-)<br>
User ren is a member of "lab" and "no_authority" so, if he logs into any<br>
devices in <a href="http://192.168.56.0/24" target="_blank">192.168.56.0/24</a>, he can do anything. For anything else, he will<br>
fall through to the "no_authority" group and only be able to log out.<br>
User stimpy is a member of all three groups: lab, production_readonly and<br>
no_authority. If he logs into a device in <a href="http://192.168.56.0/24" target="_blank">192.168.56.0/24</a>, he can do<br>
anything. If he logs in ANYWHERE else, he will receive the<br>
"production_readonly" privileges since it matches on .* for<br>
"device_permit".<br>
<br>
If you look in group "production_readonly", I'm setting priv-lvl=15 or<br>
giving "network-admin vdc-admin" or "local-user-name = remote" (depending<br>
on which AV pair(s) the device sent to tac_plus. On my Junipers, user<br>
"remote" is "super-user" which is basically the same as priv-lvl=15.<br>
<br>
On anything that does command authorization, I'm only permitting:<br>
ping.*<br>
traceroute.*<br>
terminal.*<br>
write terminal.*<br>
copy running-config terminal.*<br>
copy running-config tftp.*<br>
copy startup-config terminal.*<br>
copy startup-config tftp.*<br>
show.*<br>
<br>
Anything else will be denied.<br>
<br>
On the Junipers, since they do RBAC and don't ask to authorize individual<br>
commands, I'm simply denying "edit" and "configure" in the "deny-commands"<br>
regular expression so, they can't make config changes.<br>
<br>
Note that ALL users are members of "no_authority" as their "last resort"<br>
group. This is because, without that group membership, Cisco's and Arista<br>
would get a "denied" authorization for the shell. Junipers flat-out IGNORE<br>
that though and the user would get uninhibited "super-user". Silly JUNOS!<br>
Placing everyone in "no_authority" makes sure that even if no other groups<br>
match, they will at least match on the no_authority group and be granted<br>
just enough access to log out of the device (and look at their authority on<br>
Junipers):<br>
<br>
command_deny =<br>
.*<br>
command_permit =<br>
exit.*<br>
av_pairs =<br>
priv-lvl=0<br>
shell:roles="network-operator vdc-operator"<br>
local-user-name = test<br>
allow-commands = (.*exit)|(show cli auth.*)<br>
deny-commands = .*<br>
allow-configuration =<br>
deny-configuration =<br>
<br>
There you go... a quick tutorial on using do_auth.py via the "after<br>
authorization" function in tac_plus. You'll never believe you lived<br>
without it once you set it up. Just be sure to TEST the configurations.<br>
You might find a corner-case like I did with silly JUNOS doing the opposite<br>
of what you would expect.<br>
<br>
<br>
--<br>
John Fraizer<br>
LinkedIn profile: <a href="http://www.linkedin.com/in/johnfraizer/" target="_blank">http://www.linkedin.com/in/johnfraizer/</a><br>
<div><div><br>
<br>
<br>
On Thu, Apr 16, 2015 at 9:09 AM, Aaron Wasserott <<br>
<a href="mailto:aaron.wasserott@viawest.com" target="_blank">aaron.wasserott@viawest.com</a>> wrote:<br>
<br>
> Look into the do_auth.pyc script to control command authorization.<br>
><br>
> <a href="http://www.tacacs.org/" target="_blank">http://www.tacacs.org/</a><br>
><br>
> -----Original Message-----<br>
> From: tac_plus [mailto:<a href="mailto:tac_plus-bounces@shrubbery.net" target="_blank">tac_plus-bounces@shrubbery.net</a>] On Behalf Of<br>
> Martin T<br>
> Sent: Thursday, April 16, 2015 9:55 AM<br>
> To: <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
> Subject: [tac_plus] enable additional commands centrally for IOS privilege<br>
> levels other than 15<br>
><br>
> Hi,<br>
><br>
> privilege level 15 in IOS has all the possible commands for particular IOS<br>
> release enabled. However, for example privilege level 1 has only few dozens<br>
> of commands available. Now if I want to allow some of the privilege level<br>
> 15 commands also for privilege level 1, then I could use the "privilege<br>
> exec level 1 <command>" command. For example "privilege exec level 1<br>
> traceroute". However, is there a way to do this centrally in TACACS+ server?<br>
><br>
><br>
> thanks,<br>
> Martin<br>
> _______________________________________________<br>
> tac_plus mailing list<br>
> <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
> <a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
> This message contains information that may be confidential, privileged or<br>
> otherwise protected by law from disclosure. It is intended for the<br>
> exclusive use of the addressee(s). Unless you are the addressee or<br>
> authorized agent of the addressee, you may not review, copy, distribute or<br>
> disclose to anyone the message or any information contained within. If you<br>
> have received this message in error, please contact the sender by<br>
> electronic reply and immediately delete all copies of the message.<br>
> _______________________________________________<br>
> tac_plus mailing list<br>
> <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
> <a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
><br>
</div></div></div></div>-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/02e9a147/attachment.html" target="_blank">http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/02e9a147/attachment.html</a>><span class=""><br>
<div><div>_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
</div></div></span></blockquote></div><br></div>
<pre>E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
</pre></blockquote></div><br></div>