From joe.moore at holidaycompanies.com Tue Jan 10 21:52:37 2012 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Tue, 10 Jan 2012 21:52:37 +0000 Subject: [tac_plus] Auth Fail Lock Message-ID: <7DC5CF25DDD70D4A845DDC2F96E116B2E764@HCEXCH02.holidaycompanies.com> I have been happily running tac_plus F4.0.4.19 with the Auth Fail Lock patch for some time, on a pair of FreeBSD 7.x servers. Upon upgrading one of those servers to FreeBSD 8.x, tac_plus stopped recognizing the "auth-fail-lock 4 120 600" parameter in my config file and refused to start. Fresh builds of 4.0.4.19 (with the AFL patch) on a fresh FreeBSD 8.2 install also failed to start for the same reason. Is the AFL feature now implemented differently, or am I going to have to switch to Linux to make this work? Going without AFL is not an option since I have to prove to a security auditor that we don't allow unlimited login attempts to routers etc... ...jgm -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Tue Jan 10 22:31:33 2012 From: heas at shrubbery.net (heasley) Date: Tue, 10 Jan 2012 22:31:33 +0000 Subject: [tac_plus] Auth Fail Lock In-Reply-To: <7DC5CF25DDD70D4A845DDC2F96E116B2E764@HCEXCH02.holidaycompanies.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2E764@HCEXCH02.holidaycompanies.com> Message-ID: <20120110223133.GE7866@shrubbery.net> Tue, Jan 10, 2012 at 09:52:37PM +0000, Joe Moore: > I have been happily running tac_plus F4.0.4.19 with the Auth Fail Lock patch for some time, on a pair of FreeBSD 7.x servers. > > Upon upgrading one of those servers to FreeBSD 8.x, tac_plus stopped recognizing the "auth-fail-lock 4 120 600" parameter in my config file and refused to start. > > Fresh builds of 4.0.4.19 (with the AFL patch) on a fresh FreeBSD 8.2 install also failed to start for the same reason. > > Is the AFL feature now implemented differently, or am I going to have to switch to Linux to make this work? Going without AFL is not an option since I have to prove to a security auditor that we don't allow unlimited login attempts to routers etc... thats not a feature of this tacacs, its DoS vector as far as i am concerned. it must have been a fbsd ports patch. > ...jgm > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From jathan at gmail.com Wed Jan 11 02:11:33 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 10 Jan 2012 18:11:33 -0800 Subject: [tac_plus] Auth Fail Lock In-Reply-To: <7DC5CF25DDD70D4A845DDC2F96E116B2E764@HCEXCH02.holidaycompanies.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2E764@HCEXCH02.holidaycompanies.com> Message-ID: FYI this patch was created by Mark Ellzey Thomas, who has published it to GitHub. Ask him nicely and I'm sure he'd provide a new patch. :) https://github.com/ellzey/tac_plus_AFL jathan. On Tue, Jan 10, 2012 at 1:52 PM, Joe Moore wrote: > I have been happily running tac_plus F4.0.4.19 with the Auth Fail Lock > patch for some time, on a pair of FreeBSD 7.x servers. > > Upon upgrading one of those servers to FreeBSD 8.x, tac_plus stopped > recognizing the "auth-fail-lock 4 120 600" parameter in my config file and > refused to start. > > Fresh builds of 4.0.4.19 (with the AFL patch) on a fresh FreeBSD 8.2 > install also failed to start for the same reason. > > Is the AFL feature now implemented differently, or am I going to have to > switch to Linux to make this work? Going without AFL is not an option since > I have to prove to a security auditor that we don't allow unlimited login > attempts to routers etc... > > ...jgm > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20120110/793e15bd/attachment.html > > > _______________________________________________ > 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: From ignas.kazlauskas at ittc.vu.lt Thu Jan 12 08:17:23 2012 From: ignas.kazlauskas at ittc.vu.lt (Ignas Kazlauskas) Date: Thu, 12 Jan 2012 10:17:23 +0200 Subject: [tac_plus] host acl always denies Message-ID: <4F0E9713.6090609@ittc.vu.lt> Hello, I have a simple tac_plus config with a host acl. The problem is I always get denied, even with ".*". Tried versions tacacs+-F4.0.4.20 and tacacs+-F5.0.0a1. What's wrong (Linux CentOS6, Debian6)? tac_plus.conf ============= accounting file = /var/log/tacacs/acc.log key = testing123 acl = alist { permit = .* permit = ^192.* permit = 192.168.111\.12$ permit = 192.168.111.12 permit = 192\.168\.111.* permit = ^192\.168\.111\.12$ } user = fred { login = cleartext fred enable = cleartext enab15 # I can connect when the following line is commented acl = alist service = exec { } } IOS === ! ip tacacs source-interface FastEthernet1/0 ! interface FastEthernet1/0 ip address 192.168.111.12 255.255.255.0 speed auto duplex auto ! tac.log ======= Wed Jan 11 10:36:55 2012 [19954]: Reading config Wed Jan 11 10:36:55 2012 [19954]: Version F5.0.0a1 Initialized 1 Wed Jan 11 10:36:55 2012 [19954]: tac_plus server F5.0.0a1 starting Wed Jan 11 10:36:55 2012 [19954]: uid=0 euid=0 gid=0 egid=0 s=4 Wed Jan 11 10:36:59 2012 [19954]: session.peerip is 192.168.111.12 Wed Jan 11 10:36:59 2012 [19955]: connect from 192.168.111.12 [192.168.111.12] Wed Jan 11 10:37:03 2012 [19955]: verify daemon fred == NAS fred Wed Jan 11 10:37:03 2012 [19955]: Password is correct Wed Jan 11 10:37:03 2012 [19955]: Password has not expired Wed Jan 11 10:37:03 2012 [19955]: cfg_acl_check(alist, 192.168.111.12) Wed Jan 11 10:37:03 2012 [19955]: ip 192.168.111.12 did not match in acl filter alist Wed Jan 11 10:37:03 2012 [19955]: host ACLs for user 'fred' deny Wed Jan 11 10:37:03 2012 [19955]: login query for 'fred' tty2 from 192.168.111.12 rejected Wed Jan 11 10:37:03 2012 [19955]: login failure: fred 192.168.111.12 (192.168.111.12) tty2 -- Ignas K. From heas at shrubbery.net Thu Jan 12 16:47:46 2012 From: heas at shrubbery.net (heasley) Date: Thu, 12 Jan 2012 16:47:46 +0000 Subject: [tac_plus] host acl always denies In-Reply-To: <4F0E9713.6090609@ittc.vu.lt> References: <4F0E9713.6090609@ittc.vu.lt> Message-ID: <20120112164746.GI88468@shrubbery.net> Thu, Jan 12, 2012 at 10:17:23AM +0200, Ignas Kazlauskas: > Hello, > I have a simple tac_plus config with a host acl. The problem is I always > get denied, even with ".*". Tried versions tacacs+-F4.0.4.20 and > tacacs+-F5.0.0a1. What's wrong (Linux CentOS6, Debian6)? > > tac_plus.conf > ============= > > accounting file = /var/log/tacacs/acc.log > key = testing123 > > acl = alist { > permit = .* > permit = ^192.* > permit = 192.168.111\.12$ > permit = 192.168.111.12 > permit = 192\.168\.111.* > permit = ^192\.168\.111\.12$ > } perhaps trailing whitespace or non-printable characters? > user = fred { > login = cleartext fred > enable = cleartext enab15 > # I can connect when the following line is commented > acl = alist > service = exec { } > } > > IOS > === > ! > ip tacacs source-interface FastEthernet1/0 > ! > interface FastEthernet1/0 > ip address 192.168.111.12 255.255.255.0 > speed auto > duplex auto > ! > > tac.log > ======= > > Wed Jan 11 10:36:55 2012 [19954]: Reading config > Wed Jan 11 10:36:55 2012 [19954]: Version F5.0.0a1 Initialized 1 > Wed Jan 11 10:36:55 2012 [19954]: tac_plus server F5.0.0a1 starting > Wed Jan 11 10:36:55 2012 [19954]: uid=0 euid=0 gid=0 egid=0 s=4 > Wed Jan 11 10:36:59 2012 [19954]: session.peerip is 192.168.111.12 > Wed Jan 11 10:36:59 2012 [19955]: connect from 192.168.111.12 > [192.168.111.12] > Wed Jan 11 10:37:03 2012 [19955]: verify daemon fred == NAS fred > Wed Jan 11 10:37:03 2012 [19955]: Password is correct > Wed Jan 11 10:37:03 2012 [19955]: Password has not expired date set> > Wed Jan 11 10:37:03 2012 [19955]: cfg_acl_check(alist, 192.168.111.12) > Wed Jan 11 10:37:03 2012 [19955]: ip 192.168.111.12 did not match in acl > filter alist > Wed Jan 11 10:37:03 2012 [19955]: host ACLs for user 'fred' deny > Wed Jan 11 10:37:03 2012 [19955]: login query for 'fred' tty2 from > 192.168.111.12 rejected > Wed Jan 11 10:37:03 2012 [19955]: login failure: fred 192.168.111.12 > (192.168.111.12) tty2 > > > -- > Ignas K. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From ignas.kazlauskas at ittc.vu.lt Fri Jan 13 09:52:30 2012 From: ignas.kazlauskas at ittc.vu.lt (Ignas Kazlauskas) Date: Fri, 13 Jan 2012 11:52:30 +0200 Subject: [tac_plus] host acl always denies In-Reply-To: <20120112164746.GI88468@shrubbery.net> References: <4F0E9713.6090609@ittc.vu.lt> <20120112164746.GI88468@shrubbery.net> Message-ID: <4F0FFEDE.1030404@ittc.vu.lt> On 2012.01.12 18:47, heasley wrote: > Thu, Jan 12, 2012 at 10:17:23AM +0200, Ignas Kazlauskas: >> Hello, >> I have a simple tac_plus config with a host acl. The problem is I always >> get denied, even with ".*". Tried versions tacacs+-F4.0.4.20 and >> tacacs+-F5.0.0a1. What's wrong (Linux CentOS6, Debian6)? >> >> tac_plus.conf >> ============= >> >> accounting file = /var/log/tacacs/acc.log >> key = testing123 >> >> acl = alist { >> permit = .* >> permit = ^192.* >> permit = 192.168.111\.12$ >> permit = 192.168.111.12 >> permit = 192\.168\.111.* >> permit = ^192\.168\.111\.12$ >> } > > perhaps trailing whitespace or non-printable characters? I have deleted all unnecessary whitespaces and checked for non-printable characters with ":set list" in vim - no changes. I also tried version F4.0.4.19 and it works as expected. I see that one of the changes in F4.0.4.20 was "- Drop the private regex library in favor of libc's. A system w/o a regex is one I dont care about." Maybe I should install some additional packages? It really seems like a regex problem. -- Ignas K. From andreasjacobi85 at gmail.com Thu Jan 19 19:58:36 2012 From: andreasjacobi85 at gmail.com (Andreas Jacobi) Date: Thu, 19 Jan 2012 20:58:36 +0100 Subject: [tac_plus] tac_plus acl match on everything Message-ID: Hi, I have a tac_plus installation on a Slackware server. Everything works fine except my acls. It seems that whatever I type in an acl, it will match. For example an acl with the regexp test will match any of my network equipments source IP addresses. I tested it with a deny acl and here is the debug output (ip is replaced with a fake but you get the idea): ip 11.111.11.1 matched deny regex test of acl filter test-acl The acl config: acl = test-acl { deny = test allow = .* } I then apply the acl to a group. group = test-group { acl = test-acl } tac_plus version F4.0.4.20 What am I missing here? / Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Thu Jan 19 20:52:14 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 19 Jan 2012 22:52:14 +0200 Subject: [tac_plus] tac_plus acl match on everything In-Reply-To: References: Message-ID: <20120119225214.7e1874d6@khamul.example.con> On Thu, 19 Jan 2012 20:58:36 +0100 Andreas Jacobi wrote: > Hi, > > I have a tac_plus installation on a Slackware server. Everything > works fine except my acls. > It seems that whatever I type in an acl, it will match. > > For example an acl with the regexp test will match any of my network > equipments source IP addresses. I tested it with a deny acl and here > is the debug output (ip is replaced with a fake but you get the idea): > ip 11.111.11.1 matched deny regex test of acl filter test-acl > > The acl config: > acl = test-acl { > deny = test > allow = .* > } > > I then apply the acl to a group. > group = test-group { > acl = test-acl > } > > > tac_plus version F4.0.4.20 > > What am I missing here? You aren't missing anything :-) Your syntax is correct and it should do exactly what you expect. My config works along the same lines here and it does the job 100% with several version <=4.0.4.19 You are the second person in a week to raise this very issue with 4.0.4.19 so I would advise you try it with 4.0.4.19 or earlier and see if it occurs there too. As a data point, my tac-plus runs on FreeBSD from ports using the standard setup in the ports Makefile. What platform are you running on? -- Alan McKinnnon alan.mckinnon at gmail.com From heas at shrubbery.net Fri Jan 20 22:50:57 2012 From: heas at shrubbery.net (heasley) Date: Fri, 20 Jan 2012 22:50:57 +0000 Subject: [tac_plus] tac_plus acl match on everything In-Reply-To: <20120120224852.1879388B19@guelah.shrubbery.net> Message-ID: <20120120225057.GU62483@shrubbery.net> Thu, Jan 19, 2012 at 08:58:36PM +0100, Andreas Jacobi: > Hi, > > I have a tac_plus installation on a Slackware server. Everything works fine > except my acls. > It seems that whatever I type in an acl, it will match. > > For example an acl with the regexp test will match any of my network > equipments source IP addresses. I tested it with a deny acl and here is the > debug output (ip is replaced with a fake but you get the idea): > ip 11.111.11.1 matched deny regex test of acl filter test-acl > > The acl config: > acl = test-acl { > deny = test > allow = .* > } > > I then apply the acl to a group. > group = test-group { > acl = test-acl > } > > > tac_plus version F4.0.4.20 > > What am I missing here? A bug; sorry. Here's a patch. Index: do_author.c =================================================================== --- do_author.c (revision 3467) +++ do_author.c (working copy) @@ -21,6 +21,13 @@ #include "tac_plus.h" #include +#ifndef REG_OK +# ifdef REG_NOERROR +# define REG_OK REG_NOERROR +# else +# define REG_OK 0 +# endif +#endif static int arg_ok(char *); static char *assemble_args(struct author_data *); @@ -512,7 +519,6 @@ /* The command exists. The default if nothing matches is DENY */ data->status = AUTHOR_STATUS_FAIL; data->num_out_args = 0; - for (node = node->value1; node && args; node = node->next) { match = regexec((regex_t *)node->value1, args, 0, NULL, 0); @@ -525,7 +531,7 @@ if (match == REG_NOMATCH) continue; - if (match) { + if (match != REG_OK) { regerror(match, (regex_t *)node->value1, buf, 256); report(LOG_INFO, "regexec error: %s on line %d: %s", (char *)node->value, node->line, buf); Index: config.c =================================================================== --- config.c (revision 3467) +++ config.c (working copy) @@ -21,6 +21,13 @@ #include "tac_plus.h" #include +#ifndef REG_OK +# ifdef REG_NOERROR +# define REG_OK REG_NOERROR +# else +# define REG_OK 0 +# endif +#endif /* := * @@ -2037,7 +2044,7 @@ next = acl->nodes; while (next) { - if (regexec((regex_t *)next->value1, ip, 0, NULL, 0)) { + if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) != REG_OK) { if (debug & DEBUG_AUTHEN_FLAG) report(LOG_DEBUG, "ip %s matched %s regex %s of acl filter %s", ip, next->type == S_deny ? "deny" : "permit", From heas at shrubbery.net Fri Jan 20 23:44:36 2012 From: heas at shrubbery.net (heasley) Date: Fri, 20 Jan 2012 23:44:36 +0000 Subject: [tac_plus] host acl always denies In-Reply-To: <4F0FFEDE.1030404@ittc.vu.lt> References: <4F0E9713.6090609@ittc.vu.lt> <20120112164746.GI88468@shrubbery.net> <4F0FFEDE.1030404@ittc.vu.lt> Message-ID: <20120120234435.GY62483@shrubbery.net> Fri, Jan 13, 2012 at 11:52:30AM +0200, Ignas Kazlauskas: > > > On 2012.01.12 18:47, heasley wrote: > > Thu, Jan 12, 2012 at 10:17:23AM +0200, Ignas Kazlauskas: > >> Hello, > >> I have a simple tac_plus config with a host acl. The problem is I always > >> get denied, even with ".*". Tried versions tacacs+-F4.0.4.20 and > >> tacacs+-F5.0.0a1. What's wrong (Linux CentOS6, Debian6)? > >> > >> tac_plus.conf > >> ============= > >> > >> accounting file = /var/log/tacacs/acc.log > >> key = testing123 > >> > >> acl = alist { > >> permit = .* > >> permit = ^192.* > >> permit = 192.168.111\.12$ > >> permit = 192.168.111.12 > >> permit = 192\.168\.111.* > >> permit = ^192\.168\.111\.12$ > >> } > > > > perhaps trailing whitespace or non-printable characters? > > I have deleted all unnecessary whitespaces and checked for non-printable > characters with ":set list" in vim - no changes. have you verified that the client (router/device) is connecting with the ip address that you're trying to match in the acl? From ignas.kazlauskas at ittc.vu.lt Mon Jan 23 08:22:04 2012 From: ignas.kazlauskas at ittc.vu.lt (Ignas Kazlauskas) Date: Mon, 23 Jan 2012 10:22:04 +0200 Subject: [tac_plus] host acl always denies In-Reply-To: <20120120234435.GY62483@shrubbery.net> References: <4F0E9713.6090609@ittc.vu.lt> <20120112164746.GI88468@shrubbery.net> <4F0FFEDE.1030404@ittc.vu.lt> <20120120234435.GY62483@shrubbery.net> Message-ID: <4F1D18AC.6090309@ittc.vu.lt> On 2012.01.21 01:44, heasley wrote: > Fri, Jan 13, 2012 at 11:52:30AM +0200, Ignas Kazlauskas: >> >> >> On 2012.01.12 18:47, heasley wrote: >>> Thu, Jan 12, 2012 at 10:17:23AM +0200, Ignas Kazlauskas: >>>> Hello, >>>> I have a simple tac_plus config with a host acl. The problem is I always >>>> get denied, even with ".*". Tried versions tacacs+-F4.0.4.20 and >>>> tacacs+-F5.0.0a1. What's wrong (Linux CentOS6, Debian6)? >>>> >>>> tac_plus.conf >>>> ============= >>>> >>>> accounting file = /var/log/tacacs/acc.log >>>> key = testing123 >>>> >>>> acl = alist { >>>> permit = .* >>>> permit = ^192.* >>>> permit = 192.168.111\.12$ >>>> permit = 192.168.111.12 >>>> permit = 192\.168\.111.* >>>> permit = ^192\.168\.111\.12$ >>>> } >>> >>> perhaps trailing whitespace or non-printable characters? >> >> I have deleted all unnecessary whitespaces and checked for non-printable >> characters with ":set list" in vim - no changes. > > have you verified that the client (router/device) is connecting with the > ip address that you're trying to match in the acl? tacacs+-F4.0.4.20 ================= Yes I did today with tcpdump on tac_plus server and IPs were OK. I also noticed that host acl seems inverted (just as the other person on this mailing list said). For example if acl = alist { permit = ^192\.168\.111\.12$ } then I get denied from 192.168.111.12 and allowed from everywhere else. But lets move to tacacs+-F4.0.4.21 tacacs+-F4.0.4.21 ================= First of all, thank you for the new version! This version seemed to behave like the v20, until I did this and recompiled: --- config.c.orig 2012-01-23 09:31:32.771632186 +0200 +++ config.c 2012-01-23 09:31:46.107154201 +0200 @@ -2044,7 +2044,7 @@ next = acl->nodes; while (next) { - if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) != REG_OK) { + if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) == REG_OK) { if (debug & DEBUG_AUTHEN_FLAG) report(LOG_DEBUG, "ip %s matched %s regex %s of acl filter %s", ip, next->type == S_deny ? "deny" : "permit", Now acls works as they should, it seems. -- Ignas K. From mick at mickday.com Mon Jan 23 11:30:47 2012 From: mick at mickday.com (Mick Day) Date: Mon, 23 Jan 2012 11:30:47 -0000 Subject: [tac_plus] Should optional A/V pair be sent? Message-ID: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> 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? From daniel.schmidt at wyo.gov Mon Jan 23 15:33:43 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 23 Jan 2012 08:33:43 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> Message-ID: <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> 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 = 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. From mick at mickday.com Mon Jan 23 16:07:27 2012 From: mick at mickday.com (Mick Day) Date: Mon, 23 Jan 2012 16:07:27 -0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> Message-ID: <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> 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 = 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. From jathan at gmail.com Mon Jan 23 17:41:01 2012 From: jathan at gmail.com (Jathan McCollum) Date: Mon, 23 Jan 2012 09:41:01 -0800 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> Message-ID: 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 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 = > > 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: From heas at shrubbery.net Mon Jan 23 18:46:57 2012 From: heas at shrubbery.net (heasley) Date: Mon, 23 Jan 2012 18:46:57 +0000 Subject: [tac_plus] host acl always denies In-Reply-To: <4F1D18AC.6090309@ittc.vu.lt> References: <4F0E9713.6090609@ittc.vu.lt> <20120112164746.GI88468@shrubbery.net> <4F0FFEDE.1030404@ittc.vu.lt> <20120120234435.GY62483@shrubbery.net> <4F1D18AC.6090309@ittc.vu.lt> Message-ID: <20120123184657.GG84593@shrubbery.net> Mon, Jan 23, 2012 at 10:22:04AM +0200, Ignas Kazlauskas: > --- config.c.orig 2012-01-23 09:31:32.771632186 +0200 > +++ config.c 2012-01-23 09:31:46.107154201 +0200 > @@ -2044,7 +2044,7 @@ > > next = acl->nodes; > while (next) { > - if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) != REG_OK) { > + if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) == REG_OK) { > if (debug & DEBUG_AUTHEN_FLAG) > report(LOG_DEBUG, "ip %s matched %s regex %s of acl > filter %s", > ip, next->type == S_deny ? "deny" : "permit", > > > Now acls works as they should, it seems. sigh. indeed; my test cases were not complete. sorry From daniel.schmidt at wyo.gov Mon Jan 23 19:14:45 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Mon, 23 Jan 2012 12:14:45 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> Message-ID: 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 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 = 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. -- 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: From heas at shrubbery.net Mon Jan 23 19:57:42 2012 From: heas at shrubbery.net (heasley) Date: Mon, 23 Jan 2012 19:57:42 +0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> Message-ID: <20120123195742.GN84593@shrubbery.net> Mon, Jan 23, 2012 at 09:41:01AM -0800, Jathan McCollum: > 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) ^^^^^^^^^^^^^^^^^ From heas at shrubbery.net Mon Jan 23 19:59:14 2012 From: heas at shrubbery.net (heasley) Date: Mon, 23 Jan 2012 19:59:14 +0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> Message-ID: <20120123195914.GO84593@shrubbery.net> Mon, Jan 23, 2012 at 12:14:45PM -0700, Daniel Schmidt: > 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) 1.9 is in the F4.0.4.22 tarball. From ignas.kazlauskas at ittc.vu.lt Tue Jan 24 07:09:15 2012 From: ignas.kazlauskas at ittc.vu.lt (Ignas Kazlauskas) Date: Tue, 24 Jan 2012 09:09:15 +0200 Subject: [tac_plus] host acl always denies In-Reply-To: <20120123184657.GG84593@shrubbery.net> References: <4F0E9713.6090609@ittc.vu.lt> <20120112164746.GI88468@shrubbery.net> <4F0FFEDE.1030404@ittc.vu.lt> <20120120234435.GY62483@shrubbery.net> <4F1D18AC.6090309@ittc.vu.lt> <20120123184657.GG84593@shrubbery.net> Message-ID: <4F1E591B.9080502@ittc.vu.lt> On 2012.01.23 20:46, heasley wrote: > Mon, Jan 23, 2012 at 10:22:04AM +0200, Ignas Kazlauskas: >> --- config.c.orig 2012-01-23 09:31:32.771632186 +0200 >> +++ config.c 2012-01-23 09:31:46.107154201 +0200 >> @@ -2044,7 +2044,7 @@ >> >> next = acl->nodes; >> while (next) { >> - if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) != REG_OK) { >> + if (regexec((regex_t *)next->value1, ip, 0, NULL, 0) == REG_OK) { >> if (debug & DEBUG_AUTHEN_FLAG) >> report(LOG_DEBUG, "ip %s matched %s regex %s of acl >> filter %s", >> ip, next->type == S_deny ? "deny" : "permit", >> >> >> Now acls works as they should, it seems. > > sigh. indeed; my test cases were not complete. sorry No worries. Thanks for the REG_OK, the "==" part was easy. -- Ignas K. From mick at mickday.com Tue Jan 24 13:49:56 2012 From: mick at mickday.com (Mick Day) Date: Tue, 24 Jan 2012 13:49:56 -0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> Message-ID: <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> 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 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. 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] 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 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 = 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. -- 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: From daniel.schmidt at wyo.gov Tue Jan 24 15:51:08 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 24 Jan 2012 08:51:08 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> Message-ID: <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> 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 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. 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] *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 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 = 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. -- 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: From jathan at gmail.com Tue Jan 24 15:53:54 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 24 Jan 2012 07:53:54 -0800 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <20120123195742.GN84593@shrubbery.net> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> Message-ID: John- Are you proposing that 'service=shell' is the problem? I've tried setting that within the configuration as well. It doesn't even read it. This config: group = admin { default service = permit service = shell { priv-lvl = 15 brcd-role = admin } } Results in this: Tue Jan 24 07:48:39 2012 [13317]: Start authorization request Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: name=jathan isuser=1 attr=acl rec=1 Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: recurse group = admin Tue Jan 24 07:48:39 2012 [13317]: cfg_get_pvalue: returns NULL Tue Jan 24 07:48:39 2012 [13317]: do_author: user='jathan' Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: name=jathan isuser=1 attr=before rec=1 Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: recurse group = admin Tue Jan 24 07:48:39 2012 [13317]: cfg_get_pvalue: returns NULL Tue Jan 24 07:48:39 2012 [13317]: user 'jathan' found Tue Jan 24 07:48:39 2012 [13317]: exec authorization request for jathan Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: username=jathan N_svc_exec proto= svcname= rec=1 Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: recurse group = admin Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: returns NULL Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: username=jathan N_svc_cmd proto= svcname= rec=1 Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: recurse group = admin Tue Jan 24 07:48:39 2012 [13317]: cfg_get_svc_node: returns NULL Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: name=jathan isuser=1 attr=svc_dflt rec=1 Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: recurse group = admin Tue Jan 24 07:48:39 2012 [13317]: cfg_get_intvalue: returns 22 Tue Jan 24 07:48:39 2012 [13317]: exec permitted by default Tue Jan 24 07:48:39 2012 [13317]: Writing AUTHOR/PASS_ADD size=18 In my past experience all the magc happens in "service = shell". Are there other solutions? On Mon, Jan 23, 2012 at 11:57 AM, heasley wrote: > Mon, Jan 23, 2012 at 09:41:01AM -0800, Jathan McCollum: > > 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) > ^^^^^^^^^^^^^^^^^ > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jathan at gmail.com Tue Jan 24 16:01:58 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 24 Jan 2012 08:01:58 -0800 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> Message-ID: 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 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 > > > > > > 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. > > > > > > 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] > > *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 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 = > > 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-Mailto 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. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Tue Jan 24 16:30:32 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 24 Jan 2012 09:30:32 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> Message-ID: 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 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 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. 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] *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 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 = 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. -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick at mickday.com Tue Jan 24 16:35:58 2012 From: mick at mickday.com (Mick Day) Date: Tue, 24 Jan 2012 16:35:58 -0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> Message-ID: <012b01ccdab6$40c5ce30$c2516a90$@mickday.com> 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] 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 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 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. 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] 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 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 = 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. -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Tue Jan 24 16:56:12 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 24 Jan 2012 09:56:12 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <012b01ccdab6$40c5ce30$c2516a90$@mickday.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> <012b01ccdab6$40c5ce30$c2516a90$@mickday.com> Message-ID: <0ae67eb2f3a613ef5d1676ea06c5b8e0@mail.gmail.com> 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] *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 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 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. 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] *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 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 = 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. -- 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: From heas at shrubbery.net Tue Jan 24 20:29:51 2012 From: heas at shrubbery.net (heasley) Date: Tue, 24 Jan 2012 20:29:51 +0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> Message-ID: <20120124202951.GF33338@shrubbery.net> Tue, Jan 24, 2012 at 07:53:54AM -0800, Jathan McCollum: > John- > > Are you proposing that 'service=shell' is the problem? I've tried setting > that within the configuration as well. It doesn't even read it. This config: i meant that you configured service exec, but the nas is using service shell. > Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: name=jathan isuser=1 > attr=svc_dflt rec=1 ^^^^^^^^^^^^ maybe its just stopping at this. i'd have to look through the code. > Tue Jan 24 07:48:39 2012 [13317]: cfg_get_value: recurse group = admin > Tue Jan 24 07:48:39 2012 [13317]: cfg_get_intvalue: returns 22 > Tue Jan 24 07:48:39 2012 [13317]: exec permitted by default From jathan at gmail.com Tue Jan 24 21:33:32 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 24 Jan 2012 16:33:32 -0500 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <0ae67eb2f3a613ef5d1676ea06c5b8e0@mail.gmail.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <00d401ccda9f$0f3ef060$2dbcd120$@mickday.com> <5ff6ccff7097f279bd8ad6f66fb2657e@mail.gmail.com> <012b01ccdab6$40c5ce30$c2516a90$@mickday.com> <0ae67eb2f3a613ef5d1676ea06c5b8e0@mail.gmail.com> Message-ID: 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 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] > > *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 > 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 > > > > > > 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. > > > > > > 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] > > *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 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 = > > 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-Mailto 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: From heas at shrubbery.net Wed Jan 25 01:23:16 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Jan 2012 01:23:16 +0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <20120124202951.GF33338@shrubbery.net> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> Message-ID: <20120125012315.GA45998@shrubbery.net> handling of optional AVs is coded as 'if the nas didnt send it (as mandatory or optional), then the daemon does not send it'. the ancient ietf draft does not make this necessary. its only assertion is that both sides must ignore optional AVs if they do not support them: The arguments in both a REQUEST and a RESPONSE can be specified as either mandatory or optional. An optional argument is one that may or may not be used, modified or even understood by the recipient. ISTR someone mentioning on this list that some device of theirs threw a fit if it received an optional AVP that it didnt understand. Perhaps daniel? From alan.mckinnon at gmail.com Wed Jan 25 10:15:29 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 25 Jan 2012 12:15:29 +0200 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <20120125012315.GA45998@shrubbery.net> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> Message-ID: <20120125121529.178811ae@khamul.example.con> On Wed, 25 Jan 2012 01:23:16 +0000 heasley wrote: > handling of optional AVs is coded as 'if the nas didnt send it (as > mandatory or optional), then the daemon does not send it'. > > the ancient ietf draft does not make this necessary. its only > assertion is that both sides must ignore optional AVs if they do not > support them: > > The arguments in both a REQUEST and a RESPONSE can be specified as > either mandatory or optional. An optional argument is one that may > or may not be used, modified or even understood by the recipient. > > ISTR someone mentioning on this list that some device of theirs threw > a fit if it received an optional AVP that it didnt understand. > Perhaps daniel? I have Nexus and Juniper kit that does that. When we work around that, the Cisco GSRs fall over and die. Consensus amongst NetOps here is that Tacacs implementations on NASes are so variable and so ill defined that the "standard" is "whatever the vendor decided they feel like doing today". -- Alan McKinnnon alan.mckinnon at gmail.com From jathan at gmail.com Wed Jan 25 14:41:32 2012 From: jathan at gmail.com (Jathan McCollum) Date: Wed, 25 Jan 2012 09:41:32 -0500 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <20120125012315.GA45998@shrubbery.net> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> Message-ID: On the server side, that makes sense. Thanks for confirming! :) I will take this back to Brocade to request that they send the attribute they are requiring for successful authorization. As for devices that freak out when they receive optional AVP, if anyone can think of any that would be helpful! I have a large environment with many and varied devices that are so ancient there is no hope of getting some kind of firmware bug corrected. :) On Tue, Jan 24, 2012 at 8:23 PM, heasley wrote: > handling of optional AVs is coded as 'if the nas didnt send it (as > mandatory or optional), then the daemon does not send it'. > > the ancient ietf draft does not make this necessary. its only assertion > is that both sides must ignore optional AVs if they do not support them: > > The arguments in both a REQUEST and a RESPONSE can be specified as > either mandatory or optional. An optional argument is one that may or > may not be used, modified or even understood by the recipient. > > ISTR someone mentioning on this list that some device of theirs threw a > fit if it received an optional AVP that it didnt understand. Perhaps > daniel? > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Wed Jan 25 15:20:50 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Jan 2012 08:20:50 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> Message-ID: <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> 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. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Jathan McCollum Sent: Wednesday, January 25, 2012 7:42 AM To: heasley Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Should optional A/V pair be sent? On the server side, that makes sense. Thanks for confirming! :) I will take this back to Brocade to request that they send the attribute they are requiring for successful authorization. As for devices that freak out when they receive optional AVP, if anyone can think of any that would be helpful! I have a large environment with many and varied devices that are so ancient there is no hope of getting some kind of firmware bug corrected. :) On Tue, Jan 24, 2012 at 8:23 PM, heasley wrote: > handling of optional AVs is coded as 'if the nas didnt send it (as > mandatory or optional), then the daemon does not send it'. > > the ancient ietf draft does not make this necessary. its only > assertion is that both sides must ignore optional AVs if they do not support them: > > The arguments in both a REQUEST and a RESPONSE can be specified as > either mandatory or optional. An optional argument is one that may or > may not be used, modified or even understood by the recipient. > > ISTR someone mentioning on this list that some device of theirs threw > a fit if it received an optional AVP that it didnt understand. > Perhaps daniel? > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: _______________________________________________ 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. From heas at shrubbery.net Wed Jan 25 19:10:14 2012 From: heas at shrubbery.net (heasley) Date: Wed, 25 Jan 2012 19:10:14 +0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> Message-ID: <20120125191014.GH72937@shrubbery.net> 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. From jathan at gmail.com Wed Jan 25 19:51:02 2012 From: jathan at gmail.com (Jathan McCollum) Date: Wed, 25 Jan 2012 14:51:02 -0500 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <20120125191014.GH72937@shrubbery.net> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> <20120125191014.GH72937@shrubbery.net> Message-ID: 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 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: From daniel.schmidt at wyo.gov Wed Jan 25 20:51:53 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 25 Jan 2012 13:51:53 -0700 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> <20120125191014.GH72937@shrubbery.net> Message-ID: <8cffe38eee32821bae14cae096000e92@mail.gmail.com> 7600 is required to support it, tacacs isn?t required to have it though. How would tac_plus answer if nobody defined priv-lvl? *From:* Jathan McCollum [mailto:jathan at gmail.com] *Sent:* Wednesday, January 25, 2012 12:51 PM *To:* heasley *Cc:* Daniel Schmidt; tac_plus at shrubbery.net *Subject:* Re: [tac_plus] Should optional A/V pair be sent? 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 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. -- 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: From mick at mickday.com Thu Jan 26 09:18:43 2012 From: mick at mickday.com (Mick Day) Date: Thu, 26 Jan 2012 09:18:43 -0000 Subject: [tac_plus] Should optional A/V pair be sent? In-Reply-To: <8cffe38eee32821bae14cae096000e92@mail.gmail.com> References: <008f01ccd9c2$744455a0$5ccd00e0$@mickday.com> <555d3ce405749508ab1ca6f33dfe09c7@mail.gmail.com> <00a001ccd9e9$1abd4240$5037c6c0$@mickday.com> <20120123195742.GN84593@shrubbery.net> <20120124202951.GF33338@shrubbery.net> <20120125012315.GA45998@shrubbery.net> <11e5d831c9e11995bf8728b4fe9c28e9@mail.gmail.com> <20120125191014.GH72937@shrubbery.net> <8cffe38eee32821bae14cae096000e92@mail.gmail.com> Message-ID: <015d01ccdc0b$808f7ce0$81ae76a0$@mickday.com> My personal opinion on this (for what it is worth) is that tac_plus should at the very least have a knob to turn on/off sending of optional attributes even when NAS does not specifically request them. As mentioned before I have gone through the whole debug piece with other versions of tacacs+ and others do send optional by default, including Cisco ACS -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Daniel Schmidt Sent: 25 January 2012 20:52 To: Jathan McCollum; heasley Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Should optional A/V pair be sent? 7600 is required to support it, tacacs isn't required to have it though. How would tac_plus answer if nobody defined priv-lvl? *From:* Jathan McCollum [mailto:jathan at gmail.com] *Sent:* Wednesday, January 25, 2012 12:51 PM *To:* heasley *Cc:* Daniel Schmidt; tac_plus at shrubbery.net *Subject:* Re: [tac_plus] Should optional A/V pair be sent? 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 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. -- 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: _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From hayden at nextlevelinternet.com Thu Jan 26 21:27:30 2012 From: hayden at nextlevelinternet.com (Hayden Katzenellenbogen) Date: Thu, 26 Jan 2012 13:27:30 -0800 Subject: [tac_plus] Questions about a simple setup. Message-ID: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> I have a couple hundred devices that are managed by a support team. They have full access to these devices so I will not need authorization. (In the future I might). If all that I need to do is manage passwords in a central location using tac_plus. Is the config as simple as having a user for each team member and an enable password. And a tac-key. The remote devices then only need authorization commands and the rest can be blank. Next as far as simple security. * I will have the two tac_plus servers behind a firewall only allowing port 49. * I am running as a non-root user. * The configs are not viewable by anyone by root/tacacs user. * Passwords are des encrypted with a salt. For now I want to keep this as simple as possible. Thanks to everyone who responds. Hayden Hayden Katzenellenbogen haydenk at nextlevelinternet.com NextLevel Internet 858-836-0700 www.nextlevelinternet.com By the way, we are never too busy for referrals! If you know someone who might be interested in our services (Hosted PBX, Voice, Internet, Metro Ethernet, Co-Location) or who is unhappy with their current communications provider, we will take exceptional care of them! From alan.mckinnon at gmail.com Thu Jan 26 21:44:41 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 26 Jan 2012 23:44:41 +0200 Subject: [tac_plus] Questions about a simple setup. In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> Message-ID: <20120126234441.6e98de01@khamul.example.con> On Thu, 26 Jan 2012 13:27:30 -0800 "Hayden Katzenellenbogen" wrote: > I have a couple hundred devices that are managed by a support team. > They have full access to these devices so I will not need > authorization. (In the future I might). > > If all that I need to do is manage passwords in a central location > using tac_plus. Is the config as simple as having a user for each > team member and an enable password. And a tac-key. > > The remote devices then only need authorization commands and the rest > can be blank. > > Next as far as simple security. > > * I will have the two tac_plus servers behind a firewall only allowing > port 49. > * I am running as a non-root user. > * The configs are not viewable by anyone by root/tacacs user. > * Passwords are des encrypted with a salt. > > For now I want to keep this as simple as possible. > > Thanks to everyone who responds. Yup, that's pretty much right, you understand it well. Just one thing about password hashes - you don't need to stick to DES (and shouldn't). tac_plus couldn't care less about your password hashes, it completely depends on what your local libc supports. On Linux, that's usually all common hashes. I have tac_plus servers happily working with a mixture of DES, md5 and SHA hashes. I tried running tac_plus as a non-root user. It doesn't work too well - the daemon does the wrong thing if the log files do not already exist. The daemon starts as root to open port 49 for listening, creates the log files (owned by root of course) then drops privs to the tacacs user. At which point the daemon can no longer write to it's own log files and comes to a screeching halt. Silently. That one is hard to debug. You gett he same thing with logrotate if you are not careful. Eventually I just got fed up and recompiled removing the "run as tacacs user" option. The simplest possible way to authorize everything is to create one group with a single directive "permit .*" and assign every user membership to that group. However, you might want to rethink who can run AAA commands. Letting anyone do that just undoes all the hard work you went through to get the goodness of tacacs :-) -- Alan McKinnnon alan.mckinnon at gmail.com From hayden at nextlevelinternet.com Thu Jan 26 22:11:42 2012 From: hayden at nextlevelinternet.com (Hayden Katzenellenbogen) Date: Thu, 26 Jan 2012 14:11:42 -0800 Subject: [tac_plus] Questions about a simple setup. In-Reply-To: <20120126234441.6e98de01@khamul.example.con> References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> <20120126234441.6e98de01@khamul.example.con> Message-ID: <88BC6885D33A9D42A1CCB45E8749525E024B923C@pigeon.sandiego.nextlevelinternet.com> Alan, Thanks for the update. It's funny I ran into all those non-root issues and eventually used worked my way through them. I have the log files owned corrected and then log rotate restarted the daemon after it moves all the logs and sets user/group/permissions. If you are running as root now. Do you just authenticate off the Unix passwd file? Hayden -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, January 26, 2012 1:45 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Questions about a simple setup. On Thu, 26 Jan 2012 13:27:30 -0800 "Hayden Katzenellenbogen" wrote: > I have a couple hundred devices that are managed by a support team. > They have full access to these devices so I will not need > authorization. (In the future I might). > > If all that I need to do is manage passwords in a central location > using tac_plus. Is the config as simple as having a user for each > team member and an enable password. And a tac-key. > > The remote devices then only need authorization commands and the rest > can be blank. > > Next as far as simple security. > > * I will have the two tac_plus servers behind a firewall only allowing > port 49. > * I am running as a non-root user. > * The configs are not viewable by anyone by root/tacacs user. > * Passwords are des encrypted with a salt. > > For now I want to keep this as simple as possible. > > Thanks to everyone who responds. Yup, that's pretty much right, you understand it well. Just one thing about password hashes - you don't need to stick to DES (and shouldn't). tac_plus couldn't care less about your password hashes, it completely depends on what your local libc supports. On Linux, that's usually all common hashes. I have tac_plus servers happily working with a mixture of DES, md5 and SHA hashes. I tried running tac_plus as a non-root user. It doesn't work too well - the daemon does the wrong thing if the log files do not already exist. The daemon starts as root to open port 49 for listening, creates the log files (owned by root of course) then drops privs to the tacacs user. At which point the daemon can no longer write to it's own log files and comes to a screeching halt. Silently. That one is hard to debug. You gett he same thing with logrotate if you are not careful. Eventually I just got fed up and recompiled removing the "run as tacacs user" option. The simplest possible way to authorize everything is to create one group with a single directive "permit .*" and assign every user membership to that group. However, you might want to rethink who can run AAA commands. Letting anyone do that just undoes all the hard work you went through to get the goodness of tacacs :-) -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From alan.mckinnon at gmail.com Thu Jan 26 22:42:48 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 27 Jan 2012 00:42:48 +0200 Subject: [tac_plus] Questions about a simple setup. In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E024B923C@pigeon.sandiego.nextlevelinternet.com> References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> <20120126234441.6e98de01@khamul.example.con> <88BC6885D33A9D42A1CCB45E8749525E024B923C@pigeon.sandiego.nextlevelinternet.com> Message-ID: <20120127004248.477565d3@khamul.example.con> My hashes are in the tac_plus.conf file, bypassing pam and passwd files for authentication entirely. I find it easier to do it that way as I have custom scripts deploying all users to all tacacs_servers - the company's needs are quite complex in that regard. Plus, IIRC I ran into an issue originally with enable passwds - I couldn't get them to work properly in a separate file. I've never bothered checking back if it works now (I have no real need of it). On Thu, 26 Jan 2012 14:11:42 -0800 "Hayden Katzenellenbogen" wrote: > Alan, > > Thanks for the update. It's funny I ran into all those non-root issues > and eventually used worked my way through them. > > I have the log files owned corrected and then log rotate restarted the > daemon after it moves all the logs and sets user/group/permissions. > > If you are running as root now. Do you just authenticate off the Unix > passwd file? > > Hayden > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Thursday, January 26, 2012 1:45 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Questions about a simple setup. > > On Thu, 26 Jan 2012 13:27:30 -0800 > "Hayden Katzenellenbogen" wrote: > > > I have a couple hundred devices that are managed by a support team. > > They have full access to these devices so I will not need > > authorization. (In the future I might). > > > > If all that I need to do is manage passwords in a central location > > using tac_plus. Is the config as simple as having a user for each > > team member and an enable password. And a tac-key. > > > > The remote devices then only need authorization commands and the > > rest can be blank. > > > > Next as far as simple security. > > > > * I will have the two tac_plus servers behind a firewall only > > allowing port 49. > > * I am running as a non-root user. > > * The configs are not viewable by anyone by root/tacacs user. > > * Passwords are des encrypted with a salt. > > > > For now I want to keep this as simple as possible. > > > > Thanks to everyone who responds. > > Yup, that's pretty much right, you understand it well. > > Just one thing about password hashes - you don't need to stick to DES > (and shouldn't). tac_plus couldn't care less about your password > hashes, it completely depends on what your local libc supports. On > Linux, that's usually all common hashes. I have tac_plus servers > happily working with a mixture of DES, md5 and SHA hashes. > > I tried running tac_plus as a non-root user. It doesn't work too well > - the daemon does the wrong thing if the log files do not already > exist. The daemon starts as root to open port 49 for listening, > creates the log files (owned by root of course) then drops privs to > the tacacs user. At which point the daemon can no longer write to > it's own log files and comes to a screeching halt. Silently. That one > is hard to debug. You gett he same thing with logrotate if you are > not careful. Eventually I just got fed up and recompiled removing the > "run as tacacs user" option. > > The simplest possible way to authorize everything is to create one > group with a single directive "permit .*" and assign every user > membership to that group. > > However, you might want to rethink who can run AAA commands. Letting > anyone do that just undoes all the hard work you went through to get > the goodness of tacacs :-) > > -- Alan McKinnnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Fri Jan 27 02:35:35 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 26 Jan 2012 19:35:35 -0700 Subject: [tac_plus] Questions about a simple setup. In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E024B923C@pigeon.sandiego.nextlevelinternet.com> References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> <20120126234441.6e98de01@khamul.example.con> <88BC6885D33A9D42A1CCB45E8749525E024B923C@pigeon.sandiego.nextlevelinternet.com> Message-ID: Can if you want. Easy way to make it so users can change their password. default authentication = file /etc/passwd Doesn't work for enable though - that has to go under the user. Took a crack at it once, failed. No good at C. Have to define it per user: enable = file /etc/passwd -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Hayden Katzenellenbogen Sent: Thursday, January 26, 2012 3:12 PM To: Alan McKinnon; tac_plus at shrubbery.net Subject: Re: [tac_plus] Questions about a simple setup. Alan, Thanks for the update. It's funny I ran into all those non-root issues and eventually used worked my way through them. I have the log files owned corrected and then log rotate restarted the daemon after it moves all the logs and sets user/group/permissions. If you are running as root now. Do you just authenticate off the Unix passwd file? Hayden -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, January 26, 2012 1:45 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Questions about a simple setup. On Thu, 26 Jan 2012 13:27:30 -0800 "Hayden Katzenellenbogen" wrote: > I have a couple hundred devices that are managed by a support team. > They have full access to these devices so I will not need > authorization. (In the future I might). > > If all that I need to do is manage passwords in a central location > using tac_plus. Is the config as simple as having a user for each > team member and an enable password. And a tac-key. > > The remote devices then only need authorization commands and the rest > can be blank. > > Next as far as simple security. > > * I will have the two tac_plus servers behind a firewall only allowing > port 49. > * I am running as a non-root user. > * The configs are not viewable by anyone by root/tacacs user. > * Passwords are des encrypted with a salt. > > For now I want to keep this as simple as possible. > > Thanks to everyone who responds. Yup, that's pretty much right, you understand it well. Just one thing about password hashes - you don't need to stick to DES (and shouldn't). tac_plus couldn't care less about your password hashes, it completely depends on what your local libc supports. On Linux, that's usually all common hashes. I have tac_plus servers happily working with a mixture of DES, md5 and SHA hashes. I tried running tac_plus as a non-root user. It doesn't work too well - the daemon does the wrong thing if the log files do not already exist. The daemon starts as root to open port 49 for listening, creates the log files (owned by root of course) then drops privs to the tacacs user. At which point the daemon can no longer write to it's own log files and comes to a screeching halt. Silently. That one is hard to debug. You gett he same thing with logrotate if you are not careful. Eventually I just got fed up and recompiled removing the "run as tacacs user" option. The simplest possible way to authorize everything is to create one group with a single directive "permit .*" and assign every user membership to that group. However, you might want to rethink who can run AAA commands. Letting anyone do that just undoes all the hard work you went through to get the goodness of tacacs :-) -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus _______________________________________________ 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. From hayden at nextlevelinternet.com Fri Jan 27 03:09:25 2012 From: hayden at nextlevelinternet.com (Hayden Katzenellenbogen) Date: Fri, 27 Jan 2012 03:09:25 -0000 Subject: [tac_plus] Questions about a simple setup. Message-ID: <01a201ccdc9f$1c5fe353$1614a8c0@sandiego.nextlevelinternet.com> I understand using the passwd file for user authentication. But if you use it for enable, what do you need to have in the passwd file or does it use the users passed again. right now I am using sha/md5 hashes. I have a low number of users who do not actually have direct access to the tac servers, so user password management is not a major issue. any other suggestions are appreciated. Thanks Hayden Sent from my Verizon Wireless Phone ----- Reply message ----- From: "Daniel Schmidt" Date: Thu, Jan 26, 2012 6:35 pm Subject: [tac_plus] Questions about a simple setup. To: "Hayden Katzenellenbogen" , "tac_plus at shrubbery.net" Can if you want. Easy way to make it so users can change their password. default authentication = file /etc/passwd Doesn't work for enable though - that has to go under the user. Took a crack at it once, failed. No good at C. Have to define it per user: enable = file /etc/passwd -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Hayden Katzenellenbogen Sent: Thursday, January 26, 2012 3:12 PM To: Alan McKinnon; tac_plus at shrubbery.net Subject: Re: [tac_plus] Questions about a simple setup. Alan, Thanks for the update. It's funny I ran into all those non-root issues and eventually used worked my way through them. I have the log files owned corrected and then log rotate restarted the daemon after it moves all the logs and sets user/group/permissions. If you are running as root now. Do you just authenticate off the Unix passwd file? Hayden -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, January 26, 2012 1:45 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] Questions about a simple setup. On Thu, 26 Jan 2012 13:27:30 -0800 "Hayden Katzenellenbogen" wrote: > I have a couple hundred devices that are managed by a support team. > They have full access to these devices so I will not need > authorization. (In the future I might). > > If all that I need to do is manage passwords in a central location > using tac_plus. Is the config as simple as having a user for each > team member and an enable password. And a tac-key. > > The remote devices then only need authorization commands and the rest > can be blank. > > Next as far as simple security. > > * I will have the two tac_plus servers behind a firewall only allowing > port 49. > * I am running as a non-root user. > * The configs are not viewable by anyone by root/tacacs user. > * Passwords are des encrypted with a salt. > > For now I want to keep this as simple as possible. > > Thanks to everyone who responds. Yup, that's pretty much right, you understand it well. Just one thing about password hashes - you don't need to stick to DES (and shouldn't). tac_plus couldn't care less about your password hashes, it completely depends on what your local libc supports. On Linux, that's usually all common hashes. I have tac_plus servers happily working with a mixture of DES, md5 and SHA hashes. I tried running tac_plus as a non-root user. It doesn't work too well - the daemon does the wrong thing if the log files do not already exist. The daemon starts as root to open port 49 for listening, creates the log files (owned by root of course) then drops privs to the tacacs user. At which point the daemon can no longer write to it's own log files and comes to a screeching halt. Silently. That one is hard to debug. You gett he same thing with logrotate if you are not careful. Eventually I just got fed up and recompiled removing the "run as tacacs user" option. The simplest possible way to authorize everything is to create one group with a single directive "permit .*" and assign every user membership to that group. However, you might want to rethink who can run AAA commands. Letting anyone do that just undoes all the hard work you went through to get the goodness of tacacs :-) -- Alan McKinnnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From kissg at ssg.ki.iif.hu Fri Jan 27 05:24:32 2012 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 27 Jan 2012 06:24:32 +0100 (CET) Subject: [tac_plus] Questions about a simple setup. In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> Message-ID: > * I will have the two tac_plus servers behind a firewall only allowing > port 49. > * I am running as a non-root user. Stop the press. Ports numbers under 1024 (aka well known ports) can be opened by root only. Regards Gabor > * The configs are not viewable by anyone by root/tacacs user. > * Passwords are des encrypted with a salt. From alan.mckinnon at gmail.com Fri Jan 27 13:42:35 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 27 Jan 2012 15:42:35 +0200 Subject: [tac_plus] Questions about a simple setup. In-Reply-To: References: <88BC6885D33A9D42A1CCB45E8749525E024B9232@pigeon.sandiego.nextlevelinternet.com> Message-ID: <20120127154235.202e836b@khamul.example.con> On Fri, 27 Jan 2012 06:24:32 +0100 (CET) "Kiss Gabor (Bitman)" wrote: > > * I will have the two tac_plus servers behind a firewall only > > allowing port 49. > > * I am running as a non-root user. > > Stop the press. > Ports numbers under 1024 (aka well known ports) can be opened by root > only. tac_plus starts as root and drops privs later the same way apache does configure the build system like so to do it: ./configure --with-userid=UID --with-groupid=GID -- Alan McKinnnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Tue Jan 31 15:43:14 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 31 Jan 2012 08:43:14 -0700 Subject: [tac_plus] Cisco WLC Message-ID: <5e2e7871271596c0497f9ffb346d204c@mail.gmail.com> I give up, the Cisco WLC just doesn?t seem to like authorization replacing the pairs. Wouldn?t be the only platform that has difficulty. # egrep 6079 tac_log.txt Mon Jan 30 16:54:48 2012 [6079]: connect from 192.168.0.1 [192.168.0.1] Mon Jan 30 16:54:48 2012 [6079]: Waiting for packet Mon Jan 30 16:54:48 2012 [6079]: cfg_get_hvalue: name=192.168.0.1 attr=key Mon Jan 30 16:54:48 2012 [6079]: cfg_get_hvalue: no host named 192.168.0.1 Mon Jan 30 16:54:48 2012 [6079]: cfg_get_phvalue: returns NULL Mon Jan 30 16:54:48 2012 [6079]: Read AUTHOR size=71 Mon Jan 30 16:54:48 2012 [6079]: validation request from 192.168.0.1 Mon Jan 30 16:54:48 2012 [6079]: PACKET: key=my_key Mon Jan 30 16:54:48 2012 [6079]: version 192 (0xc0), type 2, seq no 1, flags 0x1 Mon Jan 30 16:54:48 2012 [6079]: session_id 2378080596 (0x8dbea154), Data length 59 (0x3b) Mon Jan 30 16:54:48 2012 [6079]: End header Mon Jan 30 16:54:49 2012 [6079]: type=AUTHOR, priv_lvl=1, authen=1 Mon Jan 30 16:54:49 2012 [6079]: method=tacacs+ Mon Jan 30 16:54:49 2012 [6079]: svc=1 user_len=4 port_len=0 rem_addr_len=14 Mon Jan 30 16:54:49 2012 [6079]: arg_cnt=2 Mon Jan 30 16:54:49 2012 [6079]: User: Mon Jan 30 16:54:49 2012 [6079]: stupid_user Mon Jan 30 16:54:49 2012 [6079]: port: Mon Jan 30 16:54:49 2012 [6079]: rem_addr: Mon Jan 30 16:54:49 2012 [6079]: 10.0.0.1 Mon Jan 30 16:54:49 2012 [6079]: arg[0]: size=16 Mon Jan 30 16:54:49 2012 [6079]: service=ciscowlc Mon Jan 30 16:54:49 2012 [6079]: arg[1]: size=15 Mon Jan 30 16:54:49 2012 [6079]: protocol=common Mon Jan 30 16:54:49 2012 [6079]: End packet Mon Jan 30 16:54:49 2012 [6079]: Start authorization request Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: name=stupid_user isuser=1 attr=acl rec=1 Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: recurse group = do_auth_access Mon Jan 30 16:54:49 2012 [6079]: cfg_get_pvalue: returns NULL Mon Jan 30 16:54:49 2012 [6079]: do_author: user='stupid_user' Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: name=stupid_user isuser=1 attr=before rec=1 Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: recurse group = do_auth_access Mon Jan 30 16:54:49 2012 [6079]: cfg_get_pvalue: returns NULL Mon Jan 30 16:54:49 2012 [6079]: user 'stupid_user' found Mon Jan 30 16:54:49 2012 [6079]: cfg_get_svc_node: username=stupid_user N_svc proto= svcname=ciscowlc rec=1 Mon Jan 30 16:54:49 2012 [6079]: cfg_get_svc_node: found N_svc proto= svcname=ciscowlc Mon Jan 30 16:54:49 2012 [6079]: nas:service=ciscowlc (passed thru) Mon Jan 30 16:54:49 2012 [6079]: nas:protocol=common (passed thru) Mon Jan 30 16:54:49 2012 [6079]: nas:absent, server:role1=ALL -> add role1=ALL (k) Mon Jan 30 16:54:49 2012 [6079]: added 1 args Mon Jan 30 16:54:49 2012 [6079]: out_args[0] = service=ciscowlc input copy discarded Mon Jan 30 16:54:49 2012 [6079]: out_args[1] = protocol=common input copy discarded Mon Jan 30 16:54:49 2012 [6079]: out_args[2] = role1=ALL compacted to out_args[0] Mon Jan 30 16:54:49 2012 [6079]: 1 output args Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: name=stupid_user isuser=1 attr=after rec=1 Mon Jan 30 16:54:49 2012 [6079]: cfg_get_value: recurse group = do_auth_access Mon Jan 30 16:54:49 2012 [6079]: cfg_get_pvalue: returns /usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini Mon Jan 30 16:54:49 2012 [6079]: After authorization call: /usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini Mon Jan 30 16:54:49 2012 [6079]: substitute: /usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini Mon Jan 30 16:54:49 2012 [6079]: Dollar substitution: /usr/bin/python /root/do_auth.pyo -i 10.0.0.1 -fix_crs_bug -u stupid_user -d 192.168.0.1 -l /root/log.txt -f /root/do_auth.ini Mon Jan 30 16:54:49 2012 [6079]: input service=ciscowlc Mon Jan 30 16:54:49 2012 [6079]: input protocol=common Mon Jan 30 16:54:49 2012 [6079]: input role1=ALL Mon Jan 30 16:54:49 2012 [6079]: output role1=MONITOR Mon Jan 30 16:54:49 2012 [6079]: pid 6080 child exited status 6080l Mon Jan 30 16:54:49 2012 [6079]: cmd /usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/do_auth.ini returns 2 (replace & continue) Mon Jan 30 16:54:49 2012 [6079]: status is now AUTHOR_STATUS_PASS_REPL Mon Jan 30 16:54:49 2012 [6079]: Writing AUTHOR/PASS_REPL size=32 Mon Jan 30 16:54:49 2012 [6079]: PACKET: key=my_key Mon Jan 30 16:54:49 2012 [6079]: version 192 (0xc0), type 2, seq no 2, flags 0x1 Mon Jan 30 16:54:49 2012 [6079]: session_id 2378080596 (0x8dbea154), Data length 20 (0x14) Mon Jan 30 16:54:49 2012 [6079]: End header Mon Jan 30 16:54:49 2012 [6079]: type=AUTHOR/REPLY status=2 (AUTHOR/PASS_REPL) Mon Jan 30 16:54:49 2012 [6079]: msg_len=0, data_len=0 arg_cnt=1 Mon Jan 30 16:54:49 2012 [6079]: msg: Mon Jan 30 16:54:49 2012 [6079]: data: Mon Jan 30 16:54:49 2012 [6079]: arg[0] size=13 Mon Jan 30 16:54:49 2012 [6079]: role1=MONITOR Mon Jan 30 16:54:49 2012 [6079]: End packet Mon Jan 30 16:54:49 2012 [6079]: cfg_get_hvalue: name=192.168.0.1 attr=key Mon Jan 30 16:54:49 2012 [6079]: cfg_get_hvalue: no host named 192.168.0.1 Mon Jan 30 16:54:49 2012 [6079]: cfg_get_phvalue: returns NULL Mon Jan 30 16:54:49 2012 [6079]: authorization query for 'stupid_user' unknown from 192.168.0.1 accepted Mon Jan 30 16:54:49 2012 [6079]: 192.168.0.1: disconnect 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: