[tac_plus] Should optional A/V pair be sent?

[Daniel Schmidt]

7600 is required to support it, tacacs isn’t required to have it though.
 How would tac_plus answer if nobody defined priv-lvl?



*From:* Jathan McCollum [mailto:jathan at gmail.com]
*Sent:* Wednesday, January 25, 2012 12:51 PM
*To:* heasley
*Cc:* Daniel Schmidt; tac_plus at shrubbery.net
*Subject:* Re: [tac_plus] Should optional A/V pair be sent?



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.



I configured tac_plus like so:



group = admin {



    default service = permit

    service = exec {

        optional priv-lvl = 15

        bogus = fail

    }



}



So that's "priv-lvl*15" and "bogus=fail" on the wire...



On the 7600 I turned on "debug aaa authorization", and upon trying to
login, this was the debug output:



31w1d: AAA: parse name=tty1 idb type=-1 tty=-1

31w1d: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1
channel=0

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)

31w1d: tty1 AAA/AUTHOR/EXEC (431951709): Port='tty1' list='' service=EXEC

31w1d: AAA/AUTHOR/EXEC: tty1 (431951709) user='jathan'

31w1d: tty1 AAA/AUTHOR/EXEC (431951709): send AV service=shell

31w1d: tty1 AAA/AUTHOR/EXEC (431951709): send AV cmd*

31w1d: tty1 AAA/AUTHOR/EXEC (431951709): found list "default"

31w1d: tty1 AAA/AUTHOR/EXEC (431951709): Method=tacacs+ (tacacs+)

31w1d: AAA/AUTHOR/TAC+: (431951709): user=jathan

31w1d: AAA/AUTHOR/TAC+: (431951709): send AV service=shell

31w1d: AAA/AUTHOR/TAC+: (431951709): send AV cmd*

31w1d: AAA/AUTHOR (431951709): Post authorization status = PASS_ADD

31w1d: AAA/AUTHOR/EXEC: Processing AV service=shell

31w1d: AAA/AUTHOR/EXEC: Processing AV cmd*

31w1d: AAA/AUTHOR/EXEC: Processing AV bogus=fail

31w1d: AAA/AUTHOR/EXEC: received unknown mandatory AV: bogus=fail

31w1d: AAA/AUTHOR/EXEC: Authorization FAILED

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



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.



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.



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.



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.



jathan.



On Wed, Jan 25, 2012 at 2:10 PM, heasley <heas at shrubbery.net> wrote:

Wed, Jan 25, 2012 at 08:20:50AM -0700, Daniel Schmidt:

> This I why I added the "av_pair kluging" to do_auth.  Users with Nexus,
> Brocade, Cisco, XR & whatever can all play nice together on one tac_plus
> server.  And, network operators can all have appropriate read-only
> accounts, despite vendor differences.  It's not to fix the limitations of
> tac_plus, it's to fix the limitations (bugs) of the vendors.  Well, that
> and multiple groups per user.

I'll leave the code as is for now.  perhaps a host {} knob to enable it
is appropriate, or disable it.





-- 
Jathan.
--

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20120125/f79f0571/attachment.html>