[tac_plus] Should optional A/V pair be sent?
Jathan McCollum
jathan at gmail.com
Tue Jan 24 21:33:32 UTC 2012
FYI-
Confirmed! With a slight modification, this configuration is a working
solution. I am able to successfully authenticate to both the Brocade VDX
and a Cisco 7600.
In do_auth.ini I had to specify av_pairs like this:
av_pairs =
brcd-role,brcd-role*admin
(Specifying "brcd-role=admin,brcd-role*admin" did not cause it to be
replaced.)
Here is the confirmation of the input AV pairs, and what they are replaced
with:
Tue Jan 24 13:15:37 2012 [21669]: input service=shell
Tue Jan 24 13:15:37 2012 [21669]: input cmd*
Tue Jan 24 13:15:37 2012 [21669]: input priv-lvl=15
Tue Jan 24 13:15:37 2012 [21669]: input brcd-role=admin
Tue Jan 24 13:15:37 2012 [21669]: output priv-lvl=15
Tue Jan 24 13:15:37 2012 [21669]: output brcd-role*admin
And happy login prompts on both devices:
(Cisco)
User Access Verification
Username: jathan
Password:
external1a-7600#
(Brocade)
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#
On Tue, Jan 24, 2012 at 11:56 AM, Daniel Schmidt <daniel.schmidt at wyo.gov>wrote:
> 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.
>
>
>
--
Jathan.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20120124/ec1ff4e1/attachment.html>
More information about the tac_plus
mailing list