From khandesha_kothale at mafatlalcipherspace.in Tue Mar 5 10:11:04 2013 From: khandesha_kothale at mafatlalcipherspace.in (Khandesha Kothale) Date: Tue, 5 Mar 2013 15:41:04 +0530 Subject: [tac_plus] TACACS+ installation issue on CentOS 6.3 64 bit Message-ID: <000001ce1989$c47d4100$4d77c300$@mafatlalcipherspace.in> Dear Tech Team, I am trying to install the free modified cisco's TACACS+ server on CentOS 6.3 ( 64 Bit ) but giving some error while installation of TACACS+ as below. Error:- [root at net-manage tacacs+-F4.0.4.26]# ./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... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... no checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for gmake... no checking for make... no configure: error: can't locate a make. [root at net-manage tacacs+-F4.0.4.26]# I tried to Google this error but not found any valid solution for CentOS . Request you kindly provide me suggestion and step by step installation procedure on CentOS . Best Regards Khandesha Kothale Sr. Network and Security Administrator Mafatlal Cipherspace Pvt. Ltd. Mahim, Mumbai Contact No:022-24441341 Mobile:+919892685616 From heas at shrubbery.net Tue Mar 5 17:19:14 2013 From: heas at shrubbery.net (heasley) Date: Tue, 5 Mar 2013 17:19:14 +0000 Subject: [tac_plus] TACACS+ installation issue on CentOS 6.3 64 bit In-Reply-To: <000001ce1989$c47d4100$4d77c300$@mafatlalcipherspace.in> References: <000001ce1989$c47d4100$4d77c300$@mafatlalcipherspace.in> Message-ID: <20130305171914.GC75662@shrubbery.net> Tue, Mar 05, 2013 at 03:41:04PM +0530, Khandesha Kothale: > Dear Tech Team, > > I am trying to install the free modified cisco's TACACS+ server on CentOS > 6.3 ( 64 Bit ) but giving some error while installation of TACACS+ as below. > > Error:- > [root at net-manage tacacs+-F4.0.4.26]# ./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... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for gmake... no > checking for make... no > configure: error: can't locate a make. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [root at net-manage tacacs+-F4.0.4.26]# > > > I tried to Google this error but not found any valid solution for CentOS . > > Request you kindly provide me suggestion and step by step installation > procedure on CentOS . > > > > Best Regards > Khandesha Kothale > Sr. Network and Security Administrator > Mafatlal Cipherspace Pvt. Ltd. > Mahim, Mumbai > Contact No:022-24441341 Mobile:+919892685616 > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From alan.mckinnon at gmail.com Tue Mar 5 22:45:46 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 06 Mar 2013 00:45:46 +0200 Subject: [tac_plus] TACACS+ installation issue on CentOS 6.3 64 bit In-Reply-To: <20130305171914.GC75662@shrubbery.net> References: <000001ce1989$c47d4100$4d77c300$@mafatlalcipherspace.in> <20130305171914.GC75662@shrubbery.net> Message-ID: <5136759A.6020704@gmail.com> On 05/03/2013 19:19, heasley wrote: > Tue, Mar 05, 2013 at 03:41:04PM +0530, Khandesha Kothale: >> Dear Tech Team, >> >> I am trying to install the free modified cisco's TACACS+ server on CentOS >> 6.3 ( 64 Bit ) but giving some error while installation of TACACS+ as below. >> >> Error:- >> [root at net-manage tacacs+-F4.0.4.26]# ./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... /bin/mkdir -p >> checking for gawk... gawk >> checking whether make sets $(MAKE)... no >> checking whether to enable maintainer-specific portions of Makefiles... no >> checking build system type... x86_64-unknown-linux-gnu >> checking host system type... x86_64-unknown-linux-gnu >> checking for gmake... no >> checking for make... no >> configure: error: can't locate a make. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Errr, he's not likely to know what to do with that :-) Anyone somewhat familiar with compilers and build systems would spot that error right away and know what to do. Khandesha, Your Centos machine does not have a build environment installed. This is common on recent RedHhat-based systems. You will need a compiler and a bunch of other stuff too, including the program "make". You can Google for "install build environment Centos 6.3" but you will likely just run into many more errors because you won't have the development versions of other things installed either. A much better approach is to not try build from source. Install a ready-made binary package of tac_plus instead and avoid having to build it yourself. Google for "tac_plus rpm Centos" and install the most recent you find. Any version greater than say 4.0.4.19 should be OK for most needs. Before you ask, I don't know where to find such - I don't use RedHat. > >> [root at net-manage tacacs+-F4.0.4.26]# >> >> >> I tried to Google this error but not found any valid solution for CentOS . >> >> Request you kindly provide me suggestion and step by step installation >> procedure on CentOS . >> >> >> >> Best Regards >> Khandesha Kothale >> Sr. Network and Security Administrator >> Mafatlal Cipherspace Pvt. Ltd. >> Mahim, Mumbai >> Contact No:022-24441341 Mobile:+919892685616 >> >> >> _______________________________________________ >> 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 > -- Alan McKinnon alan.mckinnon at gmail.com From a.alii85 at gmail.com Mon Mar 11 15:09:32 2013 From: a.alii85 at gmail.com (asad) Date: Mon, 11 Mar 2013 20:09:32 +0500 Subject: [tac_plus] Tacacs+ scenario: can I permit user to configure only for one interface and deny others Message-ID: Hey, I wants to allow certain user A to only able to access interface for configuration. E.g GigabitEthernet 0/0 and at the same time block all others from accessing the same interface. Kindly can you provide the configuration for the setup? Right now I'm using default service = deny cmd = interface { permit [faFAgiGI].* } regards, Asad -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Wed Mar 13 06:41:14 2013 From: heas at shrubbery.net (heasley) Date: Wed, 13 Mar 2013 06:41:14 +0000 Subject: [tac_plus] Tacacs+ scenario: can I permit user to configure only for one interface and deny others In-Reply-To: References: Message-ID: <20130313064114.GA91656@shrubbery.net> Mon, Mar 11, 2013 at 08:09:32PM +0500, asad: > Hey, > > I wants to allow certain user A to only able to access interface for > configuration. E.g > > GigabitEthernet 0/0 > > and at the same time block all others from accessing the same interface. > > Kindly can you provide the configuration for the setup? > > Right now I'm using > default service = deny > > cmd = interface { permit [faFAgiGI].* } afaik, the device will normalize the command - ie: it will expand abbreviations and send a single case, iirc. i do not recall how it deals with sub-level cmd authorization, but this should be enough info for you to experiment. authorization debugging (-d) output will probably be helpful. From tmurch at tommurch.com Thu Mar 14 18:42:37 2013 From: tmurch at tommurch.com (Tom Murch) Date: Thu, 14 Mar 2013 14:42:37 -0400 Subject: [tac_plus] multiple groups per user Message-ID: Hello I am trying to get this working. Reading the mailing list I was under the impression this was fixed. I am trying to have the same users admin both juniper and hp gear. # # tacacs configuration file # xxxxx - # /etc/tac_plus.conf # set the key key = xxxxx accounting file = /var/log/tac_plus.acct #group accounts group = admins { ## cli service for junipers service = junos-exec { local-user-name = admins allow-commands = "all" allow-configuration = "all" deny-commands = "" deny-configuration = "" } } group = admins2 { default service = permit service = exec { priv-lvl = 15 } } # users accounts user = tom { member = admins login = des "xxxxx" enable = cleartext "xxxxx" name = "Thomas Murch" } user = tomhp { member = admins2 login = des "xxxxxx" enable = cleartext "xxxx" name = "Thomas Murch" } -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Thu Mar 14 20:29:35 2013 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 14 Mar 2013 14:29:35 -0600 Subject: [tac_plus] multiple groups per user In-Reply-To: References: Message-ID: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> Checkout do_auth.py. Several people have reported it to be very useful. I've been meaning to do some more work on it and Jathan had some excellent ideas. tacacs.org -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Tom Murch Sent: Thursday, March 14, 2013 12:43 PM To: tac_plus at shrubbery.net Subject: [tac_plus] multiple groups per user Hello I am trying to get this working. Reading the mailing list I was under the impression this was fixed. I am trying to have the same users admin both juniper and hp gear. # # tacacs configuration file # xxxxx - # /etc/tac_plus.conf # set the key key = xxxxx accounting file = /var/log/tac_plus.acct #group accounts group = admins { ## cli service for junipers service = junos-exec { local-user-name = admins allow-commands = "all" allow-configuration = "all" deny-commands = "" deny-configuration = "" } } group = admins2 { default service = permit service = exec { priv-lvl = 15 } } # users accounts user = tom { member = admins login = des "xxxxx" enable = cleartext "xxxxx" name = "Thomas Murch" } user = tomhp { member = admins2 login = des "xxxxxx" enable = cleartext "xxxx" name = "Thomas Murch" } -------------- 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 alan.mckinnon at gmail.com Thu Mar 14 20:55:12 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 14 Mar 2013 22:55:12 +0200 Subject: [tac_plus] multiple groups per user In-Reply-To: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> References: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> Message-ID: <51423930.5@gmail.com> On 14/03/2013 22:29, Daniel Schmidt wrote: > Checkout do_auth.py. Several people have reported it to be very useful. > I've been meaning to do some more work on it and Jathan had some excellent > ideas. > > tacacs.org Hear, hear. Tom, go with Daniel's code. It's the correct approach. tac_plus.conf is very simplistic and for good reason. There is a patche around that supports multiple groups but AFAIK the patch was never merged. Usually with multiple groups one wants to define commands that can be run, and usually they are additive. But you want to separate behaviours of different device types, that's different. No matter how you separate it out, tac_plus is still going to try combine directives from both groups into one big one, so you might as well define one big group in the file anyway. I assume you tried that and found it doesn't work well. I tried that with Junipers; regular IOS was OK with it but it broke the GSRs. We fixed that with optional AV pairs but when we deployed Nexus... let's just say I deployed a second tacacs system instead. do_auth.py has enough information when called that you can make these decisions dynamically and always do the right thing. tac_plus.conf has to have it defined statically and can't do the right thing. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Tom Murch > Sent: Thursday, March 14, 2013 12:43 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] multiple groups per user > > Hello I am trying to get this working. Reading the mailing list I was > under the impression this was fixed. I am trying to have the same users > admin both juniper and hp gear. > > # > # tacacs configuration file > # xxxxx - > # /etc/tac_plus.conf > > # set the key > key = xxxxx > > accounting file = /var/log/tac_plus.acct > > #group accounts > > group = admins { > ## cli service for junipers > service = junos-exec > { > local-user-name = admins > allow-commands = "all" > allow-configuration = "all" > deny-commands = "" > deny-configuration = "" > } > } > > group = admins2 { > default service = permit > service = exec { > priv-lvl = 15 > } > } > > # users accounts > user = tom { > > member = admins > login = des "xxxxx" > enable = cleartext "xxxxx" > name = "Thomas Murch" > } > > user = tomhp { > member = admins2 > login = des "xxxxxx" > enable = cleartext "xxxx" > name = "Thomas Murch" > } > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > /attachment.html> > _______________________________________________ > 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 > -- Alan McKinnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Thu Mar 14 21:29:39 2013 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 14 Mar 2013 15:29:39 -0600 Subject: [tac_plus] multiple groups per user In-Reply-To: <51423930.5@gmail.com> References: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> <51423930.5@gmail.com> Message-ID: <90d90b9df7573994df99e981a830bcdb@mail.gmail.com> Thanks Alan. Note: I fixed Nexus - it modifies the pairs accordingly so you can use tac_plus for all your devices. Or, rather, I kluged a work around that is far too ugly to be considered in the tac_plus code. Do NOT confuse my vendor specific workarounds as bugs in tac_plus - if vendors (even Cisco) would standardize, I wouldn't have to write poor workarounds. I can't remember - I don't think I ever finished testing Juniper. If anybody is interested in testing, please contact me. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, March 14, 2013 2:55 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] multiple groups per user On 14/03/2013 22:29, Daniel Schmidt wrote: > Checkout do_auth.py. Several people have reported it to be very useful. > I've been meaning to do some more work on it and Jathan had some > excellent ideas. > > tacacs.org Hear, hear. Tom, go with Daniel's code. It's the correct approach. tac_plus.conf is very simplistic and for good reason. There is a patche around that supports multiple groups but AFAIK the patch was never merged. Usually with multiple groups one wants to define commands that can be run, and usually they are additive. But you want to separate behaviours of different device types, that's different. No matter how you separate it out, tac_plus is still going to try combine directives from both groups into one big one, so you might as well define one big group in the file anyway. I assume you tried that and found it doesn't work well. I tried that with Junipers; regular IOS was OK with it but it broke the GSRs. We fixed that with optional AV pairs but when we deployed Nexus... let's just say I deployed a second tacacs system instead. do_auth.py has enough information when called that you can make these decisions dynamically and always do the right thing. tac_plus.conf has to have it defined statically and can't do the right thing. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Tom Murch > Sent: Thursday, March 14, 2013 12:43 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] multiple groups per user > > Hello I am trying to get this working. Reading the mailing list I was > under the impression this was fixed. I am trying to have the same > users admin both juniper and hp gear. > > # > # tacacs configuration file > # xxxxx - > # /etc/tac_plus.conf > > # set the key > key = xxxxx > > accounting file = /var/log/tac_plus.acct > > #group accounts > > group = admins { > ## cli service for junipers > service = junos-exec > { > local-user-name = admins > allow-commands = "all" > allow-configuration = "all" > deny-commands = "" > deny-configuration = "" > } > } > > group = admins2 { > default service = permit > service = exec { > priv-lvl = 15 > } > } > > # users accounts > user = tom { > > member = admins > login = des "xxxxx" > enable = cleartext "xxxxx" > name = "Thomas Murch" > } > > user = tomhp { > member = admins2 > login = des "xxxxxx" > enable = cleartext "xxxx" > name = "Thomas Murch" > } > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 7a13 > /attachment.html> > _______________________________________________ > 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 > -- Alan McKinnon 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 kissg at ssg.ki.iif.hu Fri Mar 15 05:58:40 2013 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Fri, 15 Mar 2013 06:58:40 +0100 (CET) Subject: [tac_plus] multiple groups per user In-Reply-To: <51423930.5@gmail.com> References: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> <51423930.5@gmail.com> Message-ID: > tac_plus.conf is very simplistic and for good reason. There is a patche > around that supports multiple groups but AFAIK the patch was never merged. Here: http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/ Gabor -- E-mail = m-mail * c-mail ^ 2 From alan.mckinnon at gmail.com Fri Mar 15 12:13:31 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Fri, 15 Mar 2013 14:13:31 +0200 Subject: [tac_plus] multiple groups per user In-Reply-To: <90d90b9df7573994df99e981a830bcdb@mail.gmail.com> References: <0050a22e1dc7757ed77d769a9f3756c4@mail.gmail.com> <51423930.5@gmail.com> <90d90b9df7573994df99e981a830bcdb@mail.gmail.com> Message-ID: <5143106B.9010505@gmail.com> I can help with testing Juniper. I have to support it anyway, along with IOS XR ASR GSR Nexus A few Junipers Audiocode and a grab-bag collection of weird and wonderful firewalls that were once bought from $DEITY only knows who IOW, pretty much your standard real world network :-) On 14/03/2013 23:29, Daniel Schmidt wrote: > Thanks Alan. Note: I fixed Nexus - it modifies the pairs accordingly so > you can use tac_plus for all your devices. Or, rather, I kluged a work > around that is far too ugly to be considered in the tac_plus code. Do NOT > confuse my vendor specific workarounds as bugs in tac_plus - if vendors > (even Cisco) would standardize, I wouldn't have to write poor workarounds. > > I can't remember - I don't think I ever finished testing Juniper. If > anybody is interested in testing, please contact me. > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Thursday, March 14, 2013 2:55 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] multiple groups per user > > On 14/03/2013 22:29, Daniel Schmidt wrote: >> Checkout do_auth.py. Several people have reported it to be very useful. >> I've been meaning to do some more work on it and Jathan had some >> excellent ideas. >> >> tacacs.org > > Hear, hear. > > Tom, go with Daniel's code. It's the correct approach. > > tac_plus.conf is very simplistic and for good reason. There is a patche > around that supports multiple groups but AFAIK the patch was never merged. > > Usually with multiple groups one wants to define commands that can be run, > and usually they are additive. But you want to separate behaviours of > different device types, that's different. No matter how you separate it > out, tac_plus is still going to try combine directives from both groups > into one big one, so you might as well define one big group in the file > anyway. I assume you tried that and found it doesn't work well. > > I tried that with Junipers; regular IOS was OK with it but it broke the > GSRs. We fixed that with optional AV pairs but when we deployed Nexus... > let's just say I deployed a second tacacs system instead. > > do_auth.py has enough information when called that you can make these > decisions dynamically and always do the right thing. tac_plus.conf has to > have it defined statically and can't do the right thing. > > > > >> >> -----Original Message----- >> From: tac_plus-bounces at shrubbery.net >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Tom Murch >> Sent: Thursday, March 14, 2013 12:43 PM >> To: tac_plus at shrubbery.net >> Subject: [tac_plus] multiple groups per user >> >> Hello I am trying to get this working. Reading the mailing list I was >> under the impression this was fixed. I am trying to have the same >> users admin both juniper and hp gear. >> >> # >> # tacacs configuration file >> # xxxxx - >> # /etc/tac_plus.conf >> >> # set the key >> key = xxxxx >> >> accounting file = /var/log/tac_plus.acct >> >> #group accounts >> >> group = admins { >> ## cli service for junipers >> service = junos-exec >> { >> local-user-name = admins >> allow-commands = "all" >> allow-configuration = "all" >> deny-commands = "" >> deny-configuration = "" >> } >> } >> >> group = admins2 { >> default service = permit >> service = exec { >> priv-lvl = 15 >> } >> } >> >> # users accounts >> user = tom { >> >> member = admins >> login = des "xxxxx" >> enable = cleartext "xxxxx" >> name = "Thomas Murch" >> } >> >> user = tomhp { >> member = admins2 >> login = des "xxxxxx" >> enable = cleartext "xxxx" >> name = "Thomas Murch" >> } >> -------------- next part -------------- An HTML attachment was >> scrubbed... >> URL: >> > 7a13 >> /attachment.html> >> _______________________________________________ >> 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 >> > > > -- > Alan McKinnon > 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. > -- Alan McKinnon alan.mckinnon at gmail.com From rupendra.rathore at rechargeitnow.com Wed Mar 20 07:04:02 2013 From: rupendra.rathore at rechargeitnow.com (R.S. Rathore) Date: Wed, 20 Mar 2013 12:34:02 +0530 Subject: [tac_plus] accounting log timestamp Message-ID: <51495F62.1070301@rechargeitnow.com> Dear Team, I am using tacacs+, so find the below information suggest us about the problem. Version:- tacacs+-F4.0.4.25 Problem:- In accounting logs timestamp print in GMT, but I want to print with local server time. configuration of tac_plus.cfg:- # TACACS Key key = cisco123 accounting syslog; logging = local6 accounting file = /var/log/tacacs/accounting.log #user = domainname { # login = PAM #} user = $enable$ { login = des "enyuUOBeBvYos" } user = avtar09 { #default service = permit login = des "3cRCUzzYHsCBs" member = NOC } user = sharm { #default service = permit login = des "3cRCUzzYHsCBs" member = NOC } user = techops { #default service = permit login = des "3cRCUzzYHsCBs Regards, Rupendra Rathore 09818236305 From alan.mckinnon at gmail.com Wed Mar 20 15:31:33 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 20 Mar 2013 17:31:33 +0200 Subject: [tac_plus] accounting log timestamp In-Reply-To: <51495F62.1070301@rechargeitnow.com> References: <51495F62.1070301@rechargeitnow.com> Message-ID: <5149D655.9020900@gmail.com> You need to configure your syslog server. The client doesn't timestamp syslog entries, syslog does that. Check the usual things - the machine clock is set to GMT, the timezone is correct. You ought to find that all syslog entries are set to GMT, can you confirm if that is the case? On 20/03/2013 09:04, R.S. Rathore wrote: > Dear Team, > > > > I am using tacacs+, so find the below information suggest us about the > problem. > > > Version:- tacacs+-F4.0.4.25 > Problem:- In accounting logs timestamp print in GMT, but I want to > print with local server time. > > configuration of tac_plus.cfg:- > > > > # TACACS Key > key = cisco123 > accounting syslog; > logging = local6 > accounting file = /var/log/tacacs/accounting.log > > #user = domainname { > # login = PAM > #} > > > > > user = $enable$ { > login = des "enyuUOBeBvYos" > } > > user = avtar09 { > #default service = permit > login = des "3cRCUzzYHsCBs" > member = NOC > } > > > user = sharm { > #default service = permit > login = des "3cRCUzzYHsCBs" > member = NOC > } > > user = techops { > #default service = permit > login = des "3cRCUzzYHsCBs > > > Regards, > Rupendra Rathore > 09818236305 > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus -- Alan McKinnon alan.mckinnon at gmail.com From joe.moore at holidaycompanies.com Wed Mar 20 15:42:43 2013 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Wed, 20 Mar 2013 15:42:43 +0000 Subject: [tac_plus] unsubscribe Message-ID: <7DC5CF25DDD70D4A845DDC2F96E116B2114C99D9@hcexch01.holidaycompanies.com> unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: From thachngocquan7 at gmail.com Fri Mar 29 11:17:20 2013 From: thachngocquan7 at gmail.com (Thachngocquan thach ngoc quan) Date: Fri, 29 Mar 2013 18:17:20 +0700 Subject: [tac_plus] lab tacacs on server centos Message-ID: Hiiiii you I need a lab manual authentication configuration tacacs on linux using centos thank you very much -------------- next part -------------- An HTML attachment was scrubbed... URL: