[tac_plus] Should optional A/V pair be sent?
Daniel Schmidt
daniel.schmidt at wyo.gov
Tue Jan 24 16:56:12 UTC 2012
Thanks for the information, let me correct myself. Admittedly, I haven’t
tried optional av pairs. Thus, I can only say with certainty that sending
a Cisco a mandatory av pair it doesn’t understand causes it to work
incorrectly. I might recommend Jathan now try such for compatibility with
Brocade and Cisco:
group = admin {
default service = permit
service = exec {
priv-lvl = 15
brcd-role = admin
}
av_pairs =
brcd-role=admin, brcd-role*admin
*From:* Mick Day [mailto:mick at mickday.com]
*Sent:* Tuesday, January 24, 2012 9:36 AM
*To:* 'Daniel Schmidt'; 'Jathan McCollum'
*Cc:* tac_plus at shrubbery.net
*Subject:* RE: [tac_plus] Should optional A/V pair be sent?
I have tested using Cisco devices against other TACACS+ software (Cisco ACS
and tacacs.net) both of which do send optional a/v pairs and Cisco devices
do exactly what I would expect they should do with optional a/v pairs and
ignore them and authorisation is passed.
*From:* Daniel Schmidt [mailto:daniel.schmidt at wyo.gov<daniel.schmidt at wyo.gov>]
*Sent:* 24 January 2012 16:31
*To:* Jathan McCollum
*Cc:* Mick Day; tac_plus at shrubbery.net
*Subject:* RE: [tac_plus] Should optional A/V pair be sent?
In do_auth, I simply provide ways to get around the #*(@ stupid things
vendors do. I do not think that tac_plus should change to accommodate the
whim of every vendor who does something different. If there is a bug in
that the optional roles were not sent, Cisco would probably freak out when
it received them anyway. Please see if you can get the Cisco to honor it’s
priv-lvl while ignoring the brcd-role.
*From:* Jathan McCollum [mailto:jathan at gmail.com]
*Sent:* Tuesday, January 24, 2012 9:02 AM
*To:* Daniel Schmidt
*Cc:* Mick Day; tac_plus at shrubbery.net
*Subject:* Re: [tac_plus] Should optional A/V pair be sent?
Thanks, Dan.
I tested this and it works replacing the attribute with "brcd-role*admin".
I need to test whether I can have this interop with my Cisco gear and lock
in a working solution. I should have a confirmation before the end of the
day.
In the meantime, is the official stance now to rely on do_auth.py now that
it's being bundled with the daemon? If not, it seems to me like there is a
bug in the daemon preventing it from properly sending optional attributes
over the wire, and I feel like addressing it there is the right place.
Please correct me if I'm wrong!
jathan.
On Tue, Jan 24, 2012 at 7:51 AM, Daniel Schmidt <daniel.schmidt at wyo.gov>
wrote:
Cisco sends a “cmd*” as the first thing. Being no expert on the subject, I
can only say that unless you strip it, it will not honor your priv-lvl or
any other keys you send. I’d like to see a valid example of the actual
tac_keys received/sent of a working optional key.
I might recommend Jathan try the following experiment:
group = admin {
default service = permit
service = exec {
priv-lvl = 15
}
}
user = jathan {
login = cleartext jathan
pap = cleartext jathan
member = admin
}
And in do_auth 1.9:
av_pairs =
priv-lvl, brcd-role=admin
or perhaps experiment with:
av_pairs =
priv-lvl, brcd-role*admin
*From:* Mick Day [mailto:mick at mickday.com]
*Sent:* Tuesday, January 24, 2012 6:50 AM
*To:* 'Daniel Schmidt'; 'Jathan McCollum'
*Cc:* tac_plus at shrubbery.net
*Subject:* RE: [tac_plus] Should optional A/V pair be sent?
I thought the whole point of optional a/v pairs was that tac_plus should
send these to the NAS with * rather than = and then the NAS has the option
to ignore the attribute whereas with mandatory attributes the NAS must obey
them or deny authorisation, as per the tac_plus FAQ
<snip>
Q). Can someone expand on the use of the "optional" keyword.
A). Most attributes are mandatory i.e. if the daemon sends them to the
NAS, the NAS must obey them or deny the authorization. This is the
default. It is possible to mark attributes as optional, in which case
a NAS which cannot support the attribute is free to simply ignore it
without causing the authorization to fail.
</snip>
The problem is tac_plus is not sending any optional a/v pairs to the NAS at
all and only sends mandatory ones.
*From:* Daniel Schmidt [mailto:daniel.schmidt at wyo.gov<daniel.schmidt at wyo.gov>]
*Sent:* 23 January 2012 19:15
*To:* Jathan McCollum; Mick Day
*Cc:* tac_plus at shrubbery.net
*Subject:* RE: [tac_plus] Should optional A/V pair be sent?
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.
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.
--
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.
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/20120124/23408ea5/attachment.html>
More information about the tac_plus
mailing list