[tac_plus] enable additional commands centrally for IOS privilege levels other than 15
Daniel Schmidt
daniel.schmidt at wyo.gov
Thu Apr 16 17:53:10 UTC 2015
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.
On Thu, Apr 16, 2015 at 11:34 AM, John Fraizer <john at op-sec.us> wrote:
> 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
> >
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/19cd8c79/attachment.html>
More information about the tac_plus
mailing list