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

Jathan McCollum jathan at gmail.com
Mon Jan 23 17:41:01 UTC 2012


I am still having the exact same problem.

The tac_plus daemon is NOT sending optional a/v pairs over the wire at all.
I had been in communication with Dan back in September about modifying
do_auth.py to be able to append or remove a/v pairs. Currently do_auth.py
is only able to replace existing pairs. I was going to try to contribute
code to make do_auth.py do this, but it got de-prioritized until last week
and I had to move onto something else. I am just now revisiting this issue.

Using this configuration:

group = admin {
    default service = permit
    service = exec {
        optional brcd-role = admin
        priv-lvl = 15
    }
}
user = jathan {
    login = cleartext jathan
    pap   = cleartext jathan
    member = admin
}

And running tac_plus with maximum debug output, you see this when I login
to the device and it sends the authorization request:

Mon Jan 23 09:26:11 2012 [11716]: Start authorization request
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1
attr=acl rec=1
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:26:11 2012 [11716]: do_author: user='jathan'
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1
attr=before rec=1
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:26:11 2012 [11716]: user 'jathan' found
Mon Jan 23 09:26:11 2012 [11716]: exec authorization request for jathan
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: username=jathan
N_svc_exec proto= svcname= rec=1
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto=
svcname=
Mon Jan 23 09:26:11 2012 [11716]: exec is explicitly permitted by line 6
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: username=jathan
N_svc_exec proto= svcname= rec=1
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: recurse group = admin
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_svc_node: found N_svc_exec proto=
svcname=
Mon Jan 23 09:26:11 2012 [11716]: nas:service=shell (passed thru)
Mon Jan 23 09:26:11 2012 [11716]: nas:cmd= (passed thru)
Mon Jan 23 09:26:11 2012 [11716]: nas:absent, server:priv-lvl=15 -> add
priv-lvl=15 (k)
Mon Jan 23 09:26:11 2012 [11716]: added 1 args
Mon Jan 23 09:26:11 2012 [11716]: out_args[0] = service=shell input copy
discarded
Mon Jan 23 09:26:11 2012 [11716]: out_args[1] = cmd= input copy discarded
Mon Jan 23 09:26:11 2012 [11716]: out_args[2] = priv-lvl=15 compacted to
out_args[0]
Mon Jan 23 09:26:11 2012 [11716]: 1 output args
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: name=jathan isuser=1
attr=after rec=1
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_value: recurse group = admin
Mon Jan 23 09:26:11 2012 [11716]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:26:11 2012 [11716]: Writing AUTHOR/PASS_ADD size=30

Which results in this experience on the device:

vdxhub1-lab-sw0 login: jathan
Password:
User's role is unavailable, using default.
Welcome to the Brocade Network Operating System Software
jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0
vdxhub1-lab-sw0#

Now, if I change that a/v pair to mandatory (remove the optional prefix):

Mon Jan 23 09:30:29 2012 [11851]: Start authorization request
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1
attr=acl rec=1
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:30:29 2012 [11851]: do_author: user='jathan'
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1
attr=before rec=1
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:30:29 2012 [11851]: user 'jathan' found
Mon Jan 23 09:30:29 2012 [11851]: exec authorization request for jathan
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: username=jathan
N_svc_exec proto= svcname= rec=1
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto=
svcname=
Mon Jan 23 09:30:29 2012 [11851]: exec is explicitly permitted by line 6
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: username=jathan
N_svc_exec proto= svcname= rec=1
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: recurse group = admin
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_svc_node: found N_svc_exec proto=
svcname=
Mon Jan 23 09:30:29 2012 [11851]: nas:service=shell (passed thru)
Mon Jan 23 09:30:29 2012 [11851]: nas:cmd= (passed thru)
Mon Jan 23 09:30:29 2012 [11851]: nas:absent, server:brcd-role=admin -> add
brcd-role=admin (k)
Mon Jan 23 09:30:29 2012 [11851]: nas:absent, server:priv-lvl=15 -> add
priv-lvl=15 (k)
Mon Jan 23 09:30:29 2012 [11851]: added 2 args
Mon Jan 23 09:30:29 2012 [11851]: out_args[0] = service=shell input copy
discarded
Mon Jan 23 09:30:29 2012 [11851]: out_args[1] = cmd= input copy discarded
Mon Jan 23 09:30:29 2012 [11851]: out_args[2] = brcd-role=admin compacted
to out_args[0]
Mon Jan 23 09:30:29 2012 [11851]: out_args[3] = priv-lvl=15 compacted to
out_args[1]
Mon Jan 23 09:30:29 2012 [11851]: 2 output args
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: name=jathan isuser=1
attr=after rec=1
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_value: recurse group = admin
Mon Jan 23 09:30:29 2012 [11851]: cfg_get_pvalue: returns NULL
Mon Jan 23 09:30:29 2012 [11851]: Writing AUTHOR/PASS_ADD size=46

Note that it accurately picked up the attribute from the config and sent it
back to the device.  When I login to the device, I get the admin privileges
I am expecting:

vdxhub1-lab-sw0 login: jathan
Password:
Welcome to the Brocade Network Operating System Software
jathan connected from 10.178.91.108 using console on vdxhub1-lab-sw0
vdxhub1-lab-sw0#

This does seem like a bug in tac_plus in which it is not sending optional
A/V pairs at all.  So I have two asks of this list:

1. Would it be possible by someone familiar with the C code to confirm as
to whether this is actually a bug or not? If so, would it be possible to
get it addressed for a upcoming release?

2. Dan, if you have the resources/time would you be willing to add the
support for the av_pairs_append thing you and I had talked about in email?
(I had gotten it working in my lab before, but you have since updated
do_auth.py to version 1.8).

Thanks,

jathan.

On Mon, Jan 23, 2012 at 8:07 AM, Mick Day <mick at mickday.com> wrote:

> Hi,
>
> Thanks for the information but my specific question was regarding how
> tac_plus deals with optional a/v pairs , in the following configuration
> should the a/v pair " brcd-role*admin" be sent to NAS?
>
> group = admin {
>       default service = permit
>       service = exec {
>          priv-lvl = 15
>          optional brcd-role = admin
>    }
> }
>
> I have now tested this with Cisco ACS and TACACS.net both of which send the
> optional a/v pair but tac_plus does not?
>
> -----Original Message-----
> From: Daniel Schmidt [mailto:daniel.schmidt at wyo.gov]
> Sent: 23 January 2012 15:34
> To: Mick Day; tac_plus at shrubbery.net
> Subject: RE: [tac_plus] Should optional A/V pair be sent?
>
> I also have noted that if you send a Cisco switch/router anything other
> than
> "priv-lvl", they do not work.  One workaround is to use do_auth.  The
> following example is brocade's traditional privlvl, but the same concept
> should work with the brcd-role you describe. (Note, this is more to fix a
> Cisco bug than a Brocade)  Simply put: If you match a brocade device and
> find something that says "priv-lvl" replace it with "brocade-privlvl=5"
>
> [brocade_disable]
> host_allow =
>        .*
> device_permit =
>        <list of brocade devices>
> command_permit =
>        .*
> av_pairs =
>        priv-lvl,brocade-privlvl=5
>
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Mick Day
> Sent: Monday, January 23, 2012 4:31 AM
> To: tac_plus at shrubbery.net
> Subject: [tac_plus] Should optional A/V pair be sent?
>
> Hi Everyone,
>
> I am having a problem with sending optional a/v pair from tac_plus, this is
> related to post
> http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html as
> it
> now appears that the latest Brocade VDX code now supports optional a/v
> pairs
> for 'brcd-role' the only problem is that when the NAS authenticates with
> the
> server only the mandatory a/v pairs are being sent
>
> My configuration is as follows:
>
> group = admin {
>       default service = permit
>       service = exec {
>          priv-lvl = 15
>          optional brcd-role = admin
>    }
> }
>
> The NAS only ever receives the a/v pair ' priv-lvl = 15' is this expected
> behaviour?  If I reconfigure the 'brcd-role' to a mandatory it then sends
> both 'priv-lvl' and 'brcd-role' but then this creates the same problem as
> described in previous post
> http://www.shrubbery.net/pipermail/tac_plus/2011-September/000978.html
> where Cisco devices fail authorisation.
>
> I have also tried the same with Cisco ACS and this sends both the mandatory
> and optional a/v pairs allowing both devices to be able to login.
>
> I am unclear as to whether it is expected behaviour for server to send
> optional a/v pairs by default?
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> 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.
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>



-- 
Jathan.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20120123/5592ab14/attachment.html>


More information about the tac_plus mailing list