[tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers

[Daniel Schmidt]

-D switch is only for command line testing - mainly to test that your
do_auth.ini is setup right.  Never use it in tac_plus.conf.

I wonder if the brocades don't like the return value?  Kind of like Dell
procurves.  You could throw a:
exit_val =
    0
In the do_auth.ini and see if it makes it happier.  I can't think of a
reason it wouldn't return the tac_pairs - it's supposed to.  This *looks*
right though:

service=shell
cmd*
priv-lvl=15
Thing:priv-lvl
Thing:15

not len(the_command) > 0
Returning:priv-lvl=15
2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11'
in group 'test-group' from '10.33.144.34'
Exiting status 2

I can't remember what "thing" was - I think i was debugging to make sure we
split correctly.  Comment that part back out in the future.  (Jathan
rightly gave me a bad time for my variable names)

Let me know what you find.  I'm always happy to look into something that
isn't a patch request.


On Fri, Mar 14, 2014 at 5:45 PM, Aaron Wasserott <
aaron.wasserott at viawest.com> wrote:

> I enabled debugging and recompiled do_auth.py. However I found two lines
> that generate an error. I couldn't figure out how to fix them so I left
> them commented out. There were 14 other DEBUG lines I uncommented that
> compiled successfully.
>
> ### Line 339:
>
>   File "do_auth-debug.py", line 339
>     log_file.write('Hello World!' + '\n')
>                                         ^
> IndentationError: unindent does not match any outer indentation level
>
> ### Line 375:
>
>   File "do_auth-debug.py", line 375
>     return_pairs = av_pairs[2:]
>                               ^
> IndentationError: unindent does not match any outer indentation level
>
>
>
> Here is the log output from do_auth.log. Both of them are with 'aaa
> authorization exec' enabled on the ServerIron:
>
> ### do_auth.log with -D switch off
>
> service=shell
> cmd*
> priv-lvl=15
> Thing:priv-lvl
> Thing:15
>
> not len(the_command) > 0
> Returning:priv-lvl=15
> 2014-03-14 17:27:36: User 'testuser' granted access to device '10.99.1.11'
> in group 'test-group' from '10.33.144.34'
> Exiting status 2
>
> ### do_auth.log with -D switch on
>
> service=shell
> cmd=show
> cmd-arg=users
> cmd-arg=wide
> cmd-arg=<cr>
> show users wide
> 2014-03-14 17:39:59: User 'testuser' allowed command 'show users wide' to
> device '10.99.1.11' in 'test-group'->'command_permit'
>
>
>
> -----Original Message-----
> From: heasley [mailto:heas at shrubbery.net]
> Sent: Friday, March 14, 2014 4:39 PM
> To: Aaron Wasserott
> Cc: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] do_auth and aaa authorization not working with
> Foundry ServerIronXL load-balancers
>
> Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott:
> > I have many ancient Foundry  ServerIronXL load-balancers. They work fine
> with basic TACACS AAA but when I implement do_auth I cannot login. I
> noticed some interesting behavior, that if I either turn off authorization
> or enable do_auth debugging it will work.
> >
> > Below are tacacs debug outputs for the 3 scenarios with do_auth. 1) with
> authorization and it fails. 2)  without authorization and it passes. 3)
> with authorization and with debugging and it passes. Doing a compare,
> between scenario 1 and 3 it appears the root issue is that without
> debugging, do_auth will send AUTHOR/PASS_REPL and with debugging it will
> send AUTHOR/PASS_ADD. If you paste the entire debug output (with header)
> below into a text editor, this in on line 115. Shortly after that on line
> 138 there are other differences, and w/o debugging it either sends or
> receives (I can't tell) data not sent/received with debugging. Also notice
> that w/o debugging it never receives the username. Then w/o debugging it
> gets a null packet when it expects a continue, pointing to the ServerIron
> not liking something sent to it.
> >
> > I am hoping to find a way to modify how do_auth communicates with the
> ServerIron's that leaves debugging off, and authorization on.
>
> i believe something is missing; the do-auth script is exiting with value 2
> but not writing the AVPs or the AVPs are empty.  There are many debugging
> messages in the script that are commented out.  you should uncomment them
> and try the script; there are only two places where it exits with code 2.
> it may be that it should be exiting with code 1.
> _______________________________________________
> 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/20140317/7fbaa3a8/attachment.html>