<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">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 class="h5"><br>
<br>
<br>
On Thu, Apr 16, 2015 at 9:09 AM, Aaron Wasserott <<br>
<a href="mailto:aaron.wasserott@viawest.com">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">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">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">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">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>-------------- 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>><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net">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></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.