From daniel.schmidt at wyo.gov Fri Feb 10 18:37:46 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Fri, 10 Feb 2012 11:37:46 -0700 Subject: [tac_plus] Two factor authentication Message-ID: Looking at two factor authentication with WiKiD. They have tac_plus support, but I?m trying to convince them to keep their passwords in a separate file instead of writing over the tac_plus.conf each time. I?d write a patch, but I?m no good at Java and I need to cleanup do_auth. Getting to the point: Anybody besides me have any interest in this? 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 joe.moore at holidaycompanies.com Mon Feb 20 17:07:30 2012 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Mon, 20 Feb 2012 17:07:30 +0000 Subject: [tac_plus] auth fail lock fix or alternatives? Message-ID: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> I know some of you consider the account lockout feature to be a denial of service vector, but our security auditor insists that we lock out accounts after (no more than) 5 failed login attempts, and there is no chance of that changing. So I have to do it. I was happily running tac_plus F4.0.4.19 with the tacacs+-F4.0.4.19.afl.patch on a pair of FreeBSD 7.4 servers for some time. As soon as I updated one of the servers to FreeBSD 8.x, tac_plus would no longer start. Startup failed with the message: Error: Unrecognised token auth-fail-lock on line 6. The only way I was able to get tac_plus to start was by commenting out that line. I've tried installing F4.0.4.19 with the patch on fresh installs of FreeBSD 8.2 and Centos 6.2 with the same results. I've had no luck contacting the author of the patch so I'm assuming there won't be updates available for newer versions of tac_plus. Not updating tac_plus is also something the auditor will eventually notice. Are there any alternatives to the afl patch? Something that delays the login prompt ever increasing amounts after each failed attempt might work too. I really don't want to tell my boss that Cisco AC$ is our only option... L ...jgm -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Mon Feb 20 21:52:43 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Mon, 20 Feb 2012 23:52:43 +0200 Subject: [tac_plus] auth fail lock fix or alternatives? In-Reply-To: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> Message-ID: <20120220235243.447de1db@khamul.example.com> On Mon, 20 Feb 2012 17:07:30 +0000 Joe Moore wrote: > I know some of you consider the account lockout feature to be a > denial of service vector, but our security auditor insists that we > lock out accounts after (no more than) 5 failed login attempts, and > there is no chance of that changing. So I have to do it. > > I was happily running tac_plus F4.0.4.19 with the > tacacs+-F4.0.4.19.afl.patch on a pair of FreeBSD 7.4 servers for some > time. > > As soon as I updated one of the servers to FreeBSD 8.x, tac_plus > would no longer start. Startup failed with the message: Error: > Unrecognised token auth-fail-lock on line 6. This part doesn't make much sense to me. That's not a run-time or logic error, it means that the config file parser has no knowledge of that specific token. This should not happen as it is the same code with the same patch that worked fine on a previous version of the same OS. It's hard to think of something that would cause that, it's almost as if the #IFDEF AFL wasn't there or you missed the --enable-afl - I'm assuming that is not the case, it's a real n00b error :-) autotools likely got upgraded, what version are you running now and what were you using on FreeBSD-7.2? I also think the entire output of ./configure would be useful so we can all see how tac_plus decided to configure itself. > > The only way I was able to get tac_plus to start was by commenting > out that line. I've tried installing F4.0.4.19 with the patch on > fresh installs of FreeBSD 8.2 and Centos 6.2 with the same results. > I've had no luck contacting the author of the patch so I'm assuming > there won't be updates available for newer versions of tac_plus. Not > updating tac_plus is also something the auditor will eventually > notice. > > Are there any alternatives to the afl patch? Something that delays > the login prompt ever increasing amounts after each failed attempt > might work too. > > I really don't want to tell my boss that Cisco AC$ is our only > option... > > > L ...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 -- Alan McKinnnon alan.mckinnon at gmail.com From joe.moore at holidaycompanies.com Mon Feb 20 22:37:23 2012 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Mon, 20 Feb 2012 22:37:23 +0000 Subject: [tac_plus] auth fail lock fix or alternatives? In-Reply-To: <20120220235243.447de1db@khamul.example.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> <20120220235243.447de1db@khamul.example.com> Message-ID: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D96B@hcexch01.holidaycompanies.com> -----Original Message----- From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] Sent: Monday, February 20, 2012 3:53 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] auth fail lock fix or alternatives? On Mon, 20 Feb 2012 17:07:30 +0000 Joe Moore wrote: > I know some of you consider the account lockout feature to be a denial > of service vector, but our security auditor insists that we lock out > accounts after (no more than) 5 failed login attempts, and there is no > chance of that changing. So I have to do it. > > I was happily running tac_plus F4.0.4.19 with the > tacacs+-F4.0.4.19.afl.patch on a pair of FreeBSD 7.4 servers for some > time. > > As soon as I updated one of the servers to FreeBSD 8.x, tac_plus would > no longer start. Startup failed with the message: Error: > Unrecognised token auth-fail-lock on line 6. This part doesn't make much sense to me. That's not a run-time or logic error, it means that the config file parser has no knowledge of that specific token. This should not happen as it is the same code with the same patch that worked fine on a previous version of the same OS. It's hard to think of something that would cause that, it's almost as if the #IFDEF AFL wasn't there or you missed the --enable-afl - I'm assuming that is not the case, it's a real n00b error :-) autotools likely got upgraded, what version are you running now and what were you using on FreeBSD-7.2? I also think the entire output of ./configure would be useful so we can all see how tac_plus decided to configure itself. Alan, As a router & switch admin I am no noob but as a developer, I'm an end-user, which probably puts me below noob. The tac_plus service failed to start after a typical "buildworld" update and reboot of the FreeBSD box. At that point I had not re-compiled or re-installed tac_plus. I have subsequently patched, configured, compiled and installed tac_plus on multiple boxes with fresh FreeBSD 8.2 installs as well as a Centos 6 box. None of them would start tac_plus unless I commented out the " auth-fail-lock 4 120 900" line. Full output of the patch and configure on FreeBSD 8.2 follows. I be happy to give you the versions of the auto tools on the old FBSD 7.2 box if you tell me how to find that out. Thanks in advance! [root at ns3 ~/download]# cd tacacs+-F4.0.4.19 [root at ns3 ~/download/tacacs+-F4.0.4.19]# ls tac* tac_convert.in tac_plus.conf.5.in tac_pwd.c tac_plus.8.in tac_plus.h tacacs+-F4.0.4.19.afl.patch tac_plus.c tac_pwd.8 tacacs.h [root at ns3 ~/download/tacacs+-F4.0.4.19]# patch < tacacs+-F4.0.4.19.afl.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/authen.c ./authen.c |--- ../tacacs+-F4.0.4.19.orig/authen.c 2009-07-17 13:34:32.000000000 -0400 |+++ ./authen.c 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file authen.c using Plan A... Hunk #1 succeeded at 316. Hunk #2 succeeded at 356. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/config.c ./config.c |--- ../tacacs+-F4.0.4.19.orig/config.c 2009-07-17 13:34:30.000000000 -0400 |+++ ./config.c 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file config.c using Plan A... Hunk #1 succeeded at 114. Hunk #2 succeeded at 183. Hunk #3 succeeded at 221. Hunk #4 succeeded at 539. Hunk #5 succeeded at 772. Hunk #6 succeeded at 2475. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/config.h.in ./config.h.in |--- ../tacacs+-F4.0.4.19.orig/config.h.in 2009-07-17 16:02:18.000000000 -0400 |+++ ./config.h.in 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file config.h.in using Plan A... Hunk #1 succeeded at 288. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/configure.in ./configure.in |--- ../tacacs+-F4.0.4.19.orig/configure.in 2009-07-17 13:54:16.000000000 -0400 |+++ ./configure.in 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file configure.in using Plan A... Hunk #1 succeeded at 620. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/parse.c ./parse.c |--- ../tacacs+-F4.0.4.19.orig/parse.c 2009-07-17 13:34:32.000000000 -0400 |+++ ./parse.c 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file parse.c using Plan A... Hunk #1 succeeded at 118. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/parse.h ./parse.h |--- ../tacacs+-F4.0.4.19.orig/parse.h 2009-07-17 13:34:32.000000000 -0400 |+++ ./parse.h 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file parse.h using Plan A... Hunk #1 succeeded at 90. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/tac_plus.c ./tac_plus.c |--- ../tacacs+-F4.0.4.19.orig/tac_plus.c 2009-07-28 11:50:24.000000000 -0400 |+++ ./tac_plus.c 2009-09-10 15:17:32.000000000 -0400 -------------------------- Patching file tac_plus.c using Plan A... Hunk #1 succeeded at 79. Hunk #2 succeeded at 99. Hunk #3 succeeded at 112. Hunk #4 succeeded at 349. Hunk #5 succeeded at 927. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur ../tacacs+-F4.0.4.19.orig/tac_plus.h ./tac_plus.h |--- ../tacacs+-F4.0.4.19.orig/tac_plus.h 2009-07-27 20:11:53.000000000 -0400 |+++ ./tac_plus.h 2009-09-10 15:18:33.000000000 -0400 -------------------------- Patching file tac_plus.h using Plan A... Hunk #1 succeeded at 153. Hunk #2 succeeded at 278. Hunk #3 succeeded at 304. Hunk #4 succeeded at 623. Hmm... Ignoring the trailing garbage. done [root at ns3 ~/download/tacacs+-F4.0.4.19]# ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i386-unknown-freebsd8.2 checking host system type... i386-unknown-freebsd8.2 checking for gmake... /usr/local/bin/gmake checking whether /usr/local/bin/gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by /usr/local/bin/gmake... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... freebsd8.2 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd8.2 ld.so (cached) (cached) checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking for function prototypes... yes checking for string.h... (cached) yes checking how to run the C preprocessor... gcc -E checking for an ANSI C-conforming const... yes checking for inline... inline checking for preprocessor stringizing operator... yes checking for flex... flex checking lex output file root... lex.yy checking lex library... -lfl checking whether yytext is a pointer... yes checking for bison... bison -y checking whether yacc is bison in disguise... yes checking whether byte ordering is bigendian... no checking size of long int... 4 checking for a BSD-compatible install... /usr/bin/install -c checking whether to include symbols... no checking whether to set gcc warnings... no checking whether to use libwrap... yes checking whether to include skey support... no checking whether to setuid()... no checking whether to setgid()... no checking whether to include ACL support... yes checking whether to include user-enable support... yes checking whether to include maximum sessions (maxsess) support... no checking whether to include maxsess finger support... no checking for alt pid file FQPN... /var/run/tac_plus.pid checking for alt accounting file FQPN... /var/log/tac_plus.acct checking for alt log file FQPN... /var/log/tac_plus.log checking for alt wholog file FQPN... /var/log/tacwho.log checking whether to profile... no checking for pam_start in -lpam... yes checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking crypt.h usability... no checking crypt.h presence... no checking for crypt.h... no checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdlib.h... (cached) yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/types.h... (cached) yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking wait.h usability... no checking wait.h presence... no checking for wait.h... no checking return type of signal handlers... void checking for socklen_t... yes checking for pid_t... yes checking for getdtablesize... yes checking for memcpy... yes checking for memset... yes checking for strchr... yes checking for strcspn... yes checking for strerror... yes checking for strrchr... yes checking for wait3... yes checking for wait4... yes checking for waitpid... yes checking whether setpgrp takes no argument... no checking if waitpid takes a union wait... no checking if signals need to be re-armed... no checking if children need to be reaped... yes checking if children need to be reaped with SIG_IGN... no checking for gnutar... no checking for gtar... no checking for tar... tar checking for a BSD-compatible install... /usr/bin/install -c checking for perl5... /usr/bin/perl5 configure: creating ./config.status config.status: creating Makefile config.status: creating version.h config.status: creating pathsl.h config.status: creating tac_plus.8 config.status: creating tac_plus.conf.5 config.status: creating config.h config.status: executing depfiles commands [root at ns3 ~/download/tacacs+-F4.0.4.19]# From alan.mckinnon at gmail.com Mon Feb 20 23:37:41 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Tue, 21 Feb 2012 01:37:41 +0200 Subject: [tac_plus] auth fail lock fix or alternatives? In-Reply-To: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D96B@hcexch01.holidaycompanies.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> <20120220235243.447de1db@khamul.example.com> <7DC5CF25DDD70D4A845DDC2F96E116B2A0D96B@hcexch01.holidaycompanies.com> Message-ID: <20120221013741.60d7b134@khamul.example.com> On Mon, 20 Feb 2012 22:37:23 +0000 Joe Moore wrote: > > > -----Original Message----- > From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] > Sent: Monday, February 20, 2012 3:53 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] auth fail lock fix or alternatives? > > On Mon, 20 Feb 2012 17:07:30 +0000 > Joe Moore wrote: > > > I know some of you consider the account lockout feature to be a > > denial of service vector, but our security auditor insists that we > > lock out accounts after (no more than) 5 failed login attempts, and > > there is no chance of that changing. So I have to do it. > > > > I was happily running tac_plus F4.0.4.19 with the > > tacacs+-F4.0.4.19.afl.patch on a pair of FreeBSD 7.4 servers for > > some time. > > > > As soon as I updated one of the servers to FreeBSD 8.x, tac_plus > > would no longer start. Startup failed with the message: Error: > > Unrecognised token auth-fail-lock on line 6. > > This part doesn't make much sense to me. That's not a run-time or > logic error, it means that the config file parser has no knowledge of > that specific token. > > This should not happen as it is the same code with the same patch > that worked fine on a previous version of the same OS. It's hard to > think of something that would cause that, it's almost as if the > #IFDEF AFL wasn't there or you missed the --enable-afl - I'm assuming > that is not the case, it's a real n00b error :-) > > autotools likely got upgraded, what version are you running now and > what were you using on FreeBSD-7.2? > > I also think the entire output of ./configure would be useful so we > can all see how tac_plus decided to configure itself. > > > > Alan, > > As a router & switch admin I am no noob but as a developer, I'm an > end-user, which probably puts me below noob. > > The tac_plus service failed to start after a typical "buildworld" > update and reboot of the FreeBSD box. At that point I had not > re-compiled or re-installed tac_plus. I have subsequently patched, > configured, compiled and installed tac_plus on multiple boxes with > fresh FreeBSD 8.2 installs as well as a Centos 6 box. None of them > would start tac_plus unless I commented out the " auth-fail-lock 4 > 120 900" line. > > Full output of the patch and configure on FreeBSD 8.2 follows. I be > happy to give you the versions of the auto tools on the old FBSD 7.2 > box if you tell me how to find that out. > > Thanks in advance! Found it, see below: [snip] > Hunk #1 succeeded at 153. > Hunk #2 succeeded at 278. > Hunk #3 succeeded at 304. > Hunk #4 succeeded at 623. > Hmm... Ignoring the trailing garbage. > done You need to run "autoconf" here otherwise ./configure won't know about your changes to the sources. For me this makes the difference between it working and getting the same result you got > [root at ns3 ~/download/tacacs+-F4.0.4.19]# ./configure > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... ./install-sh -c -d [snip] If you read the original patch submission carefully http://www.shrubbery.net/pipermail/tac_plus/2009-September/000508.html you'll see it is there at the top, (but quite easy to miss actually - I also missed it the first time) -- Alan McKinnnon alan.mckinnon at gmail.com From joe.moore at holidaycompanies.com Tue Feb 21 16:11:26 2012 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Tue, 21 Feb 2012 16:11:26 +0000 Subject: [tac_plus] auth fail lock fix or alternatives? In-Reply-To: <20120221013741.60d7b134@khamul.example.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> <20120220235243.447de1db@khamul.example.com> <7DC5CF25DDD70D4A845DDC2F96E116B2A0D96B@hcexch01.holidaycompanies.com> <20120221013741.60d7b134@khamul.example.com> Message-ID: <7DC5CF25DDD70D4A845DDC2F96E116B2A0DDF0@hcexch01.holidaycompanies.com> -----Original Message----- From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] Sent: Monday, February 20, 2012 5:38 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] auth fail lock fix or alternatives? SNIP! Found it, see below: [snip] > Hunk #1 succeeded at 153. > Hunk #2 succeeded at 278. > Hunk #3 succeeded at 304. > Hunk #4 succeeded at 623. > Hmm... Ignoring the trailing garbage. > done You need to run "autoconf" here otherwise ./configure won't know about your changes to the sources. For me this makes the difference between it working and getting the same result you got > [root at ns3 ~/download/tacacs+-F4.0.4.19]# ./configure checking for a > BSD-compatible install... /usr/bin/install -c checking whether build > environment is sane... yes checking for a thread-safe mkdir -p... > ./install-sh -c -d [snip] If you read the original patch submission carefully http://www.shrubbery.net/pipermail/tac_plus/2009-September/000508.html you'll see it is there at the top, (but quite easy to miss actually - I also missed it the first time) -- Alan McKinnnon alan.mckinnon at gmail.com Thanks Alan! I've restored the lockout function for the time being. It doesn't look like the AFL patch is available for tac_plus 4.04.20. I'm thinking I'll have to point tac_plus at my Windows Active Directory backend somehow and rely on AD to lock accounts when I update to 4.04.20 and beyond. I can probably do that via PAM but I'll have to study a bit to see if there's a better/simpler way. My FBSD system accounts sync passwords to AD already, and it looks like the software I use for that is dropping FBSD support anyway. ...jgm From daniel.schmidt at wyo.gov Tue Feb 21 22:00:37 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Tue, 21 Feb 2012 15:00:37 -0700 Subject: [tac_plus] Cisco & mandatory pairs/brocade-privlvl Message-ID: I previously reported that a Cisco, given the mandatory brocade-privlvl (which it doesn?t understand), will simply default to disable. This assertion appears to be incorrect. On some devices/versions it puts you in disable, in some it puts you in enable, and on some it flat out denies access telling you authorization failed. Serves me right, expecting consistency when Heasley flat out warned me not to! Brocades new method of using optional av pairs will serve them better - one has to wonder if Cisco makes it work incorrect on purpose. Feb 21 21:30:32.346: AAA/AUTHOR (0x12B): Pick method list 'default' - FAIL Feb 21 21:30:32.390: AAA/AUTHOR/EXEC(0000012B): Authorization FAILED 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 alan.mckinnon at gmail.com Tue Feb 21 22:13:44 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 22 Feb 2012 00:13:44 +0200 Subject: [tac_plus] auth fail lock fix or alternatives? In-Reply-To: <7DC5CF25DDD70D4A845DDC2F96E116B2A0DDF0@hcexch01.holidaycompanies.com> References: <7DC5CF25DDD70D4A845DDC2F96E116B2A0D77C@hcexch01.holidaycompanies.com> <20120220235243.447de1db@khamul.example.com> <7DC5CF25DDD70D4A845DDC2F96E116B2A0D96B@hcexch01.holidaycompanies.com> <20120221013741.60d7b134@khamul.example.com> <7DC5CF25DDD70D4A845DDC2F96E116B2A0DDF0@hcexch01.holidaycompanies.com> Message-ID: <20120222001344.1e2065ea@khamul.example.com> On Tue, 21 Feb 2012 16:11:26 +0000 Joe Moore wrote: > > > -----Original Message----- > From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] > Sent: Monday, February 20, 2012 5:38 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] auth fail lock fix or alternatives? > > SNIP! > > Found it, see below: > > > [snip] > > Hunk #1 succeeded at 153. > > Hunk #2 succeeded at 278. > > Hunk #3 succeeded at 304. > > Hunk #4 succeeded at 623. > > Hmm... Ignoring the trailing garbage. > > done > > You need to run "autoconf" here otherwise ./configure won't know > about your changes to the sources. For me this makes the difference > between it working and getting the same result you got > > > [root at ns3 ~/download/tacacs+-F4.0.4.19]# ./configure checking for a > > BSD-compatible install... /usr/bin/install -c checking whether > > build environment is sane... yes checking for a thread-safe mkdir > > -p... ./install-sh -c -d > > [snip] > > If you read the original patch submission carefully > http://www.shrubbery.net/pipermail/tac_plus/2009-September/000508.html > you'll see it is there at the top, (but quite easy to miss actually - > I also missed it the first time) > > > -- > Alan McKinnnon > alan.mckinnon at gmail.com > > Thanks Alan! > I've restored the lockout function for the time being. > > It doesn't look like the AFL patch is available for tac_plus 4.04.20. > I'm thinking I'll have to point tac_plus at my Windows Active > Directory backend somehow and rely on AD to lock accounts when I > update to 4.04.20 and beyond. > > I can probably do that via PAM but I'll have to study a bit to see if > there's a better/simpler way. My FBSD system accounts sync passwords > to AD already, and it looks like the software I use for that is > dropping FBSD support anyway. Or you could just stick with 4.0.4.19 The Changelog for 4.0.4.20 has only a few changes and a lot of it to streamline code. There are no real bugs as such, no security fixes and the small features added either affect you or they don't. 4.0.4.22 is mainly better support for do_auth.py so you either need it or you don't, and you know which it is. 4.0.4.23 fixes a build error and 4.0.4.21 had a serious bug (fixed in 4.0.4.22) The point being that there's nothing there to warrant any attention at all from a code auditor, and if he does want you to upgrade for the sake of it then he's putting your network at risk. I reckon that if 4.0.4.19 fully satisfies your needs out the box with the afl patch applied, then there is no good reason not to continue with it. Mention to the auditor that it is far better maintained and has far fewer points of concern than IOS -- Alan McKinnnon alan.mckinnon at gmail.com From jathan at gmail.com Tue Feb 21 22:15:13 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 21 Feb 2012 14:15:13 -0800 Subject: [tac_plus] Cisco & mandatory pairs/brocade-privlvl In-Reply-To: References: Message-ID: Very briefly on this topic: Brocade has admitted that on the MDX platform choosing to accept any AV pairs whether the device could process them or not was a design decision. This breaks TACACS+ and I've since asked them to fix this. In any case, the correct behavior according to the TACACS+ protocol when a device receives a mandatory attribute it cannot process is to FAIL authorization, thereby booting you from the device. At least you know that in some cases, the devices are behaving correctly by flat out denying you. On Tue, Feb 21, 2012 at 2:00 PM, Daniel Schmidt wrote: > I previously reported that a Cisco, given the mandatory brocade-privlvl > (which it doesn?t understand), will simply default to disable. This > assertion appears to be incorrect. On some devices/versions it puts you > in disable, in some it puts you in enable, and on some it flat out denies > access telling you authorization failed. Serves me right, expecting > consistency when Heasley flat out warned me not to! Brocades new method of > using optional av pairs will serve them better - one has to wonder if Cisco > makes it work incorrect on purpose. > > > > Feb 21 21:30:32.346: AAA/AUTHOR (0x12B): Pick method list 'default' - FAIL > > Feb 21 21:30:32.390: AAA/AUTHOR/EXEC(0000012B): Authorization FAILED > > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20120221/29fea2ab/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 jathan at gmail.com Tue Feb 21 22:17:50 2012 From: jathan at gmail.com (Jathan McCollum) Date: Tue, 21 Feb 2012 14:17:50 -0800 Subject: [tac_plus] Cisco & mandatory pairs/brocade-privlvl In-Reply-To: References: Message-ID: Sorry, I meant VDX, not MDX. Anyway... On Tue, Feb 21, 2012 at 2:15 PM, Jathan McCollum wrote: > Very briefly on this topic: > > Brocade has admitted that on the MDX platform choosing to accept any AV > pairs whether the device could process them or not was a design decision. > This breaks TACACS+ and I've since asked them to fix this. > > In any case, the correct behavior according to the TACACS+ protocol when a > device receives a mandatory attribute it cannot process is to FAIL > authorization, thereby booting you from the device. > > At least you know that in some cases, the devices are behaving correctly > by flat out denying you. > > > On Tue, Feb 21, 2012 at 2:00 PM, Daniel Schmidt wrote: > >> I previously reported that a Cisco, given the mandatory brocade-privlvl >> (which it doesn?t understand), will simply default to disable. This >> assertion appears to be incorrect. On some devices/versions it puts you >> in disable, in some it puts you in enable, and on some it flat out denies >> access telling you authorization failed. Serves me right, expecting >> consistency when Heasley flat out warned me not to! Brocades new method >> of >> using optional av pairs will serve them better - one has to wonder if >> Cisco >> makes it work incorrect on purpose. >> >> >> >> Feb 21 21:30:32.346: AAA/AUTHOR (0x12B): Pick method list 'default' - FAIL >> >> Feb 21 21:30:32.390: AAA/AUTHOR/EXEC(0000012B): Authorization FAILED >> >> E-Mail to and from me, in connection with the transaction >> of public business, is subject to the Wyoming Public Records >> Act and may be disclosed to third parties. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.shrubbery.net/pipermail/tac_plus/attachments/20120221/29fea2ab/attachment.html >> > >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus >> > > > > -- > Jathan. > -- > -- Jathan. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matej at sustr.sk Thu Feb 23 17:05:43 2012 From: matej at sustr.sk (Matej Sustr) Date: Thu, 23 Feb 2012 18:05:43 +0100 (CET) Subject: [tac_plus] tacacs+-F5.0.0a1 ACL regexec() return value fix Message-ID: Hello, I was fighting with getting our newly installed tacacs+-F5.0.0a1 to work with acls, to allow some users to log in only to some devices. After debugging and looking at the source code I have noticed the regex is not matching correctly. I am sending a patch that fixes the incorrect behavior. Okay I have now noticed at your FTP site that there's a new version of F4.0.4.23 which should fix this for the F4-versions. Which version do you recommend to use in a production environment? Are you planning to add support for privilege dropping (running as non-root user) and chrooting? Thank you for your response. Best Regards, -- Matej Sustr matej at sustr.sk -------------- next part -------------- A non-text attachment was scrubbed... Name: tacacs+-F5.0.0a1_aclregexec-bugfix.patch.gz Type: application/octet-stream Size: 466 bytes Desc: URL: From fernando.pereira at hp.com Thu Feb 23 20:52:59 2012 From: fernando.pereira at hp.com (Pereira, Fernando (Americas RDE)) Date: Thu, 23 Feb 2012 20:52:59 +0000 Subject: [tac_plus] tac_plus compile to HPUX Message-ID: Hello, I would like to know if you have the instructions to compile the tac_plus on HPUX 11.11 and what are the requirements.. Thx in advance Fernando Pereira Americas Production Engineering HP Enterprise Services -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Thu Feb 23 21:18:55 2012 From: heas at shrubbery.net (heasley) Date: Thu, 23 Feb 2012 21:18:55 +0000 Subject: [tac_plus] tac_plus compile to HPUX In-Reply-To: References: Message-ID: <20120223211855.GQ16539@shrubbery.net> Thu, Feb 23, 2012 at 08:52:59PM +0000, Pereira, Fernando (Americas RDE): > Hello, > > I would like to know if you have the instructions to compile the tac_plus on HPUX 11.11 and what are the requirements.. if the configure script does not work, someone with pux will have figure out what is needed to fix it. > Thx in advance > > Fernando Pereira > Americas Production Engineering > HP Enterprise Services > > -------------- 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 alan.mckinnon at gmail.com Thu Feb 23 21:48:12 2012 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 23 Feb 2012 23:48:12 +0200 Subject: [tac_plus] tacacs+-F5.0.0a1 ACL regexec() return value fix In-Reply-To: References: Message-ID: <20120223234812.70096629@khamul.example.com> On Thu, 23 Feb 2012 18:05:43 +0100 (CET) Matej Sustr wrote: > Hello, > > I was fighting with getting our newly installed tacacs+-F5.0.0a1 to > work with acls, to allow some users to log in only to some devices. > After debugging and looking at the source code I have noticed the > regex is not matching correctly. I am sending a patch that fixes the > incorrect behavior. > > Okay I have now noticed at your FTP site that there's a new version > of F4.0.4.23 which should fix this for the F4-versions. > > Which version do you recommend to use in a production environment? > Are you planning to add support for privilege dropping (running as > non-root user) and chrooting? version name tacacs+-F5.0.0a1 tells me "alpha code" in neon lights, so I stick with 4.0.4.18 - it was deployed a while ago and nothing in the Changelogs since is anything I need. tac_plus already supports priv dropping, run ./configure --help to see the options syntax to enable. It works, but with a caveat: non-existing log files are touched by the root user before dropping privs, and usually the tacacs user can't write to them. So if your log files don't exist, tac_plus starts just fine and refuses to work. That can be most annoying so ensure your log rotator touches and chmods new files. I've never seen anything about chroot support, but I'm curious, why would you want it? If you run tac_plus on Linux, a chroot as a security device is rather pointless -- Alan McKinnnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Thu Feb 23 22:10:12 2012 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 23 Feb 2012 15:10:12 -0700 Subject: [tac_plus] tacacs+-F5.0.0a1 ACL regexec() return value fix In-Reply-To: <20120223234812.70096629@khamul.example.com> References: <20120223234812.70096629@khamul.example.com> Message-ID: <0b1eaa9f5cd21ab7dd32d24dab1713ce@mail.gmail.com> F4.0.4.19 has been rock solid for me, with afl patch. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, February 23, 2012 2:48 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] tacacs+-F5.0.0a1 ACL regexec() return value fix On Thu, 23 Feb 2012 18:05:43 +0100 (CET) Matej Sustr wrote: > Hello, > > I was fighting with getting our newly installed tacacs+-F5.0.0a1 to > work with acls, to allow some users to log in only to some devices. > After debugging and looking at the source code I have noticed the > regex is not matching correctly. I am sending a patch that fixes the > incorrect behavior. > > Okay I have now noticed at your FTP site that there's a new version of > F4.0.4.23 which should fix this for the F4-versions. > > Which version do you recommend to use in a production environment? > Are you planning to add support for privilege dropping (running as > non-root user) and chrooting? version name tacacs+-F5.0.0a1 tells me "alpha code" in neon lights, so I stick with 4.0.4.18 - it was deployed a while ago and nothing in the Changelogs since is anything I need. tac_plus already supports priv dropping, run ./configure --help to see the options syntax to enable. It works, but with a caveat: non-existing log files are touched by the root user before dropping privs, and usually the tacacs user can't write to them. So if your log files don't exist, tac_plus starts just fine and refuses to work. That can be most annoying so ensure your log rotator touches and chmods new files. I've never seen anything about chroot support, but I'm curious, why would you want it? If you run tac_plus on Linux, a chroot as a security device is rather pointless -- 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 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 fernando.pereira at hp.com Fri Feb 24 00:25:13 2012 From: fernando.pereira at hp.com (Pereira, Fernando (Americas RDE)) Date: Fri, 24 Feb 2012 00:25:13 +0000 Subject: [tac_plus] tac_plus compile to HPUX References: <20120223211855.GQ16539@shrubbery.net> Message-ID: Hello heasley, I fix the issue with installing some missing libraries, and the configure script works, but now I got an error on make install, can you help ? # ./configure --without-libwrap ... # # make install ... /usr/ccs/bin/ld: Unsatisfied symbols: getspnam (first referenced in pwlib.o) (code) collect2: ld returned 1 exit status *** Error exit code 1 Stop. # Fernando Pereira Americas Production Engineering HP Enterprise Services -----Original Message----- From: Pereira, Fernando (Americas RDE) Sent: Thursday, February 23, 2012 9:08 PM To: 'heasley' Subject: RE: [tac_plus] tac_plus compile to HPUX Hello, I got this error when I run the configure script configure: error: registry requires gnu flex. sorry Fernando Pereira Americas Production Engineering HP Enterprise Services -----Original Message----- From: heasley [mailto:heas at shrubbery.net] Sent: Thursday, February 23, 2012 7:19 PM To: Pereira, Fernando (Americas RDE) Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] tac_plus compile to HPUX Thu, Feb 23, 2012 at 08:52:59PM +0000, Pereira, Fernando (Americas RDE): > Hello, > > I would like to know if you have the instructions to compile the tac_plus on HPUX 11.11 and what are the requirements.. if the configure script does not work, someone with pux will have figure out what is needed to fix it. > Thx in advance > > Fernando Pereira > Americas Production Engineering > HP Enterprise Services > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > b630/attachment.html> _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Fri Feb 24 00:38:59 2012 From: heas at shrubbery.net (heasley) Date: Fri, 24 Feb 2012 00:38:59 +0000 Subject: [tac_plus] tac_plus compile to HPUX In-Reply-To: References: <20120223211855.GQ16539@shrubbery.net> Message-ID: <20120224003859.GV16539@shrubbery.net> Fri, Feb 24, 2012 at 12:25:13AM +0000, Pereira, Fernando (Americas RDE): > Hello heasley, > > I fix the issue with installing some missing libraries, and the configure script works, but now I got an error on make install, can you help ? > > # ./configure --without-libwrap > ... > # > > > # make install > ... > /usr/ccs/bin/ld: Unsatisfied symbols: > getspnam (first referenced in pwlib.o) (code) > collect2: ld returned 1 exit status > *** Error exit code 1 > > Stop. > # the script thinks it has shadow passwords. you have to figure out why, if it doesnt, or whats missing if it does. > Fernando Pereira > Americas Production Engineering > HP Enterprise Services > > > -----Original Message----- > From: Pereira, Fernando (Americas RDE) > Sent: Thursday, February 23, 2012 9:08 PM > To: 'heasley' > Subject: RE: [tac_plus] tac_plus compile to HPUX > > Hello, > > I got this error when I run the configure script > > configure: error: registry requires gnu flex. sorry i think that you can just remove the flex check for now; it will be required for 5.0. flex has features that sysv flex does not. > > Fernando Pereira > Americas Production Engineering > HP Enterprise Services > > > -----Original Message----- > From: heasley [mailto:heas at shrubbery.net] > Sent: Thursday, February 23, 2012 7:19 PM > To: Pereira, Fernando (Americas RDE) > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] tac_plus compile to HPUX > > Thu, Feb 23, 2012 at 08:52:59PM +0000, Pereira, Fernando (Americas RDE): > > Hello, > > > > I would like to know if you have the instructions to compile the tac_plus on HPUX 11.11 and what are the requirements.. > > if the configure script does not work, someone with pux will have figure out what is needed to fix it. > > > Thx in advance > > > > Fernando Pereira > > Americas Production Engineering > > HP Enterprise Services > > > > -------------- next part -------------- An HTML attachment was > > scrubbed... > > URL: > > > b630/attachment.html> _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Fri Feb 24 00:43:36 2012 From: heas at shrubbery.net (heasley) Date: Fri, 24 Feb 2012 00:43:36 +0000 Subject: [tac_plus] tacacs+-F5.0.0a1 ACL regexec() return value fix In-Reply-To: <20120223234812.70096629@khamul.example.com> References: <20120223234812.70096629@khamul.example.com> Message-ID: <20120224004336.GW16539@shrubbery.net> Thu, Feb 23, 2012 at 11:48:12PM +0200, Alan McKinnon: > On Thu, 23 Feb 2012 18:05:43 +0100 (CET) > Matej Sustr wrote: > > > Hello, > > > > I was fighting with getting our newly installed tacacs+-F5.0.0a1 to > > work with acls, to allow some users to log in only to some devices. > > After debugging and looking at the source code I have noticed the > > regex is not matching correctly. I am sending a patch that fixes the > > incorrect behavior. > > > > Okay I have now noticed at your FTP site that there's a new version > > of F4.0.4.23 which should fix this for the F4-versions. > > > > Which version do you recommend to use in a production environment? > > Are you planning to add support for privilege dropping (running as > > non-root user) and chrooting? > > > version name tacacs+-F5.0.0a1 tells me "alpha code" in neon lights, so > I stick with 4.0.4.18 - it was deployed a while ago and nothing in the > Changelogs since is anything I need. very alpha. its the start of a yacc parser for the config + threading. > tac_plus already supports priv dropping, run ./configure --help to see > the options syntax to enable. It works, but with a caveat: > non-existing log files are touched by the root user before dropping > privs, and usually the tacacs user can't write to them. So if your log > files don't exist, tac_plus starts just fine and refuses to work. That > can be most annoying so ensure your log rotator touches and chmods new > files. > > I've never seen anything about chroot support, but I'm curious, why > would you want it? If you run tac_plus on Linux, a chroot as a security > device is rather pointless just use a wrapper script to chroot.