<div dir="ltr">It does work.  Order and number of pairs matter - put priv-lvl first.  </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 18, 2016 at 2:41 AM, Tom Storey <span dir="ltr"><<a href="mailto:tom@snnap.net" target="_blank">tom@snnap.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah but as per the article I linked, it *should* do some translation to derive the privlvl from some other AV pair.<div><br></div><div>Will investigate the do_auth route as we have a multi-vendor environment at play.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2016 at 18:32, Daniel Schmidt <span dir="ltr"><<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah.... I don' t think that is going to work.  I'm pretty sure you can only have one priv-lvl.  I can't remember if Brocade is smart enough to figure it out, I'm pretty sure Cisco is not.  That's why Jathan and I wrote do_auth, so you can swap that tac_pair based on what IP it comes from.  If you don't have any cisco, just pull the priv-lvl out.  If not, consider do_auth. </div><div class="m_-1416603691592351633HOEnZb"><div class="m_-1416603691592351633h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 6:39 AM, Tom Storey <span dir="ltr"><<a href="mailto:tom@snnap.net" target="_blank">tom@snnap.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah, foundry-privlvl and brocade-privlvl did nothing. Also per my original email I seemed to try brcd-role.<div><br></div><div><div>aaa authentication enable implicit-user</div><div>aaa authentication login default tacacs+ local</div><div>aaa authorization commands 0 default tacacs+ none<br></div><span><div>aaa authorization exec default tacacs+</div><div>aaa accounting commands 0 default start-stop tacacs+</div><div>aaa accounting exec default start-stop tacacs+</div><div>aaa accounting system default start-stop tacacs+</div></span><div>!</div></div><div><br></div><div><span><div>group = read_write {</div><div>    default service = permit</div></span><div>    acl = venus_nets</div><div>    </div><div>    service = exec {</div><div>        idletime = 30</div><div>        priv-lvl = 15</div><div>        <insert other priv level></div><div>    }</div><div>}</div></div><div><br></div><div>I had to add the foundry-privlvl/brocade-privlv<wbr>l AVs as optional, otherwise they were mandatory and would break login on things like Cisco.</div><div><br></div><div>Also, as per the link below, it would seem that I shouldnt even need to specify a Foundry/Brocade specific AV, because it should take the last numeric AV as the privlvl, and translate Cisco-esque priv levels in to its own scheme.</div><div><br></div><div><a href="http://www.brocade.com/content/html/en/configuration-guide/FI_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html" target="_blank">http://www.brocade.com/content<wbr>/html/en/configuration-guide/F<wbr>I_08030_SECURITY/GUID-A2449097<wbr>-2DA4-4CD1-B2DA-C531D7A90587.h<wbr>tml</a><span class="m_-1416603691592351633m_-4824632719990647289HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-1416603691592351633m_-4824632719990647289HOEnZb"><font color="#888888"><div><br></div><div>Tom</div><div><br></div></font></span></div><div class="m_-1416603691592351633m_-4824632719990647289HOEnZb"><div class="m_-1416603691592351633m_-4824632719990647289h5"><div class="gmail_extra"><br><div class="gmail_quote">On 16 November 2016 at 15:01, Eldon Koyle <span dir="ltr"><<a href="mailto:ekoyle+puck.nether.net@gmail.com" target="_blank">ekoyle+puck.nether.net@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Did you try the foundry-privlvl one?  Also, if you are using tac_plus, you should be able to enable debug and look at the actual avp's sent/received by the server.</p><span class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800HOEnZb"><font color="#888888">
<p dir="ltr">-- <br>
Eldon</p></font></span><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800HOEnZb"><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 16, 2016 5:09 AM, "Tom Storey" <<a href="mailto:tom@snnap.net" target="_blank">tom@snnap.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Daniel,<div><br></div><div>I hadnt tried the brocade-privlvl AV pair before, so I gave that a try, but still that didnt seem to enable me upon login.</div><div><br></div><div>Either the TACACS server isnt sending the AV pair (although I believe it is, because if it is not made optional, then I cant login to Cisco devices for example), or the Brocades are just ignoring them or Im just doing something really wrong...</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 November 2016 at 17:06, Daniel Schmidt <span dir="ltr"><<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Brocade has the brocade specific brocade-privlvl, with three different levels of access as I remember, 1, 4 and 5.  The mapping between the two is not always good.  For instance, on Brocade, as I remember, 1 on Cisco maps to 4 of Brocade, which is just stupid - it should map to 5.  (Granted, this was years ago, it may have changed)  As a shameless plug, it's not hard to do modify this with tac_plus & do_auth provided you can distinguish by device IP.  You can authorize by priv levels or commands.  I wrote about it years ago here:<br><br><a href="http://www.tacacs.org/tacacsplus/2012/02/06/disable-account-on-brocade" target="_blank">http://www.tacacs.org/tacacspl<wbr>us/2012/02/06/disable-account-<wbr>on-brocade</a><br></div><div><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800m_-4697297825553810826m_2672963624859438933h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 5, 2016 at 1:32 PM, Eldon Koyle <span dir="ltr"><<a href="mailto:ekoyle+puck.nether.net@gmail.com" target="_blank">ekoyle+puck.nether.net@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I did notice that document says privlvl and not priv-lvl.  Depending on what you changed, you may be able to see the enable attempt on the tacacs server (it may just be expecting the same username/password with admin privs on tacacs).</p><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800m_-4697297825553810826m_2672963624859438933m_-1834327981839455876HOEnZb"><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800m_-4697297825553810826m_2672963624859438933m_-1834327981839455876h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 5, 2016 11:06 AM, "Tom Storey" <<a href="mailto:tom@snnap.net" target="_blank">tom@snnap.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Eldon,<div><br></div><div>Thanks for pointing me to this document.</div><div><br></div><div>If I understand it correctly, my existing configuration should have been working just fine as it is. Since I wasnt specifying the "foundry-privlvl" attribute, it should look for the last exec attribute with a number in it and treat that number as the priv level. In my case Im using "priv-lvl" with a value of 15 for my Cisco devices, so the Brocade should have translated that to mean level 0 given a lack of "foundry-privlvl" attribute.</div><div><br></div><div>But for what ever reason that doesnt seem to be working. So I also tried specifying it explicitly in my config, including removing the priv-lvl attribute, but still to no avail.</div><div><br></div><div>Ive managed to lock myself out of my test device now (can no longer enable, its asking for a username, doh!), its in the office and Im at home. So I guess I'll resume on Monday if anyone else comes up with anything. :-)</div><div><br></div><div>Thanks</div><div>Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 November 2016 at 20:53, Eldon Koyle <span dir="ltr"><<a href="mailto:ekoyle+puck.nether.net@gmail.com" target="_blank">ekoyle+puck.nether.net@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We use foundry-privlvl = 0 for admin access.<br>
<br>
See also: <a href="http://www.brocade.com/content/html/en/configuration-guide/FI_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html" rel="noreferrer" target="_blank">http://www.brocade.com/content<wbr>/html/en/configuration-guide/F<wbr>I_08030_SECURITY/GUID-A2449097<wbr>-2DA4-4CD1-B2DA-C531D7A90587.h<wbr>tml</a><br>
<br>
--<br>
Eldon<br>
<div><div class="m_-1416603691592351633m_-4824632719990647289m_-4314283504754810800m_-4697297825553810826m_2672963624859438933m_-1834327981839455876m_318517198259953205m_-5859492176705583369h5"><br>
On Fri, Nov 4, 2016 at 5:26 AM, Tom Storey <<a href="mailto:tom@snnap.net" target="_blank">tom@snnap.net</a>> wrote:<br>
> Hi everyone,<br>
><br>
> Implementing a TACACS server for a network that I am working on, and I am<br>
> trying to determine how to have certain users (e.g. network admins) enabled<br>
> by default once they have logged in, but certain other users (e.g. support<br>
> group) logged in as read only, and requiring them to enable manually.<br>
><br>
> Ive seen some suggestions of using an optional av pair "brcd-role = admin"<br>
> in the TACACS config, but seems this is for VDX devices, and I am working<br>
> with ICX.<br>
><br>
> The usual "priv-lvl = 15" that works with Cisco doesnt seem to apply, and Im<br>
> finding scant other information about how to do this other than specifying<br>
> "aaa authentication login privilege-mode", but that would have all users<br>
> enabled once they have logged in.<br>
><br>
> My configs look like:<br>
><br>
> aaa authentication enable default enable<br>
> aaa authentication login default tacacs+<br>
> aaa authorization commands 0 default tacacs+<br>
> aaa authorization exec default tacacs+<br>
> aaa accounting commands 0 default start-stop tacacs+<br>
> aaa accounting exec default start-stop tacacs+<br>
> aaa accounting system default start-stop tacacs+<br>
><br>
> and on the TACACS server Ive tried:<br>
><br>
> group = read_write {<br>
>     default service = permit<br>
>     acl = network_nets<br>
><br>
>     service = exec {<br>
>         priv-lvl = 15<br>
>         optional brcd-role = admin<br>
>     }<br>
> }<br>
><br>
> Or maybe the reason I cant find any information is because this just isnt<br>
> possible on a Brocade?<br>
><br>
> Any help appreciated!<br>
><br>
> Thanks<br>
> Tom<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> foundry-nsp mailing list<br>
> <a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
> <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/mailman<wbr>/listinfo/foundry-nsp</a><br>
</blockquote></div><br></div>
</blockquote></div></div>
</div></div><br>______________________________<wbr>_________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/mailman<wbr>/listinfo/foundry-nsp</a><br></blockquote></div><br></div>

<br>
<br></div></div>E-Mail to and from me, in connection with the transaction <br>of public business, is subject to the Wyoming Public Records <br>Act and may be disclosed to third parties.<br></blockquote></div><br></div>
</blockquote></div></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/mailman<wbr>/listinfo/foundry-nsp</a><br></blockquote></div><br></div>

<br>
<br>E-Mail to and from me, in connection with the transaction <br>of public business, is subject to the Wyoming Public Records <br>Act and may be disclosed to third parties.<br></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<br>
<br>E-Mail to and from me, in connection with the transaction <br>of public business, is subject to the Wyoming Public Records <br>Act and may be disclosed to third parties.<br>