[tac_plus] Should optional A/V pair be sent?
Daniel Schmidt
daniel.schmidt at wyo.gov
Mon Jan 23 19:14:45 UTC 2012
Do_auth 1.9 can append or remove* av_pairs now, that’s essentially what I’m
doing below. I think I added that feature while trying to fix the Nexus.
(Thought I told Jathan?) I believe 1.9 is in the tarball, but I haven’t
posted anything on tacacs.org because I’ve been busy and there wasn’t a
lot of interest in it or the Nexus fixes. (tac_plus does what most people
need without do_auth)
In short: The tac_pairs for the nexus created the same problem people
experience with Brocade, but there was an easy way to distinguish the nexus
from everything else by noting a subtle difference in the tac_pairs nexus
sends. (If Brocade didn’t mimic Cisco, I could implement a fix for it as
well) Hence, in do_auth is a trivial, automatic routine: if(found_nexus),
send(“shell:roles”), else pass. Thus, it sends shell:roles only to the
nexus, and priv-lvl to the Cisco. It’s a kluge, and Cisco may change the
pairs, but it works quite well for now. If you wish to establish roles
and priv-lvls, it appears impossible to use one tac_plus server for nexus
and Cisco unless you use do_auth 1.9 or some other after-authentication
fix/kluge. Not to imply this is an issue with tac_plus, it’s a Cisco issue.
Anyway, I would imagine “optional” would have to be triggered somehow by
the Brocade sending some sort of tac_key to tac_plus, but I’ve never seen
anything like that – please comment if you know more on the subject or have
an example of the tac_pairs sent.
*Haven’t actually tried to remove pairs, but should work if you put nothing
after the comma
*From:* Jathan McCollum [mailto:jathan at gmail.com]
*Sent:* Monday, January 23, 2012 10:41 AM
*To:* Mick Day
*Cc:* Daniel Schmidt; tac_plus at shrubbery.net
*Subject:* Re: [tac_plus] Should optional A/V pair be sent?
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 <http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus%0d%0aE-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.
--
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/20120123/77bbf922/attachment.html>
More information about the tac_plus
mailing list