This is an interesting case, because what I have discovered in this debugging is that the Cisco hardware in fact, does not send along any attributes it requires other than "service=shell". For testing I am using a Cisco 7600.<div>
<br></div><div>I configured tac_plus like so:</div><div><br></div><div><div>group = admin {</div><div><br></div><div> default service = permit</div><div> service = exec {</div><div> optional priv-lvl = 15</div>
<div> bogus = fail</div><div> }</div><div><br></div><div>}</div><div><br></div><div>So that's "priv-lvl*15" and "bogus=fail" on the wire... </div><div><br></div><div>On the 7600 I turned on "debug aaa authorization", and upon trying to login, this was the debug output:</div>
<div><br></div><div><div>31w1d: AAA: parse name=tty1 idb type=-1 tty=-1</div><div>31w1d: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1 channel=0</div><div>31w1d: AAA/MEMORY: create_user (0x5105D0E8) user='NULL' ruser='NULL' ds0=0 port='tty1' rem_addr='10.178.91.108' authen_type=ASCII service=LOGIN priv=1 initial_task_id='0', vrf= (id=0)</div>
<div>31w1d: tty1 AAA/AUTHOR/EXEC (431951709): Port='tty1' list='' service=EXEC</div><div>31w1d: AAA/AUTHOR/EXEC: tty1 (431951709) user='jathan'</div><div>31w1d: tty1 AAA/AUTHOR/EXEC (431951709): send AV service=shell</div>
<div>31w1d: tty1 AAA/AUTHOR/EXEC (431951709): send AV cmd*</div><div>31w1d: tty1 AAA/AUTHOR/EXEC (431951709): found list "default"</div><div>31w1d: tty1 AAA/AUTHOR/EXEC (431951709): Method=tacacs+ (tacacs+)</div>
<div>31w1d: AAA/AUTHOR/TAC+: (431951709): user=jathan</div><div>31w1d: AAA/AUTHOR/TAC+: (431951709): send AV service=shell</div><div>31w1d: AAA/AUTHOR/TAC+: (431951709): send AV cmd*</div><div>31w1d: AAA/AUTHOR (431951709): Post authorization status = PASS_ADD</div>
<div>31w1d: AAA/AUTHOR/EXEC: Processing AV service=shell</div><div>31w1d: AAA/AUTHOR/EXEC: Processing AV cmd*</div><div>31w1d: AAA/AUTHOR/EXEC: Processing AV bogus=fail</div><div>31w1d: AAA/AUTHOR/EXEC: received unknown mandatory AV: bogus=fail</div>
<div>31w1d: AAA/AUTHOR/EXEC: Authorization FAILED</div><div>31w1d: AAA/MEMORY: free_user (0x5105D0E8) user='jathan' ruser='NULL' port='tty1' rem_addr='10.178.91.108' authen_type=ASCII service=LOGIN priv=1</div>
</div><div><br></div><div>Per the RFC, the Cisco 7600 received a mandatory attribute it could not process, and it failed authorization. Bravo! Observe, however, that the Cisco device never sent "priv-lvl" in its authorization request to the server.</div>
<div><br></div><div>That means we also learned is that the Cisco is never propositioning the server to say "I require priv-lvl" to be set, because it really doesn't. This attribute defaults internally to 1. One may successfully obtain a shell without that attribute set and upon login, you are dropped to a non-enabled ">" prompt. By sending along priv-lvl, you are telling the device escalate your privileges to the number specified (where 15 is super-user), thereby auto-enabling you and presenting you with the "#" prompt.</div>
<div><br></div><div>With that in mind, it's now clear that the Brocade VDX is in fact NOT behaving correctly when it receives unknown attributes. If I attempt to connect to the VDX again using those same attributes including "bogus=fail", it still allows me to connect as a read-only user. The VDX requires the "brcd-role=admin" attribute set in order to escalate your shell to super-user, but it is not by definition a mandatory attribute.</div>
<div><br></div><div>So... I still think there is value in having a way within the tac_plus server configuration to always send optional attributes to devices. We need a way to tell the server to send optional attributes that weren't necessarily requested by the NAS. I think the ability to utilize a utility like do_auth.py is invaluable, but I believe it would be wise for us to consider whether that is the best place to maintain that functionality in the long term. </div>
<div><br></div><div>jathan.</div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 2:10 PM, heasley <span dir="ltr"><<a href="mailto:heas@shrubbery.net">heas@shrubbery.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wed, Jan 25, 2012 at 08:20:50AM -0700, Daniel Schmidt:<br>
<div class="im">> This I why I added the "av_pair kluging" to do_auth. Users with Nexus,<br>
> Brocade, Cisco, XR & whatever can all play nice together on one tac_plus<br>
> server. And, network operators can all have appropriate read-only<br>
> accounts, despite vendor differences. It's not to fix the limitations of<br>
> tac_plus, it's to fix the limitations (bugs) of the vendors. Well, that<br>
> and multiple groups per user.<br>
<br>
</div>I'll leave the code as is for now. perhaps a host {} knob to enable it<br>
is appropriate, or disable it.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Jathan.<br>--<br>
</div>