<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In do_auth, I simply provide ways to get around the #*(@ stupid things vendors do. I do not think that tac_plus should change to accommodate the whim of every vendor who does something different. If there is a bug in that the optional roles were not sent, Cisco would probably freak out when it received them anyway. Please see if you can get the Cisco to honor it’s priv-lvl while ignoring the brcd-role. </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal">
<b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Jathan McCollum [mailto:<a href="mailto:jathan@gmail.com">jathan@gmail.com</a>] <br>
<b>Sent:</b> Tuesday, January 24, 2012 9:02 AM<br><b>To:</b> Daniel Schmidt<br><b>Cc:</b> Mick Day; <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br><b>Subject:</b> Re: [tac_plus] Should optional A/V pair be sent?</span></p>
</div><p class="MsoNormal"> </p><p class="MsoNormal">Thanks, Dan. </p><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">I tested this and it works replacing the attribute with "brcd-role*admin". I need to test whether I can have this interop with my Cisco gear and lock in a working solution. I should have a confirmation before the end of the day.</p>
</div><div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">In the meantime, is the official stance now to rely on do_auth.py now that it's being bundled with the daemon? If not, it seems to me like there is a bug in the daemon preventing it from properly sending optional attributes over the wire, and I feel like addressing it there is the right place. Please correct me if I'm wrong! </p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">jathan.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal"> </p><div><p class="MsoNormal">On Tue, Jan 24, 2012 at 7:51 AM, Daniel Schmidt <<a href="mailto:daniel.schmidt@wyo.gov">daniel.schmidt@wyo.gov</a>> wrote:</p>
<div><div><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Cisco sends a “cmd*” as the first thing. Being no expert on the subject, I can only say that unless you strip it, it will not honor your priv-lvl or any other keys you send. I’d like to see a valid example of the actual tac_keys received/sent of a working optional key. </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I might recommend Jathan try the following experiment:</span></p>
<div><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style>group = admin {</p><p class="MsoNormal" style> default service = permit</p>
<p class="MsoNormal" style> service = exec {</p><p class="MsoNormal" style> priv-lvl = 15</p><p class="MsoNormal" style> }</p><p class="MsoNormal" style>}</p></div><p class="MsoNormal" style>user = jathan {</p>
<div><p class="MsoNormal" style> login = cleartext jathan</p><p class="MsoNormal" style> pap = cleartext jathan</p><p class="MsoNormal" style> member = admin</p><p class="MsoNormal" style>}</p><p class="MsoNormal" style>
</p></div><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">And in do_auth 1.9:</span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">av_pairs =</span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> priv-lvl,</span> <span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">brcd-role=admin</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">or perhaps experiment with:</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">av_pairs =</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> priv-lvl,</span> <span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">brcd-role*admin</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Mick Day [mailto:<a href="mailto:mick@mickday.com" target="_blank">mick@mickday.com</a>] <br>
<b>Sent:</b> Tuesday, January 24, 2012 6:50 AM<br><b>To:</b> 'Daniel Schmidt'; 'Jathan McCollum'</span></p><div><div><p class="MsoNormal"><br><b>Cc:</b> <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
<b>Subject:</b> RE: [tac_plus] Should optional A/V pair be sent?</p></div></div></div></div><div><div><p class="MsoNormal" style> </p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I thought the whole point of optional a/v pairs was that tac_plus should send these to the NAS with * rather than = and then the NAS has the option to ignore the attribute whereas with mandatory attributes the NAS must obey them or deny authorisation, as per the tac_plus FAQ</span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><snip></span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New"">Q). Can someone expand on the use of the "optional" keyword.</span></p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New"">A). Most attributes are mandatory i.e. if the daemon sends them to the</span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New""> NAS, the NAS must obey them or deny the authorization. This is the</span></p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New""> default. It is possible to mark attributes as optional, in which case</span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New""> a NAS which cannot support the attribute is free to simply ignore it</span></p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New""> without causing the authorization to fail.</span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></snip></span></p><p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The problem is tac_plus is not sending any optional a/v pairs to the NAS at all and only sends mandatory ones.</span></p>
<p class="MsoNormal" style><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Daniel Schmidt [<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">mailto:daniel.schmidt@wyo.gov</a>] <br>
<b>Sent:</b> 23 January 2012 19:15<br><b>To:</b> Jathan McCollum; Mick Day<br><b>Cc:</b> <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br><b>Subject:</b> RE: [tac_plus] Should optional A/V pair be sent?</span></p>
</div></div><p class="MsoNormal" style><span lang="EN-GB"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Do_auth 1.9 can append or remove* av_pairs now, that’s essentially what I’m doing below. I think I added that feature while trying to fix the Nexus. (Thought I told Jathan?) I believe 1.9 is in the tarball, but I haven’t posted anything on <a href="http://tacacs.org" target="_blank">tacacs.org</a> because I’ve been busy and there wasn’t a lot of interest in it or the Nexus fixes. (tac_plus does what most people need without do_auth) </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In short: The tac_pairs for the nexus created the same problem people experience with Brocade, but there was an easy way to distinguish the nexus from everything else by noting a subtle difference in the tac_pairs nexus sends. (If Brocade didn’t mimic Cisco, I could implement a fix for it as well) Hence, in do_auth is a trivial, automatic routine: if(found_nexus), send(“shell:roles”), else pass. Thus, it sends shell:roles only to the nexus, and priv-lvl to the Cisco. It’s a kluge, and Cisco may change the pairs, but it works quite well for now. If you wish to establish roles and priv-lvls, it appears impossible to use one tac_plus server for nexus and Cisco unless you use do_auth 1.9 or some other after-authentication fix/kluge. Not to imply this is an issue with tac_plus, it’s a Cisco issue.</span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Anyway, I would imagine “optional” would have to be triggered somehow by the Brocade sending some sort of tac_key to tac_plus, but I’ve never seen anything like that – please comment if you know more on the subject or have an example of the tac_pairs sent. </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal" style><span style="font-size:8.0pt;font-family:"Calibri","sans-serif";color:#1f497d">*Haven’t actually tried to remove pairs, but should work if you put nothing after the comma </span></p>
<p class="MsoNormal" style><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Jathan McCollum [mailto:<a href="mailto:jathan@gmail.com" target="_blank">jathan@gmail.com</a>] <br>
<b>Sent:</b> Monday, January 23, 2012 10:41 AM<br><b>To:</b> Mick Day<br><b>Cc:</b> Daniel Schmidt; <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br><b>Subject:</b> Re: [tac_plus] Should optional A/V pair be sent?</span></p>
</div><p class="MsoNormal" style> </p><div><div><div><div><p class="MsoNormal" style>I am still having the exact same problem. </p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>The tac_plus daemon is NOT sending optional a/v pairs over the wire at all. I had been in communication with Dan back in September about modifying do_auth.py to be able to append or remove a/v pairs. Currently do_auth.py is only able to replace existing pairs. I was going to try to contribute code to make do_auth.py do this, but it got de-prioritized until last week and I had to move onto something else. I am just now revisiting this issue.</p>
</div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>Using this configuration:</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>group = admin {</p></div><div>
<p class="MsoNormal" style> default service = permit</p></div><div><p class="MsoNormal" style> service = exec {</p></div><div><p class="MsoNormal" style> optional brcd-role = admin</p></div><div><p class="MsoNormal" style>
priv-lvl = 15</p></div><div><p class="MsoNormal" style> }</p></div><div><p class="MsoNormal" style>}</p></div><div><p class="MsoNormal" style>user = jathan {</p></div><div><p class="MsoNormal" style> login = cleartext jathan</p>
</div><div><p class="MsoNormal" style> pap = cleartext jathan</p></div><div><p class="MsoNormal" style> member = admin</p></div><div><p class="MsoNormal" style>}</p></div><div><p class="MsoNormal" style> </p></div>
<div><p class="MsoNormal" style>And running tac_plus with maximum debug output, you see this when I login to the device and it sends the authorization request:</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>
Mon Jan 23 09:26:11 2012 [11716]: Start authorization request</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1 attr=acl rec=1</p></div><div><p class="MsoNormal" style>
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: do_author: user='jathan'</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1 attr=before rec=1</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: user 'jathan' found</p></div><div><p class="MsoNormal" style>
Mon Jan 23 09:26:11 2012 [11716]: exec authorization request for jathan</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: username=jathan N_svc_exec proto= svcname= rec=1</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: exec is explicitly permitted by line 6</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: username=jathan N_svc_exec proto= svcname= rec=1</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: nas:service=shell (passed thru)</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: nas:cmd= (passed thru)</p></div><div><p class="MsoNormal" style>
Mon Jan 23 09:26:11 2012 [11716]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: added 1 args</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: out_args[0] = service=shell input copy discarded</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: out_args[1] = cmd= input copy discarded</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: out_args[2] = priv-lvl=15 compacted to out_args[0]</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: 1 output args</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1 attr=after rec=1</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div>
<p class="MsoNormal" style>Mon Jan 23 09:26:11 2012 [11716]: Writing AUTHOR/PASS_ADD size=30</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>Which results in this experience on the device:</p>
</div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>vdxhub1-lab-sw0 login: jathan</p></div><div><p class="MsoNormal" style>Password: </p></div><div><p class="MsoNormal" style>User's role is unavailable, using default.</p>
</div><div><p class="MsoNormal" style>Welcome to the Brocade Network Operating System Software</p></div><div><p class="MsoNormal" style>jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0</p></div><div><p class="MsoNormal" style>
vdxhub1-lab-sw0# </p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>Now, if I change that a/v pair to mandatory (remove the optional prefix):</p></div><div><p class="MsoNormal" style> </p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: Start authorization request</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1 attr=acl rec=1</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: do_author: user='jathan'</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1 attr=before rec=1</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: user 'jathan' found</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: exec authorization request for jathan</p></div><div>
<p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: username=jathan N_svc_exec proto= svcname= rec=1</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: exec is explicitly permitted by line 6</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: username=jathan N_svc_exec proto= svcname= rec=1</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: nas:service=shell (passed thru)</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: nas:cmd= (passed thru)</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: nas:absent, server:brcd-role=admin -> add brcd-role=admin (k)</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: added 2 args</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: out_args[0] = service=shell input copy discarded</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: out_args[1] = cmd= input copy discarded</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: out_args[2] = brcd-role=admin compacted to out_args[0]</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: out_args[3] = priv-lvl=15 compacted to out_args[1]</p>
</div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: 2 output args</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1 attr=after rec=1</p></div>
<div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div><div>
<p class="MsoNormal" style>Mon Jan 23 09:30:29 2012 [11851]: Writing AUTHOR/PASS_ADD size=46</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>Note that it accurately picked up the attribute from the config and sent it back to the device. When I login to the device, I get the admin privileges I am expecting:</p>
</div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>vdxhub1-lab-sw0 login: jathan</p></div><div><p class="MsoNormal" style>Password: </p></div><div><p class="MsoNormal" style>Welcome to the Brocade Network Operating System Software</p>
</div><div><p class="MsoNormal" style>jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0</p></div><div><p class="MsoNormal" style>vdxhub1-lab-sw0# </p></div><div><p class="MsoNormal" style> </p></div><div>
<p class="MsoNormal" style>This does seem like a bug in tac_plus in which it is not sending optional A/V pairs at all. So I have two asks of this list:</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>
1. Would it be possible by someone familiar with the C code to confirm as to whether this is actually a bug or not? If so, would it be possible to get it addressed for a upcoming release? </p></div><div><p class="MsoNormal" style>
</p></div><div><p class="MsoNormal" style>2. Dan, if you have the resources/time would you be willing to add the support for the av_pairs_append thing you and I had talked about in email? (I had gotten it working in my lab before, but you have since updated do_auth.py to version 1.8).</p>
</div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>Thanks,</p></div><div><p class="MsoNormal" style> </p></div><div><p class="MsoNormal" style>jathan.</p></div><div><p class="MsoNormal" style>
</p></div><div><p class="MsoNormal" style>On Mon, Jan 23, 2012 at 8:07 AM, Mick Day <<a href="mailto:mick@mickday.com" target="_blank">mick@mickday.com</a>> wrote:</p><p class="MsoNormal" style>Hi,<br><br>Thanks for the information but my specific question was regarding how<br>
tac_plus deals with optional a/v pairs , in the following configuration<br>should the a/v pair " brcd-role*admin" be sent to NAS?</p><div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>group = admin {<br>
default service = permit<br> service = exec {<br> priv-lvl = 15<br> optional brcd-role = admin<br> }<br>}</p></div><p class="MsoNormal" style>I have now tested this with Cisco ACS and TACACS.net both of which send the<br>
optional a/v pair but tac_plus does not?</p><div><div><p class="MsoNormal" style><br>-----Original Message-----<br>From: Daniel Schmidt [mailto:<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>]<br>
Sent: 23 January 2012 15:34<br>To: Mick Day; <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>Subject: RE: [tac_plus] Should optional A/V pair be sent?<br><br>I also have noted that if you send a Cisco switch/router anything other than<br>
"priv-lvl", they do not work. One workaround is to use do_auth. The<br>following example is brocade's traditional privlvl, but the same concept<br>should work with the brcd-role you describe. (Note, this is more to fix a<br>
Cisco bug than a Brocade) Simply put: If you match a brocade device and<br>find something that says "priv-lvl" replace it with "brocade-privlvl=5"<br><br>[brocade_disable]<br>host_allow =<br> .*<br>
device_permit =<br> <list of brocade devices><br>command_permit =<br> .*<br>av_pairs =<br> priv-lvl,brocade-privlvl=5<br><br>-----Original Message-----<br>From: <a href="mailto:tac_plus-bounces@shrubbery.net" target="_blank">tac_plus-bounces@shrubbery.net</a><br>
[mailto:<a href="mailto:tac_plus-bounces@shrubbery.net" target="_blank">tac_plus-bounces@shrubbery.net</a>] On Behalf Of Mick Day<br>Sent: Monday, January 23, 2012 4:31 AM<br>To: <a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br>
Subject: [tac_plus] Should optional A/V pair be sent?<br><br>Hi Everyone,<br><br>I am having a problem with sending optional a/v pair from tac_plus, this is<br>related to post<br><a href="http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html" target="_blank">http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html</a> as it<br>
now appears that the latest Brocade VDX code now supports optional a/v pairs<br>for 'brcd-role' the only problem is that when the NAS authenticates with the<br>server only the mandatory a/v pairs are being sent<br>
<br>My configuration is as follows:<br><br>group = admin {<br> default service = permit<br> service = exec {<br> priv-lvl = 15<br> optional brcd-role = admin<br> }<br>}<br><br>The NAS only ever receives the a/v pair ' priv-lvl = 15' is this expected<br>
behaviour? If I reconfigure the 'brcd-role' to a mandatory it then sends<br>both 'priv-lvl' and 'brcd-role' but then this creates the same problem as<br>described in previous post<br><a href="http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html" target="_blank">http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html</a><br>
where Cisco devices fail authorisation.<br><br>I have also tried the same with Cisco ACS and this sends both the mandatory<br>and optional a/v pairs allowing both devices to be able to login.<br><br>I am unclear as to whether it is expected behaviour for server to send<br>
optional a/v pairs by default?<br><br>_______________________________________________<br>tac_plus mailing list<br><a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br><a href="http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus%0d%0aE-Mail" target="_blank">http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus<br>
E-Mail</a> to and from me, in connection with the transaction of public<br>business,is subject to the Wyoming Public Records Act, and may be disclosed<br>to third parties.<br><br>_______________________________________________<br>
tac_plus mailing list<br><a href="mailto:tac_plus@shrubbery.net" target="_blank">tac_plus@shrubbery.net</a><br><a href="http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus</a></p>
</div></div></div><p class="MsoNormal" style><br><br clear="all"></p><div><p class="MsoNormal" style> </p></div><p class="MsoNormal" style>-- <br>Jathan.<br>--</p></div></div></div><pre><span lang="EN-GB">E-Mail to and from me, in connection with the transaction </span></pre>
<pre><span lang="EN-GB">of public business,is subject to the Wyoming Public Records </span></pre><pre><span lang="EN-GB">Act, and may be disclosed to third parties.</span></pre><pre><span lang="EN-GB"> </span></pre></div>
</div></div></div><div><div><pre>E-Mail to and from me, in connection with the transaction </pre><pre>of public business,is subject to the Wyoming Public Records </pre><pre>Act, and may be disclosed to third parties.</pre>
<pre> </pre></div></div></div><p class="MsoNormal"><br><br clear="all"></p><div><p class="MsoNormal"> </p></div><p class="MsoNormal">-- <br>Jathan.<br>--</p></div></div></div></body></html>
<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.