<div dir="ltr"><div>-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.</div><div><br></div><div>I wonder if the brocades don't like the return value? Kind of like Dell procurves. You could throw a:</div>
<div><span style="color:rgb(0,0,0);font-family:'Courier New',Courier,Fixed,monospace;font-size:12px;line-height:17px">exit_val = </span><br style="color:rgb(0,0,0);font-family:'Courier New',Courier,Fixed,monospace;font-size:12px;line-height:17px">
<span style="color:rgb(0,0,0);font-family:'Courier New',Courier,Fixed,monospace;font-size:12px;line-height:17px"> 0 </span></div><div>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:</div>
<div><br></div><div><font face="courier new, monospace" size="1">service=shell<br>cmd*<br>priv-lvl=15<br>Thing:priv-lvl<br>Thing:15<br><br>not len(the_command) > 0<br>Returning:priv-lvl=15<br>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'<br>
Exiting status 2</font><br></div><div><br></div><div>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) </div>
<div><br></div><div>Let me know what you find. I'm always happy to look into something that isn't a patch request. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 5:45 PM, Aaron Wasserott <span dir="ltr"><<a href="mailto:aaron.wasserott@viawest.com" target="_blank">aaron.wasserott@viawest.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
### Line 339:<br>
<br>
File "do_auth-debug.py", line 339<br>
log_file.write('Hello World!' + '\n')<br>
^<br>
IndentationError: unindent does not match any outer indentation level<br>
<br>
### Line 375:<br>
<br>
File "do_auth-debug.py", line 375<br>
return_pairs = av_pairs[2:]<br>
^<br>
IndentationError: unindent does not match any outer indentation level<br>
<br>
<br>
<br>
Here is the log output from do_auth.log. Both of them are with 'aaa authorization exec' enabled on the ServerIron:<br>
<br>
### do_auth.log with -D switch off<br>
<br>
service=shell<br>
cmd*<br>
priv-lvl=15<br>
Thing:priv-lvl<br>
Thing:15<br>
<br>
not len(the_command) > 0<br>
Returning:priv-lvl=15<br>
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'<br>
Exiting status 2<br>
<br>
### do_auth.log with -D switch on<br>
<br>
service=shell<br>
cmd=show<br>
cmd-arg=users<br>
cmd-arg=wide<br>
cmd-arg=<cr><br>
show users wide<br>
2014-03-14 17:39:59: User 'testuser' allowed command 'show users wide' to device '10.99.1.11' in 'test-group'->'command_permit'<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-----Original Message-----<br>
From: heasley [mailto:<a href="mailto:heas@shrubbery.net">heas@shrubbery.net</a>]<br>
Sent: Friday, March 14, 2014 4:39 PM<br>
To: Aaron Wasserott<br>
Cc: <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
Subject: Re: [tac_plus] do_auth and aaa authorization not working with Foundry ServerIronXL load-balancers<br>
<br>
Fri, Mar 14, 2014 at 04:17:00PM +0000, Aaron Wasserott:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> I am hoping to find a way to modify how do_auth communicates with the ServerIron's that leaves debugging off, and authorization on.<br>
<br>
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.<br>
it may be that it should be exiting with code 1.<br>
_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
</div></div></blockquote></div><br></div>
<pre>
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.