<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;}
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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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">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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I might recommend Jathan try the following experiment:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal">group = admin {</p><p class="MsoNormal"> default service = permit</p>
<p class="MsoNormal"> service = exec {</p><p class="MsoNormal"> priv-lvl = 15</p><p class="MsoNormal"> }</p><p class="MsoNormal">}</p><p class="MsoNormal">user = jathan {</p><p class="MsoNormal"> login = cleartext jathan</p>
<p class="MsoNormal"> pap = cleartext jathan</p><p class="MsoNormal"> member = admin</p><p class="MsoNormal">}</p><p class="MsoNormal"> </p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">And in do_auth 1.9:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">av_pairs =</span></p>
<p class="MsoNormal"><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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">or perhaps experiment with:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">av_pairs =</span></p>
<p class="MsoNormal"><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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><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">
<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">mick@mickday.com</a>] <br>
<b>Sent:</b> Tuesday, January 24, 2012 6:50 AM<br><b>To:</b> 'Daniel Schmidt'; 'Jathan McCollum'<br><b>Cc:</b> <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></div><p class="MsoNormal"> </p><p class="MsoNormal"><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"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><snip></span></p>
<p class="MsoNormal"><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"><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"><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"><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"><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"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Courier New""> without causing the authorization to fail.</span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></snip></span></p><p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><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"><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"><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">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">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"><span lang="EN-GB"> </span></p><p class="MsoNormal"><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">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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><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"><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> 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">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><div><div><div><div><p class="MsoNormal">I am still having the exact same problem. </p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">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"> </p></div><div><p class="MsoNormal">Using this configuration:</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">group = admin {</p></div><div><p class="MsoNormal"> default service = permit</p>
</div><div><p class="MsoNormal"> service = exec {</p></div><div><p class="MsoNormal"> optional brcd-role = admin</p></div><div><p class="MsoNormal"> priv-lvl = 15</p></div><div><p class="MsoNormal"> }</p>
</div><div><p class="MsoNormal">}</p></div><div><p class="MsoNormal">user = jathan {</p></div><div><p class="MsoNormal"> login = cleartext jathan</p></div><div><p class="MsoNormal"> pap = cleartext jathan</p></div>
<div><p class="MsoNormal"> member = admin</p></div><div><p class="MsoNormal">}</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">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"> </p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: Start authorization request</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">
Mon Jan 23 09:26:11 2012 [11716]: do_author: user='jathan'</p></div><div><p class="MsoNormal">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">
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: user 'jathan' found</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: exec authorization request for jathan</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: exec is explicitly permitted by line 6</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: nas:service=shell (passed thru)</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: nas:cmd= (passed thru)</p></div><div><p class="MsoNormal">
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">Mon Jan 23 09:26:11 2012 [11716]: added 1 args</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: out_args[0] = service=shell input copy discarded</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: out_args[1] = cmd= input copy discarded</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:26:11 2012 [11716]: 1 output args</p></div><div><p class="MsoNormal">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">
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">Mon Jan 23 09:26:11 2012 [11716]: Writing AUTHOR/PASS_ADD size=30</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Which results in this experience on the device:</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">vdxhub1-lab-sw0 login: jathan</p>
</div><div><p class="MsoNormal">Password: </p></div><div><p class="MsoNormal">User's role is unavailable, using default.</p></div><div><p class="MsoNormal">Welcome to the Brocade Network Operating System Software</p></div>
<div><p class="MsoNormal">jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0</p></div><div><p class="MsoNormal">vdxhub1-lab-sw0# </p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Now, if I change that a/v pair to mandatory (remove the optional prefix):</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: Start authorization request</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">
Mon Jan 23 09:30:29 2012 [11851]: do_author: user='jathan'</p></div><div><p class="MsoNormal">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">
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: user 'jathan' found</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: exec authorization request for jathan</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: exec is explicitly permitted by line 6</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto= svcname=</p>
</div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: nas:service=shell (passed thru)</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: nas:cmd= (passed thru)</p></div><div><p class="MsoNormal">
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">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">Mon Jan 23 09:30:29 2012 [11851]: added 2 args</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: out_args[0] = service=shell input copy discarded</p></div><div><p class="MsoNormal">
Mon Jan 23 09:30:29 2012 [11851]: out_args[1] = cmd= input copy discarded</p></div><div><p class="MsoNormal">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">
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">Mon Jan 23 09:30:29 2012 [11851]: 2 output args</p></div><div><p class="MsoNormal">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">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin</p></div><div><p class="MsoNormal">Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL</p></div><div><p class="MsoNormal">
Mon Jan 23 09:30:29 2012 [11851]: Writing AUTHOR/PASS_ADD size=46</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">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"> </p></div><div><p class="MsoNormal">vdxhub1-lab-sw0 login: jathan</p></div><div><p class="MsoNormal">Password: </p></div><div><p class="MsoNormal">Welcome to the Brocade Network Operating System Software</p>
</div><div><p class="MsoNormal">jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0</p></div><div><p class="MsoNormal">vdxhub1-lab-sw0# </p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">
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"> </p></div><div><p class="MsoNormal">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"> </p></div><div><p class="MsoNormal">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"> </p></div><div><p class="MsoNormal">Thanks,</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">
On Mon, Jan 23, 2012 at 8:07 AM, Mick Day <<a href="mailto:mick@mickday.com">mick@mickday.com</a>> wrote:</p><p class="MsoNormal">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">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">
<br>-----Original Message-----<br>From: Daniel Schmidt [mailto:<a href="mailto:daniel.schmidt@wyo.gov">daniel.schmidt@wyo.gov</a>]<br>Sent: 23 January 2012 15:34<br>To: Mick Day; <a href="mailto:tac_plus@shrubbery.net">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">tac_plus-bounces@shrubbery.net</a><br>[mailto:<a href="mailto:tac_plus-bounces@shrubbery.net">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">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">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">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"><br><br clear="all"></p><div><p class="MsoNormal"> </p></div><p class="MsoNormal">-- <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>
</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.