From alan.mckinnon at gmail.com  Thu May 24 00:01:15 2012
From: alan.mckinnon at gmail.com (Alan McKinnon)
Date: Thu, 24 May 2012 02:01:15 +0200
Subject: [tac_plus] Nexus
In-Reply-To: <693b443ba3b1751b92a657673ec5d366@mail.gmail.com>
References: <5b66ec2b1eca835fc64a211ff2b7fc92@mail.gmail.com>
	<20111102234617.46e3762c@rohan.example.com>
	<693b443ba3b1751b92a657673ec5d366@mail.gmail.com>
Message-ID: <20120524020115.39a6bab0@khamul.example.com>

On Wed, 16 Nov 2011 10:28:28 -0700
Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:

> Ok, I got it working, I also have it set so it can find/replace pairs
> based on groups.  Slight change to do_auth - you DO have to strip the
> first 2 pairs just like ios, but they are not identical.  (cmd* vs
> cmd=)  Will post that change soon.  This would solve all Alan's
> problem, if Alan could be convinced to try do_auth.  ;-)

Your wish has been granted and I am convinced to try do_auth.py :-)

It know this one goes back a while but it deserves a reply - my tacacs
setup has gotten so big, unwieldy and cumbersome that I just can't take
it any more.

I have the usual mixture so typical of a real-world ISP: at least one
of everything Cisco have ever made, a bunch of Nexus, couple of XR
switches, some Juniper and even a few weird firewalls that someone once
bought because they were cheap. And every skill level amongst users
from knows nothing to brilliant and it all needs to be contained. Sound
familiar?

Let's see how it goes. I do have one question though:

Has anyone ever stress tested do_auth.py with lots of requests? On a
busy day we can achieve 1,000,000 requests (12 a second). tac_plus can
deal with that without breaking a sweat but I'd like to know if the .py
script has been tested to that level. Gut feel tells me it should be
fine.

> 
> The only thing I don't understand is why none of the default roles
> seem to be restricted.  I could conf t & change an int desc with
> role-0 and network-operator.  Are all the default roles useless or am
> I missing something?  The only place I could see a role being "not
> cumbersome and useless" was if you defined one for a VDC giving a
> user rights only to a specific VDC.  THAT is the only thing I can't
> do easier with do_auth and authorization.
> 
> [root at cwacs ~]# tail -n 11 log2.txt
> service=shell
> cmd=
> shell:roles="network-operator"
> idletime=3
> timeout=15
> Nexus pairs found
> not len(the_command) > 0
> Returning:shell:roles="priv-0"
> Returning:idletime=3
> Returning:timeout=15
> 2011-11-16 09:35:31: User 'tester' granted access to <yada yada>
> 
> 5k# show user- tester
> user:tester
>         roles:priv-0
> account created through REMOTE authentication
> Credentials such as ssh server key will be cached temporarily only
> for this user account
> Local login not possible
> 
> 5k# show role name priv-0
> 
> Role: priv-0
>   Description: This is a system defined privilege role.
>   vsan policy: permit (default)
>   Vlan policy: permit (default)
>   Interface policy: permit (default)
>   Vrf policy: permit (default)
>   -------------------------------------------------------------------
>   Rule    Perm    Type        Scope               Entity
>   -------------------------------------------------------------------
>   10      permit  command                         traceroute6 *
>   9       permit  command                         traceroute *
>   8       permit  command                         telnet6 *
>   7       permit  command                         telnet *
>   6       permit  command                         ping6 *
>   5       permit  command                         ping *
>   4       permit  command                         ssh6 *
>   3       permit  command                         ssh *
>   2       permit  command                         enable *
>   1       permit  read
> 
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Wednesday, November 02, 2011 3:46 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] Nexus
> 
> On Wed, 2 Nov 2011 12:55:21 -0600
> Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
> 
> > I have updated the do_auth.py authentication script to handle nexus,
> > thus it can provide the same multiple group authentication it
> > provides on other Cisco devices.   (or at least provide an example)
> > I have not been able to pass a role tac_pair successfully ? please
> > post if you have any progress with this.
> 
> tac_plus requires it in this form:
> 
>                 shell:roles="\"level1\""
> 
> Yes, you see it right. Two levels of double quotes, inner pair escaped
> 
> Many brain cells died in agony to discover that one :-)
> 
> >
> >
> >
> > I had success with the nexus with the following config: (Note that
> > many of the commands you traditionally look for are available)
> >
> >
> >
> > !Command: show running-config aaa
> >
> > !Time: Wed Oct 26 18:28:46 2011
> >
> >
> >
> > version 5.0(3)N1(1c)
> >
> > aaa authentication login default group private
> >
> > aaa authorization config-commands default group private
> >
> > aaa authorization commands default group private
> >
> > aaa accounting default group private
> >
> >
> >
> > As was discussed previously, the nexus seems to authenticate pap.
> > No clue why Cisco did this; putting pap user names in the
> > tac_plus.conf fixes login issues.   Also, the resulting accounting
> > file is different so if you have written cgi scripts to parse your
> > accounting log, be prepared to rewrite them.
> 
> 
> --
> Alan McKinnnon
> alan.mckinnon at gmail.com
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/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.
> 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus



-- 
Alan McKinnnon
alan.mckinnon at gmail.com


From daniel.schmidt at wyo.gov  Thu May 24 14:54:12 2012
From: daniel.schmidt at wyo.gov (Daniel Schmidt)
Date: Thu, 24 May 2012 08:54:12 -0600
Subject: [tac_plus] Nexus
In-Reply-To: <20120524020115.39a6bab0@khamul.example.com>
References: <5b66ec2b1eca835fc64a211ff2b7fc92@mail.gmail.com>
	<20111102234617.46e3762c@rohan.example.com>	<693b443ba3b1751b92a657673ec5d366@mail.gmail.com>
	<20120524020115.39a6bab0@khamul.example.com>
Message-ID: <754af54e19ab42cc36f23758095d5147@mail.gmail.com>

Yeah... that is a bit of a surprise.  ;-)

If you are worried, strip the long doc string & use do_auth.pyo.  Should
load slightly faster, when I did it, it was 23k before and 7.7k after.

$ python -OO
Python 2.4.3 (#1, Feb 22 2012, 16:05:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import py_compile
>>> py_compile.compile("do_auth.py")
>>>
<hit ctrl-d>

As for Juniper, I had Jathan test it and I believe he said it worked.
However, there was some Juniper specific stuff I wanted to add.  I'll get
around to someday soon. Jathan also had some great ideas for cleaning up
my lazy variable names & logging that I wanted him to add if he can get
around to it someday. Also, I changed my mind on Nexus roles - see
tacacs.org for more on roles.

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
Sent: Wednesday, May 23, 2012 6:01 PM
To: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Nexus

On Wed, 16 Nov 2011 10:28:28 -0700
Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:

> Ok, I got it working, I also have it set so it can find/replace pairs
> based on groups.  Slight change to do_auth - you DO have to strip the
> first 2 pairs just like ios, but they are not identical.  (cmd* vs
> cmd=)  Will post that change soon.  This would solve all Alan's
> problem, if Alan could be convinced to try do_auth.  ;-)

Your wish has been granted and I am convinced to try do_auth.py :-)

It know this one goes back a while but it deserves a reply - my tacacs
setup has gotten so big, unwieldy and cumbersome that I just can't take it
any more.

I have the usual mixture so typical of a real-world ISP: at least one of
everything Cisco have ever made, a bunch of Nexus, couple of XR switches,
some Juniper and even a few weird firewalls that someone once bought
because they were cheap. And every skill level amongst users from knows
nothing to brilliant and it all needs to be contained. Sound familiar?

Let's see how it goes. I do have one question though:

Has anyone ever stress tested do_auth.py with lots of requests? On a busy
day we can achieve 1,000,000 requests (12 a second). tac_plus can deal
with that without breaking a sweat but I'd like to know if the .py script
has been tested to that level. Gut feel tells me it should be fine.

>
> The only thing I don't understand is why none of the default roles
> seem to be restricted.  I could conf t & change an int desc with
> role-0 and network-operator.  Are all the default roles useless or am
> I missing something?  The only place I could see a role being "not
> cumbersome and useless" was if you defined one for a VDC giving a user
> rights only to a specific VDC.  THAT is the only thing I can't do
> easier with do_auth and authorization.
>
> [root at cwacs ~]# tail -n 11 log2.txt
> service=shell
> cmd=
> shell:roles="network-operator"
> idletime=3
> timeout=15
> Nexus pairs found
> not len(the_command) > 0
> Returning:shell:roles="priv-0"
> Returning:idletime=3
> Returning:timeout=15
> 2011-11-16 09:35:31: User 'tester' granted access to <yada yada>
>
> 5k# show user- tester
> user:tester
>         roles:priv-0
> account created through REMOTE authentication Credentials such as ssh
> server key will be cached temporarily only for this user account Local
> login not possible
>
> 5k# show role name priv-0
>
> Role: priv-0
>   Description: This is a system defined privilege role.
>   vsan policy: permit (default)
>   Vlan policy: permit (default)
>   Interface policy: permit (default)
>   Vrf policy: permit (default)
>   -------------------------------------------------------------------
>   Rule    Perm    Type        Scope               Entity
>   -------------------------------------------------------------------
>   10      permit  command                         traceroute6 *
>   9       permit  command                         traceroute *
>   8       permit  command                         telnet6 *
>   7       permit  command                         telnet *
>   6       permit  command                         ping6 *
>   5       permit  command                         ping *
>   4       permit  command                         ssh6 *
>   3       permit  command                         ssh *
>   2       permit  command                         enable *
>   1       permit  read
>
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Wednesday, November 02, 2011 3:46 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] Nexus
>
> On Wed, 2 Nov 2011 12:55:21 -0600
> Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
>
> > I have updated the do_auth.py authentication script to handle nexus,
> > thus it can provide the same multiple group authentication it
> > provides on other Cisco devices.   (or at least provide an example)
> > I have not been able to pass a role tac_pair successfully - please
> > post if you have any progress with this.
>
> tac_plus requires it in this form:
>
>                 shell:roles="\"level1\""
>
> Yes, you see it right. Two levels of double quotes, inner pair escaped
>
> Many brain cells died in agony to discover that one :-)
>
> >
> >
> >
> > I had success with the nexus with the following config: (Note that
> > many of the commands you traditionally look for are available)
> >
> >
> >
> > !Command: show running-config aaa
> >
> > !Time: Wed Oct 26 18:28:46 2011
> >
> >
> >
> > version 5.0(3)N1(1c)
> >
> > aaa authentication login default group private
> >
> > aaa authorization config-commands default group private
> >
> > aaa authorization commands default group private
> >
> > aaa accounting default group private
> >
> >
> >
> > As was discussed previously, the nexus seems to authenticate pap.
> > No clue why Cisco did this; putting pap user names in the
> > tac_plus.conf fixes login issues.   Also, the resulting accounting
> > file is different so if you have written cgi scripts to parse your
> > accounting log, be prepared to rewrite them.
>
>
> --
> Alan McKinnnon
> alan.mckinnon at gmail.com
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/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.
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus



--
Alan McKinnnon
alan.mckinnon at gmail.com

_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/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.


From alan.mckinnon at gmail.com  Thu May 24 20:43:16 2012
From: alan.mckinnon at gmail.com (Alan McKinnon)
Date: Thu, 24 May 2012 22:43:16 +0200
Subject: [tac_plus] Nexus
In-Reply-To: <754af54e19ab42cc36f23758095d5147@mail.gmail.com>
References: <5b66ec2b1eca835fc64a211ff2b7fc92@mail.gmail.com>
	<20111102234617.46e3762c@rohan.example.com>
	<693b443ba3b1751b92a657673ec5d366@mail.gmail.com>
	<20120524020115.39a6bab0@khamul.example.com>
	<754af54e19ab42cc36f23758095d5147@mail.gmail.com>
Message-ID: <20120524224316.4a498303@khamul.example.com>

On Thu, 24 May 2012 08:54:12 -0600
Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:

> Yeah... that is a bit of a surprise.  ;-)
> 
> If you are worried, strip the long doc string & use do_auth.pyo.
> Should load slightly faster, when I did it, it was 23k before and
> 7.7k after.


Nice tip :-) thanks


> $ python -OO
> Python 2.4.3 (#1, Feb 22 2012, 16:05:45)
> [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import py_compile
> >>> py_compile.compile("do_auth.py")
> >>>
> <hit ctrl-d>
> 
> As for Juniper, I had Jathan test it and I believe he said it worked.
> However, there was some Juniper specific stuff I wanted to add.  I'll
> get around to someday soon. Jathan also had some great ideas for
> cleaning up my lazy variable names & logging that I wanted him to add
> if he can get around to it someday. Also, I changed my mind on Nexus
> roles - see tacacs.org for more on roles.

I expect I'll end up doing a fair amount of patching to do-auth (that
being the nature of the work we all do) so I'll be happy to share the
results.

Nexus roles - that's the easy part for me. We use RBAC for that and
just send back the role as an av-pair. The NetOps guys reckon this
works best for how we do our Nexus stuff.

My main driver for testing do_auth is to get the notion of multiple
groups, everything else is bonus.


> 
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Wednesday, May 23, 2012 6:01 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] Nexus
> 
> On Wed, 16 Nov 2011 10:28:28 -0700
> Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
> 
> > Ok, I got it working, I also have it set so it can find/replace
> > pairs based on groups.  Slight change to do_auth - you DO have to
> > strip the first 2 pairs just like ios, but they are not identical.
> > (cmd* vs cmd=)  Will post that change soon.  This would solve all
> > Alan's problem, if Alan could be convinced to try do_auth.  ;-)
> 
> Your wish has been granted and I am convinced to try do_auth.py :-)
> 
> It know this one goes back a while but it deserves a reply - my tacacs
> setup has gotten so big, unwieldy and cumbersome that I just can't
> take it any more.
> 
> I have the usual mixture so typical of a real-world ISP: at least one
> of everything Cisco have ever made, a bunch of Nexus, couple of XR
> switches, some Juniper and even a few weird firewalls that someone
> once bought because they were cheap. And every skill level amongst
> users from knows nothing to brilliant and it all needs to be
> contained. Sound familiar?
> 
> Let's see how it goes. I do have one question though:
> 
> Has anyone ever stress tested do_auth.py with lots of requests? On a
> busy day we can achieve 1,000,000 requests (12 a second). tac_plus
> can deal with that without breaking a sweat but I'd like to know if
> the .py script has been tested to that level. Gut feel tells me it
> should be fine.
> 
> >
> > The only thing I don't understand is why none of the default roles
> > seem to be restricted.  I could conf t & change an int desc with
> > role-0 and network-operator.  Are all the default roles useless or
> > am I missing something?  The only place I could see a role being
> > "not cumbersome and useless" was if you defined one for a VDC
> > giving a user rights only to a specific VDC.  THAT is the only
> > thing I can't do easier with do_auth and authorization.
> >
> > [root at cwacs ~]# tail -n 11 log2.txt
> > service=shell
> > cmd=
> > shell:roles="network-operator"
> > idletime=3
> > timeout=15
> > Nexus pairs found
> > not len(the_command) > 0
> > Returning:shell:roles="priv-0"
> > Returning:idletime=3
> > Returning:timeout=15
> > 2011-11-16 09:35:31: User 'tester' granted access to <yada yada>
> >
> > 5k# show user- tester
> > user:tester
> >         roles:priv-0
> > account created through REMOTE authentication Credentials such as
> > ssh server key will be cached temporarily only for this user
> > account Local login not possible
> >
> > 5k# show role name priv-0
> >
> > Role: priv-0
> >   Description: This is a system defined privilege role.
> >   vsan policy: permit (default)
> >   Vlan policy: permit (default)
> >   Interface policy: permit (default)
> >   Vrf policy: permit (default)
> >   -------------------------------------------------------------------
> >   Rule    Perm    Type        Scope               Entity
> >   -------------------------------------------------------------------
> >   10      permit  command                         traceroute6 *
> >   9       permit  command                         traceroute *
> >   8       permit  command                         telnet6 *
> >   7       permit  command                         telnet *
> >   6       permit  command                         ping6 *
> >   5       permit  command                         ping *
> >   4       permit  command                         ssh6 *
> >   3       permit  command                         ssh *
> >   2       permit  command                         enable *
> >   1       permit  read
> >
> > -----Original Message-----
> > From: tac_plus-bounces at shrubbery.net
> > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> > Sent: Wednesday, November 02, 2011 3:46 PM
> > To: tac_plus at shrubbery.net
> > Subject: Re: [tac_plus] Nexus
> >
> > On Wed, 2 Nov 2011 12:55:21 -0600
> > Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
> >
> > > I have updated the do_auth.py authentication script to handle
> > > nexus, thus it can provide the same multiple group authentication
> > > it provides on other Cisco devices.   (or at least provide an
> > > example) I have not been able to pass a role tac_pair
> > > successfully - please post if you have any progress with this.
> >
> > tac_plus requires it in this form:
> >
> >                 shell:roles="\"level1\""
> >
> > Yes, you see it right. Two levels of double quotes, inner pair
> > escaped
> >
> > Many brain cells died in agony to discover that one :-)
> >
> > >
> > >
> > >
> > > I had success with the nexus with the following config: (Note that
> > > many of the commands you traditionally look for are available)
> > >
> > >
> > >
> > > !Command: show running-config aaa
> > >
> > > !Time: Wed Oct 26 18:28:46 2011
> > >
> > >
> > >
> > > version 5.0(3)N1(1c)
> > >
> > > aaa authentication login default group private
> > >
> > > aaa authorization config-commands default group private
> > >
> > > aaa authorization commands default group private
> > >
> > > aaa accounting default group private
> > >
> > >
> > >
> > > As was discussed previously, the nexus seems to authenticate pap.
> > > No clue why Cisco did this; putting pap user names in the
> > > tac_plus.conf fixes login issues.   Also, the resulting accounting
> > > file is different so if you have written cgi scripts to parse your
> > > accounting log, be prepared to rewrite them.
> >
> >
> > --
> > Alan McKinnnon
> > alan.mckinnon at gmail.com
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/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.
> >
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> 
> 
> 
> --
> Alan McKinnnon
> alan.mckinnon at gmail.com
> 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/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.
> 



-- 
Alan McKinnnon
alan.mckinnon at gmail.com


From daniel.schmidt at wyo.gov  Thu May 24 22:44:30 2012
From: daniel.schmidt at wyo.gov (Daniel Schmidt)
Date: Thu, 24 May 2012 16:44:30 -0600
Subject: [tac_plus] Nexus
In-Reply-To: <20120524224316.4a498303@khamul.example.com>
References: <5b66ec2b1eca835fc64a211ff2b7fc92@mail.gmail.com>
	<20111102234617.46e3762c@rohan.example.com>	<693b443ba3b1751b92a657673ec5d366@mail.gmail.com>
	<20120524020115.39a6bab0@khamul.example.com>	<754af54e19ab42cc36f23758095d5147@mail.gmail.com>
	<20120524224316.4a498303@khamul.example.com>
Message-ID: <6d48236f9f603297d3cefe5d4ecc0c4d@mail.gmail.com>

As I recall, you ran a separate instance for your nexus.  Use do_auth &
you can use the same instance.  It's python; the code's pretty trivial.  I
look forward to seeing your patches.

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
Sent: Thursday, May 24, 2012 2:43 PM
To: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Nexus

On Thu, 24 May 2012 08:54:12 -0600
Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:

> Yeah... that is a bit of a surprise.  ;-)
>
> If you are worried, strip the long doc string & use do_auth.pyo.
> Should load slightly faster, when I did it, it was 23k before and 7.7k
> after.


Nice tip :-) thanks


> $ python -OO
> Python 2.4.3 (#1, Feb 22 2012, 16:05:45) [GCC 4.1.2 20080704 (Red Hat
> 4.1.2-52)] on linux2 Type "help", "copyright", "credits" or "license"
> for more information.
> >>> import py_compile
> >>> py_compile.compile("do_auth.py")
> >>>
> <hit ctrl-d>
>
> As for Juniper, I had Jathan test it and I believe he said it worked.
> However, there was some Juniper specific stuff I wanted to add.  I'll
> get around to someday soon. Jathan also had some great ideas for
> cleaning up my lazy variable names & logging that I wanted him to add
> if he can get around to it someday. Also, I changed my mind on Nexus
> roles - see tacacs.org for more on roles.

I expect I'll end up doing a fair amount of patching to do-auth (that
being the nature of the work we all do) so I'll be happy to share the
results.

Nexus roles - that's the easy part for me. We use RBAC for that and just
send back the role as an av-pair. The NetOps guys reckon this works best
for how we do our Nexus stuff.

My main driver for testing do_auth is to get the notion of multiple
groups, everything else is bonus.


>
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Wednesday, May 23, 2012 6:01 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] Nexus
>
> On Wed, 16 Nov 2011 10:28:28 -0700
> Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
>
> > Ok, I got it working, I also have it set so it can find/replace
> > pairs based on groups.  Slight change to do_auth - you DO have to
> > strip the first 2 pairs just like ios, but they are not identical.
> > (cmd* vs cmd=)  Will post that change soon.  This would solve all
> > Alan's problem, if Alan could be convinced to try do_auth.  ;-)
>
> Your wish has been granted and I am convinced to try do_auth.py :-)
>
> It know this one goes back a while but it deserves a reply - my tacacs
> setup has gotten so big, unwieldy and cumbersome that I just can't
> take it any more.
>
> I have the usual mixture so typical of a real-world ISP: at least one
> of everything Cisco have ever made, a bunch of Nexus, couple of XR
> switches, some Juniper and even a few weird firewalls that someone
> once bought because they were cheap. And every skill level amongst
> users from knows nothing to brilliant and it all needs to be
> contained. Sound familiar?
>
> Let's see how it goes. I do have one question though:
>
> Has anyone ever stress tested do_auth.py with lots of requests? On a
> busy day we can achieve 1,000,000 requests (12 a second). tac_plus can
> deal with that without breaking a sweat but I'd like to know if the
> .py script has been tested to that level. Gut feel tells me it should
> be fine.
>
> >
> > The only thing I don't understand is why none of the default roles
> > seem to be restricted.  I could conf t & change an int desc with
> > role-0 and network-operator.  Are all the default roles useless or
> > am I missing something?  The only place I could see a role being
> > "not cumbersome and useless" was if you defined one for a VDC giving
> > a user rights only to a specific VDC.  THAT is the only thing I
> > can't do easier with do_auth and authorization.
> >
> > [root at cwacs ~]# tail -n 11 log2.txt
> > service=shell
> > cmd=
> > shell:roles="network-operator"
> > idletime=3
> > timeout=15
> > Nexus pairs found
> > not len(the_command) > 0
> > Returning:shell:roles="priv-0"
> > Returning:idletime=3
> > Returning:timeout=15
> > 2011-11-16 09:35:31: User 'tester' granted access to <yada yada>
> >
> > 5k# show user- tester
> > user:tester
> >         roles:priv-0
> > account created through REMOTE authentication Credentials such as
> > ssh server key will be cached temporarily only for this user account
> > Local login not possible
> >
> > 5k# show role name priv-0
> >
> > Role: priv-0
> >   Description: This is a system defined privilege role.
> >   vsan policy: permit (default)
> >   Vlan policy: permit (default)
> >   Interface policy: permit (default)
> >   Vrf policy: permit (default)
> >   -------------------------------------------------------------------
> >   Rule    Perm    Type        Scope               Entity
> >   -------------------------------------------------------------------
> >   10      permit  command                         traceroute6 *
> >   9       permit  command                         traceroute *
> >   8       permit  command                         telnet6 *
> >   7       permit  command                         telnet *
> >   6       permit  command                         ping6 *
> >   5       permit  command                         ping *
> >   4       permit  command                         ssh6 *
> >   3       permit  command                         ssh *
> >   2       permit  command                         enable *
> >   1       permit  read
> >
> > -----Original Message-----
> > From: tac_plus-bounces at shrubbery.net
> > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> > Sent: Wednesday, November 02, 2011 3:46 PM
> > To: tac_plus at shrubbery.net
> > Subject: Re: [tac_plus] Nexus
> >
> > On Wed, 2 Nov 2011 12:55:21 -0600
> > Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
> >
> > > I have updated the do_auth.py authentication script to handle
> > > nexus, thus it can provide the same multiple group authentication
> > > it provides on other Cisco devices.   (or at least provide an
> > > example) I have not been able to pass a role tac_pair successfully
> > > - please post if you have any progress with this.
> >
> > tac_plus requires it in this form:
> >
> >                 shell:roles="\"level1\""
> >
> > Yes, you see it right. Two levels of double quotes, inner pair
> > escaped
> >
> > Many brain cells died in agony to discover that one :-)
> >
> > >
> > >
> > >
> > > I had success with the nexus with the following config: (Note that
> > > many of the commands you traditionally look for are available)
> > >
> > >
> > >
> > > !Command: show running-config aaa
> > >
> > > !Time: Wed Oct 26 18:28:46 2011
> > >
> > >
> > >
> > > version 5.0(3)N1(1c)
> > >
> > > aaa authentication login default group private
> > >
> > > aaa authorization config-commands default group private
> > >
> > > aaa authorization commands default group private
> > >
> > > aaa accounting default group private
> > >
> > >
> > >
> > > As was discussed previously, the nexus seems to authenticate pap.
> > > No clue why Cisco did this; putting pap user names in the
> > > tac_plus.conf fixes login issues.   Also, the resulting accounting
> > > file is different so if you have written cgi scripts to parse your
> > > accounting log, be prepared to rewrite them.
> >
> >
> > --
> > Alan McKinnnon
> > alan.mckinnon at gmail.com
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/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.
> >
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
>
>
> --
> Alan McKinnnon
> alan.mckinnon at gmail.com
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/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.
>



--
Alan McKinnnon
alan.mckinnon at gmail.com

_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/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.