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

[Mick Day]

My personal opinion on this (for what it is worth) is that tac_plus should
at the very least have a knob to turn on/off sending of optional attributes
even when NAS does not specifically request them.

As mentioned before I have gone through the whole debug piece with other
versions of tacacs+ and others do send optional by default, including Cisco
ACS

-----Original Message-----
From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net]
On Behalf Of Daniel Schmidt
Sent: 25 January 2012 20:52
To: Jathan McCollum; heasley
Cc: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Should optional A/V pair be sent?

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/a
ttachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus