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

[Aaron Wasserott]

That did the trick, thanks!

Here is do_auth.log output now (still running the debug version of do_auth.pyc):

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

not len(the_command) > 0
Returning:priv-lvl=15
2014-03-17 21:04:05: User 'testuser' granted access to device '10.99.1.11' in group 'test-group' from '10.33.144.28'
Exiting status 0

From: Daniel Schmidt [mailto:daniel.schmidt at wyo.gov]
Sent: Monday, March 17, 2014 2:45 PM
To: Aaron Wasserott
Cc: tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
Subject: Re: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers

-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<mailto: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<mailto:heas at shrubbery.net>]
Sent: Friday, March 14, 2014 4:39 PM
To: Aaron Wasserott
Cc: tac_plus at shrubbery.net<mailto: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<mailto: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/20140318/17148234/attachment.html>