From kissg at ssg.ki.iif.hu Thu Aug 9 15:13:07 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Thu, 9 Aug 2007 17:13:07 +0200 (CEST) Subject: [tac_plus] tac_plus enhancement Message-ID: Dear Colleagues, I've just installed your tac_plus version F4.0.4.14. I wonder if you plan to release a newer one in the near future. I think it would be useful if a user or group could be member of multiple groups. Probably I can modify the code within a few hours. Are you interested in such a patch? Regards Gabor Kiss (file ./CHANGES, line 230 ;-) From heas at shrubbery.net Fri Aug 10 17:54:57 2007 From: heas at shrubbery.net (john heasley) Date: Fri, 10 Aug 2007 17:54:57 +0000 Subject: [tac_plus] Re: tac_plus enhancement In-Reply-To: References: Message-ID: <20070810175457.GF21815@shrubbery.net> Thu, Aug 09, 2007 at 05:13:07PM +0200, Kiss Gabor (Bitman): > Dear Colleagues, > > I've just installed your tac_plus version F4.0.4.14. > I wonder if you plan to release a newer one in the near future. > > I think it would be useful if a user or group could be member > of multiple groups. Probably I can modify the code within a few hours. > Are you interested in such a patch? How do you propose conflicts of attributes between groups be resolved? From kissg at ssg.ki.iif.hu Mon Aug 13 06:59:00 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Mon, 13 Aug 2007 08:59:00 +0200 (CEST) Subject: [tac_plus] Re: tac_plus enhancement In-Reply-To: <20070810175457.GF21815@shrubbery.net> References: <20070810175457.GF21815@shrubbery.net> Message-ID: > > I think it would be useful if a user or group could be member > > of multiple groups. > How do you propose conflicts of attributes between groups be resolved? This problem is like in object oriented languages: if more than one parent class provides the same method which one is to be executed? I made an arbitrary decision. I like PERL so I follow the PERL model: I do a recursive, depth-first, left-to-right search till I found the requested attribute. However the primary goal of this enhancement is to allow fine grained but simple configuration. In the tipical case there are no conflicting attributes. Properties should be organized into orthogonal groups, i.e. NAS location and allowed commands: acl = core_routers { permit = ... } acl = local_switches { permit = ... } group = red { acl = core_routers } group = green { acl = local_switches } group = show_ip { cmd = show { permit ^ip } } group = telnet_private { cmd = telnet { permit ^192\.168\. } } user = chico { member green member telnet_private } user = harpo { member green member show_ip } user zeppo { member red member telnet_private } Gabor From heas at shrubbery.net Tue Aug 14 00:09:03 2007 From: heas at shrubbery.net (john heasley) Date: Tue, 14 Aug 2007 00:09:03 +0000 Subject: [tac_plus] Re: tac_plus enhancement In-Reply-To: References: <20070810175457.GF21815@shrubbery.net> Message-ID: <20070814000903.GG10333@shrubbery.net> Mon, Aug 13, 2007 at 08:59:00AM +0200, Kiss Gabor (Bitman): > > > I think it would be useful if a user or group could be member > > > of multiple groups. > > > How do you propose conflicts of attributes between groups be resolved? > > This problem is like in object oriented languages: if more than > one parent class provides the same method which one is to be executed? > I made an arbitrary decision. I like PERL so I follow the PERL model: > I do a recursive, depth-first, left-to-right search till I found > the requested attribute. > However the primary goal of this enhancement is to allow fine grained > but simple configuration. > In the tipical case there are no conflicting attributes. > Properties should be organized into orthogonal groups, i.e. NAS location > and allowed commands: > > acl = core_routers { > permit = ... > } > > acl = local_switches { > permit = ... > } > > group = red { > acl = core_routers > } > > group = green { > acl = local_switches > } > > group = show_ip { > cmd = show { > permit ^ip > } > } > group = telnet_private { > cmd = telnet { > permit ^192\.168\. > } > } Any of these are good examples of what I mean. Take user chico. if chico: a) hits the implicit deny of local_switches, does it deny or go on to telnet_private? b) if local_switches would explicitly accept/deny it, should it check telnet_private. > user = chico { > member green > member telnet_private > } > > user = harpo { > member green > member show_ip > } > > user zeppo { > member red > member telnet_private > } > > Gabor From kissg at ssg.ki.iif.hu Tue Aug 14 07:01:32 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 14 Aug 2007 09:01:32 +0200 (CEST) Subject: [tac_plus] Re: tac_plus enhancement In-Reply-To: <20070814000903.GG10333@shrubbery.net> References: <20070810175457.GF21815@shrubbery.net> <20070814000903.GG10333@shrubbery.net> Message-ID: > > acl = local_switches { > > permit = ... > > } > > group = green { > > acl = local_switches > > } > > group = telnet_private { > > cmd = telnet { > > permit ^192\.168\. > > } > > } > > user = chico { > > member green > > member telnet_private > > } > Any of these are good examples of what I mean. Take user chico. if chico: > a) hits the implicit deny of local_switches, does it deny or go on to > telnet_private? In the current version I don't want to change the semantics of existing configuration items. So implicit deny also terminates searching. However I plan to introduce a new keyword along "permit" and "deny" (e.g. "continue" or "return" or "dunno") that stops traversing of current subtree (i.e. no further parent groups of current one will be examined). > b) if local_switches would explicitly accept/deny it, should it check > telnet_private. No. Explicit hit terminates searching immediately. This behavior is compatible with current version of tac_plus. Gabor From kissg at ssg.ki.iif.hu Wed Aug 15 10:15:33 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 15 Aug 2007 12:15:33 +0200 (CEST) Subject: [tac_plus] Re: tac_plus enhancement In-Reply-To: References: Message-ID: > I've just installed your tac_plus version F4.0.4.14. > I wonder if you plan to release a newer one in the near future. > > I think it would be useful if a user or group could be member > of multiple groups. The patch can be found at http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/ http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/tacacs+-F4.0.4.14-k1.diff README: tacacs+-F4.0.4.14-k1.diff A patch to tacacs+-F4.0.4.14 that allows multiple group membership. Attribute search is done in depth-first manner. The program is upward compatible with tacacs+-F4.0.4.14, old config files can be used without any change. Any feedback is welcome. Gabor From kissg at ssg.ki.iif.hu Fri Aug 17 13:36:51 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 17 Aug 2007 15:36:51 +0200 (CEST) Subject: [tac_plus] Multiple groups, multiple ACL-s Message-ID: Dear folks, At http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/ you can find a patch against tacacs+-F4.0.4.14. Now multiple membership is allowed as well as a kind of hierarchical ACL-s. Let's assume you have a large scale network at several locations and a lot of users. If you want to allow certain users to enter into a certain NAS-es only you can use the following schema: ########## elementary ACLs and location groups ############ acl = city1 { permit = ^192\.168\.1\. permit = ^192\.168\.23\. return = .* } group = location_city1 { acl = city1 } acl = city2 { permit = ^192\.168\.17\. return = .* } group = location_city2 { acl = city2 } acl = city3 { permit = ^10\.61\. return = .* } group = location_city3 { acl = city3 } acl = city4 { permit = ^172\.16\.28\. return = .* } group = location_city4 { acl = city4 } ############# composite location groups ##################### group = location_all { member = location_city1 member = location_city2 member = location_city3 member = location_city4 } group location_northern_region { member = location_city1 member = location_city2 } group location_western_region { member = location_city3 } group location_eastern_region { member = location_city4 } group location_northeastern_region { member = location_northern_region member = location_eastern_region } ################### users ####################### user = groucho { member = location_all ... } user = harpo { member = location_eastern_region ... } user = zeppo { member = location_northeastern_region ... } ... Any feedback is welcome. G?bor From jathan at gmail.com Mon Aug 20 17:38:02 2007 From: jathan at gmail.com (jathan.) Date: Mon, 20 Aug 2007 10:38:02 -0700 Subject: [tac_plus] Deep command filtering Message-ID: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> Hello- With the announcement of the latest Cisco PSIRT for "'sh ip bgp regexp' crashing router". Briefly what happens is that the router will crash when you enter the command 'show ip bgp regexp'. For example: show ip bgp regexp (.*)(_\1)+ I have been a user of tac_plus for a long time, but this is the first time I have been asked to filter deep into a command tree. I am aware of something like cmd = show { deny ip permit .* } I have never had any success going any deeper such as: cmd = show { deny ip bgp regexp } Is this even possible? Any help or feedback would be appreciated. It's looking like in the interim my only remedy is to block access to 'show ip' period, and that's quite a nuisance. Thanks, Jathan McCollum From heas at shrubbery.net Mon Aug 20 19:04:06 2007 From: heas at shrubbery.net (john heasley) Date: Mon, 20 Aug 2007 19:04:06 +0000 Subject: [tac_plus] Re: Deep command filtering In-Reply-To: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> References: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> Message-ID: <20070820190406.GL8360@shrubbery.net> Mon, Aug 20, 2007 at 10:38:02AM -0700, jathan.: > Hello- > > With the announcement of the latest Cisco PSIRT for "'sh ip bgp > regexp' crashing router". Briefly what happens is that the router > will crash when you enter the command 'show ip bgp regexp'. > > For example: > > show ip bgp regexp (.*)(_\1)+ > > I have been a user of tac_plus for a long time, but this is the first > time I have been asked to filter deep into a command tree. > > I am aware of something like > > cmd = show { > deny ip > permit .* > } > > I have never had any success going any deeper such as: > > cmd = show { > deny ip bgp regexp > } > > Is this even possible? Any help or feedback would be appreciated. > It's looking like in the interim my only remedy is to block access to > 'show ip' period, and that's quite a nuisance. Yes, this will work just fine, but I believe it is a bigger hammer than necessary. My suspicion is that deny ip bgp regexp.*\\ is sufficient. It is likely the [non-sensical & unnecessary in the sense of AS-paths] reference operator (\N) that is to blame. From heas at shrubbery.net Mon Aug 20 21:49:55 2007 From: heas at shrubbery.net (john heasley) Date: Mon, 20 Aug 2007 21:49:55 +0000 Subject: [tac_plus] Re: Deep command filtering In-Reply-To: <4e0e47490708201338j4c5d5f3lbcdb5c81d060bf7a@mail.gmail.com> References: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> <20070820190406.GL8360@shrubbery.net> <4e0e47490708201338j4c5d5f3lbcdb5c81d060bf7a@mail.gmail.com> Message-ID: <20070820214955.GR8360@shrubbery.net> Mon, Aug 20, 2007 at 01:38:08PM -0700, jathan.: > Hmm- > > Are you absolutely sure? I am running 4.0.4.13 and when I attempt to > restart the daemon I see: > > Aug 20 15:21:40 tac-ntc tac_plus[6709]: Reading config > Aug 20 15:21:40 tac-ntc tac_plus[6709]: Error expecting '}' but found > 'bgp' on line 61 > Aug 20 15:21:40 tac-ntc tac_plus: Error: expecting '}' but found 'bgp' > on line 61 > Aug 20 15:21:40 tac-ntc tacacs: tac_plus startup failed > > Using your example line 61 is: > > 60 cmd = show { > 61 deny ip bgp regexp.*\\ > 62 permit .* > 63 } > > No dice. Any suggestions? well, thats a bug of some sort. looks like I actually used the following locally: deny regex.*\\[0-9] From jathan at gmail.com Mon Aug 20 20:38:08 2007 From: jathan at gmail.com (jathan.) Date: Mon, 20 Aug 2007 13:38:08 -0700 Subject: [tac_plus] Re: Deep command filtering In-Reply-To: <20070820190406.GL8360@shrubbery.net> References: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> <20070820190406.GL8360@shrubbery.net> Message-ID: <4e0e47490708201338j4c5d5f3lbcdb5c81d060bf7a@mail.gmail.com> Hmm- Are you absolutely sure? I am running 4.0.4.13 and when I attempt to restart the daemon I see: Aug 20 15:21:40 tac-ntc tac_plus[6709]: Reading config Aug 20 15:21:40 tac-ntc tac_plus[6709]: Error expecting '}' but found 'bgp' on line 61 Aug 20 15:21:40 tac-ntc tac_plus: Error: expecting '}' but found 'bgp' on line 61 Aug 20 15:21:40 tac-ntc tacacs: tac_plus startup failed Using your example line 61 is: 60 cmd = show { 61 deny ip bgp regexp.*\\ 62 permit .* 63 } No dice. Any suggestions? # tac_plus -v tac_plus version F4.0.4.13 ACLS FIONBIO LIBWRAP LINUX LITTLE_ENDIAN LOG_DAEMON PAM NO_PWAGE REAPCHILD REARMSIGNAL RETSIGTYPE RETSIGTYPE SHADOW_PASSWORDS SIGTSTP SIGTTIN SIGTTOU SO_REUSEADDR STRERROR TAC_PLUS_PORT UENABLE __STDC__ On 8/20/07, john heasley wrote: > Mon, Aug 20, 2007 at 10:38:02AM -0700, jathan.: > > Hello- > > > > With the announcement of the latest Cisco PSIRT for "'sh ip bgp > > regexp' crashing router". Briefly what happens is that the router > > will crash when you enter the command 'show ip bgp regexp'. > > > > For example: > > > > show ip bgp regexp (.*)(_\1)+ > > > > I have been a user of tac_plus for a long time, but this is the first > > time I have been asked to filter deep into a command tree. > > > > I am aware of something like > > > > cmd = show { > > deny ip > > permit .* > > } > > > > I have never had any success going any deeper such as: > > > > cmd = show { > > deny ip bgp regexp > > } > > > > Is this even possible? Any help or feedback would be appreciated. > > It's looking like in the interim my only remedy is to block access to > > 'show ip' period, and that's quite a nuisance. > > Yes, this will work just fine, but I believe it is a bigger hammer than > necessary. My suspicion is that > > deny ip bgp regexp.*\\ > > is sufficient. It is likely the [non-sensical & unnecessary in the sense > of AS-paths] reference operator (\N) that is to blame. > -- jathan. 00bliss.dj.switchstance www.00bliss.com -- From kissg at ssg.ki.iif.hu Tue Aug 21 11:14:43 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 21 Aug 2007 13:14:43 +0200 (CEST) Subject: [tac_plus] Re: Deep command filtering In-Reply-To: <20070820214955.GR8360@shrubbery.net> References: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> <20070820190406.GL8360@shrubbery.net> <4e0e47490708201338j4c5d5f3lbcdb5c81d060bf7a@mail.gmail.com> <20070820214955.GR8360@shrubbery.net> Message-ID: > 60 cmd = show { > 61 deny ip bgp regexp.*\\ > 62 permit .* > 63 } > > No dice. Any suggestions? deny "ip bgp regexp" Gabor From kissg at ssg.ki.iif.hu Tue Aug 21 13:25:37 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 21 Aug 2007 15:25:37 +0200 (CEST) Subject: [tac_plus] Included config files Message-ID: Dear folks, At http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/ you can find a patch against tacacs+-F4.0.4.14. A new 'include' keyword is added. Now you can split your laaaarge config file in reasonable size chunks or you can maintain different parts of your config separately. If you write include = /absolute/path/file the content of mentioned file will be processed at this point. (Using relative paths can produce unpredictable result. Yet.) Files can be nested in arbitrary depth. Gabor From jathan at gmail.com Tue Aug 21 14:10:50 2007 From: jathan at gmail.com (jathan.) Date: Tue, 21 Aug 2007 07:10:50 -0700 Subject: [tac_plus] Re: Deep command filtering In-Reply-To: References: <4e0e47490708201038q35360494wbcdc0c8fd07dba16@mail.gmail.com> <20070820190406.GL8360@shrubbery.net> <4e0e47490708201338j4c5d5f3lbcdb5c81d060bf7a@mail.gmail.com> <20070820214955.GR8360@shrubbery.net> Message-ID: <4e0e47490708210710k69c7fbcv809c33df8d572935@mail.gmail.com> That did it! Thank you. I'm not sure why it never occurred to me to use quotations before. On 8/21/07, Kiss Gabor (Bitman) wrote: > > 60 cmd = show { > > 61 deny ip bgp regexp.*\\ > > 62 permit .* > > 63 } > > > > No dice. Any suggestions? > > deny "ip bgp regexp" > > Gabor > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -- jathan. 00bliss.dj.switchstance www.00bliss.com -- From bkennedy at peer1.com Tue Aug 21 16:53:15 2007 From: bkennedy at peer1.com (Ben Kennedy) Date: Tue, 21 Aug 2007 09:53:15 -0700 Subject: [tac_plus] After authorization scripting Message-ID: <46CB187B.7000006@peer1.com> Hello, I have been looking into a more dynamic way of doing command authorization. I wanted to find a way to intelligently filter commands based on the device that a person was logging into (ie a switch allows for different commands than a router). From what I can tell the best way to go is to use the "after authorization" command in the conf file. Then in the script I can dymaically create a list of devices. However In all the forums/documentation and I have went through no one seems to have given example of the format for any of this. They merely describe it and show the conf file command. I have played around with the format but haven't had any success to date, it is mainly trial and error. Any help would be greatly appreciated. Example of switch config: aaa new-model aaa authentication login default local group tacacs+ enable aaa authorization exec default local group tacacs+ if-authenticated aaa authorization commands 15 default local group tacacs+ Here is an example of the config file: user = test { after authorization "/etc/tac-plus/authen $user $address" } Example of script: #!/bin/sh if [ "$1" = 'test' ] then if [ "$2" = 'X.X.X.X' ] #ip of switch then echo default service=permit echo login=cleartext XXX echo service=exec echo { echo priv-lvl=15 echo echo cmd=arp echo { echo permit timeout echo } echo cmd=no echo { echo permit arp echo } echo cmd=show echo { echo permit run echo permit start echo } echo cmd=configure echo { echo permit terminal echo permit interface echo deny .* echo } exit 2 fi fi exit 1 -- Ben Kennedy Network Engineer PEER 1 1000-555 West Hastings Street Vancouver, BC, Canada V6B 4N5 24/7 Support: 1.866.484.2588 T: 604.484.2588 F: 604.683.4634 bkennedy at peer1.net www.peer1.com NETWORK | CO-LOCATION | DEDICATED HOSTING From kissg at ssg.ki.iif.hu Wed Aug 22 06:40:22 2007 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 22 Aug 2007 08:40:22 +0200 (CEST) Subject: [tac_plus] Re: After authorization scripting In-Reply-To: <46CB187B.7000006@peer1.com> References: <46CB187B.7000006@peer1.com> Message-ID: > it and show the conf file command. I have played around with the format > but haven't had any success to date, it is mainly trial and error. Any > help would be greatly appreciated. > Example of script: > #!/bin/sh > > if [ "$1" = 'test' ] > then > if [ "$2" = 'X.X.X.X' ] #ip of switch > then > echo default service=permit > echo login=cleartext XXX > echo service=exec > echo { > echo priv-lvl=15 > echo > echo cmd=arp > echo { > echo permit timeout > echo } > echo cmd=no > echo { > echo permit arp > echo } > echo cmd=show > echo { > echo permit run > echo permit start > echo } > echo cmd=configure > echo { > echo permit terminal > echo permit interface > echo deny .* > echo } > exit 2 > fi > fi > exit 1 Users_guide writes: The program is expected to process the AV pairs and write them to its standard output, one per line. What happens then is determined by the exit status of the program: ... If the program returns a status of 2, authorization is permitted and any AV pairs returned from the program on its standard output are sent to the NAS in place of any AV pairs that the daemon may have constructed. Gabor From heas at shrubbery.net Thu Aug 23 16:26:48 2007 From: heas at shrubbery.net (john heasley) Date: Thu, 23 Aug 2007 16:26:48 +0000 Subject: [tac_plus] Re: Included config files In-Reply-To: References: Message-ID: <20070823162648.GE14783@shrubbery.net> Tue, Aug 21, 2007 at 03:25:37PM +0200, Kiss Gabor (Bitman): > Dear folks, > > At http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/ > you can find a patch against tacacs+-F4.0.4.14. > > A new 'include' keyword is added. Now you can split > your laaaarge config file in reasonable size chunks > or you can maintain different parts of your config separately. > If you write > > include = /absolute/path/file > > the content of mentioned file will be processed at this point. > (Using relative paths can produce unpredictable result. Yet.) > Files can be nested in arbitrary depth. I really like this idea. Sorry, I have not had time to look at it yet, nor your other patch. patience From sergey.babichev at sitek.net Tue Aug 28 09:56:36 2007 From: sergey.babichev at sitek.net (Sergey Babichev) Date: Tue, 28 Aug 2007 13:56:36 +0400 Subject: [tac_plus] Trouble with password Message-ID: <056601c7e959$ba3a69e0$7a010f0a@sitek.net> Hi! I have a problem with tacacs. My user can connect to cisco devices with two passwords: vtnhjkju1@ vtnhjkju97@ I generate his password (vtnhjkju1@) with tac_pwd and write it in cisco.pwd file: cat--- pavelsm:VFoUc2TB5Tjf2::::: cat--- I can change this password and all be ok but I wish to understand as it probably? Best regards, Sergey Babichev Sitek Global Network, Moscow http://www.sitek.net phone: + 7 495 2312000 fax: + 7 495 2312003 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070828/38bc76a4/attachment.html From heas at shrubbery.net Tue Aug 28 18:02:04 2007 From: heas at shrubbery.net (john heasley) Date: Tue, 28 Aug 2007 18:02:04 +0000 Subject: [tac_plus] Re: Trouble with password In-Reply-To: <056601c7e959$ba3a69e0$7a010f0a@sitek.net> References: <056601c7e959$ba3a69e0$7a010f0a@sitek.net> Message-ID: <20070828180204.GE11955@shrubbery.net> Tue, Aug 28, 2007 at 01:56:36PM +0400, Sergey Babichev: > Hi! > > I have a problem with tacacs. My user can connect to cisco devices with two passwords: > > vtnhjkju1@ > vtnhjkju97@ I think you'll find that crypt(3) on your system is limited to 8 characters. > I generate his password (vtnhjkju1@) with tac_pwd and write it in cisco.pwd file: > > cat--- > pavelsm:VFoUc2TB5Tjf2::::: > cat--- > > I can change this password and all be ok but I wish to understand as it probably? > > Best regards, > Sergey Babichev > Sitek Global Network, Moscow > http://www.sitek.net > phone: + 7 495 2312000 > fax: + 7 495 2312003 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070828/38bc76a4/attachment.html > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From sfischer1967 at gmail.com Tue Aug 28 20:24:13 2007 From: sfischer1967 at gmail.com (Steven Fischer) Date: Tue, 28 Aug 2007 16:24:13 -0400 Subject: [tac_plus] Error when starting tac_plus with acl in tac_plus.cfg Message-ID: <500ffb690708281324q28263ebfj81e4ac7b5de33170@mail.gmail.com> Getting an error when trying to use an acl in the tac_plus.cfg file. Note the acl below is at the top of the file. Am I doing something wrong? acl = userlan { permit = 172.16.254.[10-60] deny = 192.168.*.* deny = 172.16.254.[1-9] deny = 10.*.*.* } [root at hqitnwm02 init.d]# ./tac_plus start Starting TACACS+ :Error: Unrecognised token acl on line 5 [FAILED] [root at hqitnwm02 tacacs]# tac_plus -v tac_plus version F4.0.4.14 ACLS FIONBIO LIBWRAP LINUX LITTLE_ENDIAN LOG_DAEMON PAM NO_PWAGE REAPCHILD REARMSIGNAL RETSIGTYPE RETSIGTYPE SHADOW_PASSWORDS SIGTSTP SIGTTIN SIGTTOU SO_REUSEADDR STRERROR TAC_PLUS_PORT UENABLE __STDC__ Any help anyone can provide is sincerely appreciated. Steve -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070828/25984019/attachment.html From heas at shrubbery.net Tue Aug 28 21:24:02 2007 From: heas at shrubbery.net (john heasley) Date: Tue, 28 Aug 2007 21:24:02 +0000 Subject: [tac_plus] Re: Error when starting tac_plus with acl in tac_plus.cfg In-Reply-To: <500ffb690708281324q28263ebfj81e4ac7b5de33170@mail.gmail.com> References: <500ffb690708281324q28263ebfj81e4ac7b5de33170@mail.gmail.com> Message-ID: <20070828212402.GE6727@shrubbery.net> Tue, Aug 28, 2007 at 04:24:13PM -0400, Steven Fischer: > Getting an error when trying to use an acl in the tac_plus.cfg file. Note > the acl below is at the top of the file. Am I doing something wrong? > > acl = userlan { > > permit = 172.16.254.[10-60] > > deny = 192.168.*.* > > deny = 172.16.254.[1-9] > > deny = 10.*.*.* > > } > > > > [root at hqitnwm02 init.d]# ./tac_plus start > > Starting TACACS+ :Error: Unrecognised token acl on line 5 > > [FAILED] please look for syntax errors prior to line 5 > [root at hqitnwm02 tacacs]# tac_plus -v > > tac_plus version F4.0.4.14 > > ACLS > > FIONBIO > > LIBWRAP > > LINUX > > LITTLE_ENDIAN > > LOG_DAEMON > > PAM > > NO_PWAGE > > REAPCHILD > > REARMSIGNAL > > RETSIGTYPE RETSIGTYPE > > SHADOW_PASSWORDS > > SIGTSTP > > SIGTTIN > > SIGTTOU > > SO_REUSEADDR > > STRERROR > > TAC_PLUS_PORT > > UENABLE > > __STDC__ > > > Any help anyone can provide is sincerely appreciated. > > Steve > > -- > To him who is able to keep you from falling and to present you before his > glorious presence without fault and with great joy > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070828/25984019/attachment.html > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Thu Aug 30 20:35:02 2007 From: dan.schmidt at uplinkdata.com (Dan Schmidt) Date: Thu, 30 Aug 2007 14:35:02 -0600 Subject: [tac_plus] Password Bug Message-ID: <390DD3915314C044A2B6D54FF84E872B29EA67@che-exch-001.uplinkdata.com> Thank you for your excellent work on tac_plus. If I encrypt the word "password1" I can use just about any variation of password* and get in. password, password1,password2, password45... they all will log me in. That is a big security hole. Thank you for your time, -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070830/137c0caa/attachment.html