[tac_plus] enable additional commands centrally for IOS privilege levels other than 15
John Fraizer
john at op-sec.us
Thu Apr 16 17:34:43 UTC 2015
Here is an example:
tac_plus.conf:
key = "blah-blah-blah"
accounting file = /some/location/tacplus.acct
default authentication = file /etc/passwd
#
# Default group to run all command authentication through do_auth.
#
group = doauthaccess {
default service = permit
service = exec {
priv-lvl = 1
optional idletime = 30
optional acl = 2
shell:roles="\"network-operator vdc-operator\""
}
service = junos-exec {
bug-fix = "first pair is lost"
local-user-name = "remote"
allow-commands = "(.*exit)|(show cli auth.*)"
deny-commands = ".*"
allow-configuration = ""
deny-configuration = ".*"
}
after authorization "/usr/bin/python /some-location/do_auth.py -i
$address -u $user -d $name -l /some-location/do_auth.log -f
/some-location/do_auth.ini"
}
#
# Default user - Used when no user specific stanza exists in tac_plus.conf.
#
user = DEFAULT {
member = doauthaccess
login = PAM
}
And then, in do_auth.ini:
[users]
default =
no_authority
ren =
lab
no_authority
stimpy =
lab
production_readonly
no_authority
# Groups start here
# Default group. Can only log out and check
# privilege level (JUNOS)
[no_authority]
host_deny =
host_allow =
.*
device_deny =
device_permit =
.*
command_deny =
.*
command_permit =
exit.*
av_pairs =
priv-lvl=0
shell:roles="network-operator vdc-operator"
local-user-name = test
allow-commands = (.*exit)|(show cli auth.*)
deny-commands = .*
allow-configuration =
deny-configuration =
# LAB group can do anything - as long as the device
# they're logging into is in 192.168.56.0/24 which is
# the IP address space used for management in the LAB.
[lab]
host_deny =
host_allow =
.*
device_deny =
device_permit =
192.168.56.*
command_deny =
command_permit =
.*
av_pairs =
priv-lvl=15
shell:roles="network-admin vdc-admin"
local-user-name = remote
allow-commands = .*
deny-commands =
allow-configuration = .*
deny-configuration =
# This group provides read-only access to ANY device.
[production_readonly]
host_deny =
host_allow =
.*
device_deny =
device_permit =
.*
command_deny =
command_permit =
ping.*
traceroute.*
terminal.*
write terminal.*
copy running-config terminal.*
copy running-config tftp.*
copy startup-config terminal.*
copy startup-config tftp.*
show.*
av_pairs =
priv-lvl=15
shell:roles="network-admin vdc-admin"
local-user-name = remote
allow-commands =
deny-commands = (.*edit)|(.*configure)
allow-configuration =
deny-configuration =
With the above configuration, user "joe" does not have a user stanza in
do_auth.ini so, he will fall through to the "default" group (no_authority)
no matter which device he logs into. He will only be able to log out. ;-)
User ren is a member of "lab" and "no_authority" so, if he logs into any
devices in 192.168.56.0/24, he can do anything. For anything else, he will
fall through to the "no_authority" group and only be able to log out.
User stimpy is a member of all three groups: lab, production_readonly and
no_authority. If he logs into a device in 192.168.56.0/24, he can do
anything. If he logs in ANYWHERE else, he will receive the
"production_readonly" privileges since it matches on .* for
"device_permit".
If you look in group "production_readonly", I'm setting priv-lvl=15 or
giving "network-admin vdc-admin" or "local-user-name = remote" (depending
on which AV pair(s) the device sent to tac_plus. On my Junipers, user
"remote" is "super-user" which is basically the same as priv-lvl=15.
On anything that does command authorization, I'm only permitting:
ping.*
traceroute.*
terminal.*
write terminal.*
copy running-config terminal.*
copy running-config tftp.*
copy startup-config terminal.*
copy startup-config tftp.*
show.*
Anything else will be denied.
On the Junipers, since they do RBAC and don't ask to authorize individual
commands, I'm simply denying "edit" and "configure" in the "deny-commands"
regular expression so, they can't make config changes.
Note that ALL users are members of "no_authority" as their "last resort"
group. This is because, without that group membership, Cisco's and Arista
would get a "denied" authorization for the shell. Junipers flat-out IGNORE
that though and the user would get uninhibited "super-user". Silly JUNOS!
Placing everyone in "no_authority" makes sure that even if no other groups
match, they will at least match on the no_authority group and be granted
just enough access to log out of the device (and look at their authority on
Junipers):
command_deny =
.*
command_permit =
exit.*
av_pairs =
priv-lvl=0
shell:roles="network-operator vdc-operator"
local-user-name = test
allow-commands = (.*exit)|(show cli auth.*)
deny-commands = .*
allow-configuration =
deny-configuration =
There you go... a quick tutorial on using do_auth.py via the "after
authorization" function in tac_plus. You'll never believe you lived
without it once you set it up. Just be sure to TEST the configurations.
You might find a corner-case like I did with silly JUNOS doing the opposite
of what you would expect.
--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
On Thu, Apr 16, 2015 at 9:09 AM, Aaron Wasserott <
aaron.wasserott at viawest.com> wrote:
> Look into the do_auth.pyc script to control command authorization.
>
> http://www.tacacs.org/
>
> -----Original Message-----
> From: tac_plus [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of
> Martin T
> Sent: Thursday, April 16, 2015 9:55 AM
> To: tac_plus at shrubbery.net
> Subject: [tac_plus] enable additional commands centrally for IOS privilege
> levels other than 15
>
> Hi,
>
> privilege level 15 in IOS has all the possible commands for particular IOS
> release enabled. However, for example privilege level 1 has only few dozens
> of commands available. Now if I want to allow some of the privilege level
> 15 commands also for privilege level 1, then I could use the "privilege
> exec level 1 <command>" command. For example "privilege exec level 1
> traceroute". However, is there a way to do this centrally in TACACS+ server?
>
>
> thanks,
> Martin
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
> This message contains information that may be confidential, privileged or
> otherwise protected by law from disclosure. It is intended for the
> exclusive use of the addressee(s). Unless you are the addressee or
> authorized agent of the addressee, you may not review, copy, distribute or
> disclose to anyone the message or any information contained within. If you
> have received this message in error, please contact the sender by
> electronic reply and immediately delete all copies of the message.
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/02e9a147/attachment.html>
More information about the tac_plus
mailing list