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

[Jathan McCollum]

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.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20120125/c8d880cc/attachment.html>