From bennie.lam at gmail.com Thu Sep 5 08:04:14 2013 From: bennie.lam at gmail.com (Lam Bennie) Date: Thu, 5 Sep 2013 16:04:14 +0800 Subject: [tac_plus] Network devices frequently report TACACS+ service down Message-ID: Dear Sir/Madam, Grateful for your help in advance. I have installed TACACS+ daemon (version F4.0.4.26 with basic configuration) on a HP server (HP ProLiant DL320 G5P operating on Red Hat Enterprise Linux 5.9, Kernel: 2.6.18-348.3.1.el5PAE i686). My Alcatel-Lucent routers and LAN switches frequently report TACACS+ service is UP and then DOWN (30+ times per hour). Below are some of the syslog messages. >>> Sep 3 10:00:16 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688680 Base SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: TACACS+ server xx.yy.zz.59 operational status changed to down. Sep 3 10:00:31 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688703 Base SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: TACACS+ server xx.yy.zz.59 operational status changed to down. Sep 3 10:01:39 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688713 Base SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: TACACS+ server xx.yy.zz.59 operational status changed to down. Sep 3 10:02:33 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688727 Base SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: TACACS+ server xx.yy.zz.59 operational status changed to down. >>> May I have queries below. ** *1. Why my Alcatel-Lucent routers and LAN switches frequently report the TACACS+ service is UP and then DOWN (30+ times per hour)?* *2. Do Alcatel-Lucent routers and LAN switches have any compatibility issue with TACACS+ daemon? If yes, any workaround or fix?* *3. How to show/verify that TACACS+ daemon is running normally without interruption to my network devices? Can tac_plus "debug" help?* *4. Is below pattern of tac_plus connections (i.e. 3 times in 4 seconds) plausible although noboby or no job tried to login with tac_plus?* "debug" of tac_plus was turned on. Below is the tac_plus command: /var/tacp/tac_plus -C /var/tacp/tac_plus.conf -d 65536 4 As a result, tac_plus log and syslog messages related to one of my Alcatel-Lucent router (IP address: x.y.z.81) are attached below. tac_plus log: ... Wed Sep 4 14:54:44 2013 [12753]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 14:54:44 2013 [12753]: x.y.z.81: exception on fd 1 Wed Sep 4 14:54:44 2013 [12753]: Read -1 bytes from x.y.z.81 , expecting 12 Wed Sep 4 14:55:14 2013 [12832]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 14:55:14 2013 [12832]: x.y.z.81: exception on fd 1 Wed Sep 4 14:55:14 2013 [12832]: Read -1 bytes from x.y.z.81 , expecting 12 Wed Sep 4 14:55:44 2013 [12848]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 14:55:44 2013 [12848]: x.y.z.81: exception on fd 1 Wed Sep 4 14:55:44 2013 [12848]: Read -1 bytes from x.y.z.81 , expecting 12 ... Wed Sep 4 15:02:10 2013 [13458]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 15:02:11 2013 [13460]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 15:02:14 2013 [13469]: connect from x.y.z.81 [x.y.z.81] Wed Sep 4 15:02:16 2013 [13469]: x.y.z.81: exception on fd 1 Wed Sep 4 15:02:16 2013 [13469]: Read -1 bytes from x.y.z.81 , expecting 12 syslog: Sep 4 15:02:14 x.y.z.81 x.y.z.81 NEWTESTNET: 271981 Base SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: TACACS+ server x.y.p.59 operational status changed to down. Thanks Bennie -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Thu Sep 5 15:18:49 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 05 Sep 2013 17:18:49 +0200 Subject: [tac_plus] Network devices frequently report TACACS+ service down In-Reply-To: References: Message-ID: <5228A0D9.1090808@gmail.com> On 05/09/2013 10:04, Lam Bennie wrote: > Dear Sir/Madam, > > Grateful for your help in advance. > > I have installed TACACS+ daemon (version F4.0.4.26 with basic > configuration) on a HP server (HP ProLiant DL320 G5P operating on Red Hat > Enterprise Linux 5.9, Kernel: 2.6.18-348.3.1.el5PAE i686). > > My Alcatel-Lucent routers and LAN switches frequently report TACACS+ > service is UP and then DOWN (30+ times per hour). Below are some of the > syslog messages. > > >>> > Sep 3 10:00:16 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688680 Base > SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: > TACACS+ server xx.yy.zz.59 operational status changed to down. > Sep 3 10:00:31 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688703 Base > SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: > TACACS+ server xx.yy.zz.59 operational status changed to down. > Sep 3 10:01:39 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688713 Base > SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: > TACACS+ server xx.yy.zz.59 operational status changed to down. > Sep 3 10:02:33 xx.yy.kk.1 xx.yy.kk.1 NEWTESTNET: 688727 Base > SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: > TACACS+ server xx.yy.zz.59 operational status changed to down. >>>> > > May I have queries below. > ** > > *1. Why my Alcatel-Lucent routers and LAN switches frequently report > the TACACS+ > service is UP and then DOWN (30+ times per hour)?* I have never observed tac_plus to do this. You may have buggy hardware, a horrible tacas implementation on your hardware, network issues or something wrong with your installed RedHat. The last is highly unlikely (just speaking from experience). But it is almost certainly not tac_plus > *2. Do Alcatel-Lucent routers and LAN switches have any compatibility issue > with TACACS+ daemon? If yes, any workaround or fix?* I have no experience with that hardware. If no-one else here does either, we'll have to resort to your logs and tcpdumps running on your tac_plus server > *3. How to show/verify that TACACS+ daemon is running normally without > interruption to my network devices? Can tac_plus "debug" help?* ps axu | grep tac_plus check if tcp port 49 is open That's normally sufficient (the daemon is *very* well-behaved). If you need more, a perl script using a tacacs client module that merely authentications a user does the job nicely. That's how I do it, run from nagios > *4. Is below pattern of tac_plus connections (i.e. 3 times in 4 seconds) > plausible although noboby or no job tried to login with tac_plus?* 3 connections in 4 seconds is a tiny load, it won't even show up in top. Mine run 2000+ connections a minute, day in, day out for 3 years, with debug set to -d 8 -d 16 I'd say you are most likely dealing with a buggy tacacs implementation on that hardware. It's not unknown to find terrible implementations on non-Cisco hardware. > > "debug" of tac_plus was turned on. Below is the tac_plus command: > /var/tacp/tac_plus -C /var/tacp/tac_plus.conf -d 65536 4 > > As a result, tac_plus log and syslog messages related to one of my > Alcatel-Lucent router (IP address: x.y.z.81) are attached below. > > tac_plus log: > ... > Wed Sep 4 14:54:44 2013 [12753]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 14:54:44 2013 [12753]: x.y.z.81: exception on fd 1 > Wed Sep 4 14:54:44 2013 [12753]: Read -1 bytes from x.y.z.81 , expecting 12 > Wed Sep 4 14:55:14 2013 [12832]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 14:55:14 2013 [12832]: x.y.z.81: exception on fd 1 > Wed Sep 4 14:55:14 2013 [12832]: Read -1 bytes from x.y.z.81 , expecting 12 > Wed Sep 4 14:55:44 2013 [12848]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 14:55:44 2013 [12848]: x.y.z.81: exception on fd 1 > Wed Sep 4 14:55:44 2013 [12848]: Read -1 bytes from x.y.z.81 , expecting 12 > ... > Wed Sep 4 15:02:10 2013 [13458]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 15:02:11 2013 [13460]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 15:02:14 2013 [13469]: connect from x.y.z.81 [x.y.z.81] > Wed Sep 4 15:02:16 2013 [13469]: x.y.z.81: exception on fd 1 > Wed Sep 4 15:02:16 2013 [13469]: Read -1 bytes from x.y.z.81 , expecting 12 > > syslog: > Sep 4 15:02:14 x.y.z.81 x.y.z.81 NEWTESTNET: 271981 Base > SECURITY-MINOR-tacplusInetSrvrOperStatusChange-2025 [tacplus server 2]: > TACACS+ server x.y.p.59 operational status changed to down. > > > Thanks > Bennie > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -- Alan McKinnon alan.mckinnon at gmail.com From heas at shrubbery.net Tue Sep 10 14:01:47 2013 From: heas at shrubbery.net (heasley) Date: Tue, 10 Sep 2013 14:01:47 +0000 Subject: [tac_plus] tac_plus post from andrea.razzini@ericsson.com requires approval In-Reply-To: References: Message-ID: <20130910140147.GA43303@shrubbery.net> > Hello, > > I'm working in Ericsson, trying to set up a Tacacs+ server for IPv6. > does the latest version 27a.tar.gz support IPv6? > Can you provide me some guidance on how-to-configure a Tacacs+ server for IPv6? 4.0.4.27a has a patch to bind IPv6 ports, but I wrote it on a plane where i could only test on my laptop and haven't heard back from the folks who requested it. So, please try it and let us know if it works and on what o/s. From bennie.lam at gmail.com Wed Sep 11 09:04:31 2013 From: bennie.lam at gmail.com (Lam Bennie) Date: Wed, 11 Sep 2013 17:04:31 +0800 Subject: [tac_plus] Basic tac_plus compilation procedure and simple configuration file Message-ID: Can you share the basic tac_plus compilation procedure and simple configuration file (with /etc/passwd for authentication) on RHEL 5.9 for reference? Thanks in advance! As my previous enquiry, my case was suspected to be "a buggy tacacs implementation on that hardware". My case was that my network devices (including Cisco LAN switch) frequently report TACACS+ service is UP and then DOWN (30+ times per hour). tac_plus (version F4.0.4.26) is operating on 2 separate HP servers (HP ProLiant DL320 G5P operating on Red Hat Enterprise Linux 5.9, Kernel: 2.6.18-348.3.1.el5PAE i686). Both HP servers are with same setup for resilience but both are with the same tac_plus problem. Actually, I made basic tac_plus compilation without modifying any tac_plus source files and run tac_plus with simple configuration as following. a) compilation procedure: # ./configure # make # make install b) configuration file: >>> [root at my-server tacp]# more tac_plus.conf key = default authentication = file /etc/passwd accounting file = /var/tacp/log/access.log user = DEFAULT { default service = permit cmd = configure { deny .* } cmd = admin { deny .* } } user = admin1 { member = admin-group } user = admin2 { member = admin-group } group = admin-group { default service = permit } >>> c) command to run tac_plus: # /usr/local/bin/tac_plus -C /var/tacp/tac_plus.conf # ps -ef | grep tac root 22144 1 0 17:32 pts/2 00:00:00 /usr/local/bin/tac_plus -C /var/tacp/tac_plus.conf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbyrd74 at gmail.com Wed Sep 11 17:43:56 2013 From: bbyrd74 at gmail.com (Bo Byrd) Date: Wed, 11 Sep 2013 12:43:56 -0500 Subject: [tac_plus] tac_plus issues Message-ID: Hello, I have authorization set up but it only seems to work if there are no arguments to a command. so my user can 'exit' and can 'show' but cannot 'show run' even though I used the 'permit .*' under the cmd = show section Here is my log, can you tell what is wrong? Thanks for this nifty software! Reading config Version F4.0.4.19 Initialized 1 tac_plus server F4.0.4.19 starting uid=559 euid=559 gid=559 egid=559 s=4 connect from 192.168.0.85 [192.168.0.85] login query for 'ro' tty10 from 192.168.0.85 accepted connect from 192.168.0.85 [192.168.0.85] connect from 192.168.0.85 [192.168.0.85] Start authorization request do_author: user='ro' user 'ro' found authorize_cmd: user=ro, cmd=show line 7 compare show permit '.*' & '' match show permitted by line 7 authorization query for 'ro' tty10 from 192.168.0.85 accepted connect from 192.168.0.85 [192.168.0.85] connect from 192.168.0.85 [192.168.0.85] Start authorization request do_author: user='ro' user 'ro' found authorize_cmd: user=ro, cmd=show running-config cmd show running-config does not exist, denied by default authorization query for 'ro' tty10 from 192.168.0.85 rejected connect from 192.168.0.85 [192.168.0.85] connect from 192.168.0.85 [192.168.0.85] Start authorization request do_author: user='ro' user 'ro' found authorize_cmd: user=ro, cmd=exit line 11 compare exit permit '.*' & '' match exit permitted by line 11 authorization query for 'ro' tty10 from 192.168.0.85 accepted connect from 192.168.0.85 [192.168.0.85] connect from 192.168.0.85 [192.168.0.85] -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Thu Sep 12 09:09:36 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 12 Sep 2013 11:09:36 +0200 Subject: [tac_plus] tac_plus issues In-Reply-To: References: Message-ID: <523184D0.9000901@gmail.com> On 11/09/2013 19:43, Bo Byrd wrote: > Hello, > > I have authorization set up but it only seems to work if there are no > arguments to a command. so my user can 'exit' and can 'show' but cannot > 'show run' even though I used the 'permit .*' under the cmd = show section > > Here is my log, can you tell what is wrong? Thanks for this nifty software! Please post your complete tac_plus.conf (redact passwords and sensitive info as necessary) > > > Reading config > Version F4.0.4.19 Initialized 1 > tac_plus server F4.0.4.19 starting > uid=559 euid=559 gid=559 egid=559 s=4 > connect from 192.168.0.85 [192.168.0.85] > login query for 'ro' tty10 from 192.168.0.85 accepted > connect from 192.168.0.85 [192.168.0.85] > connect from 192.168.0.85 [192.168.0.85] > Start authorization request > do_author: user='ro' > user 'ro' found > authorize_cmd: user=ro, cmd=show > line 7 compare show permit '.*' & '' match > show permitted by line 7 > authorization query for 'ro' tty10 from 192.168.0.85 accepted > connect from 192.168.0.85 [192.168.0.85] > connect from 192.168.0.85 [192.168.0.85] > Start authorization request > do_author: user='ro' > user 'ro' found > authorize_cmd: user=ro, cmd=show running-config > cmd show running-config does not exist, denied by default > authorization query for 'ro' tty10 from 192.168.0.85 rejected > connect from 192.168.0.85 [192.168.0.85] > connect from 192.168.0.85 [192.168.0.85] > Start authorization request > do_author: user='ro' > user 'ro' found > authorize_cmd: user=ro, cmd=exit > line 11 compare exit permit '.*' & '' match > exit permitted by line 11 > authorization query for 'ro' tty10 from 192.168.0.85 accepted > connect from 192.168.0.85 [192.168.0.85] > connect from 192.168.0.85 [192.168.0.85] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -- Alan McKinnon alan.mckinnon at gmail.com From SG00123446 at TechMahindra.com Thu Sep 19 13:42:48 2013 From: SG00123446 at TechMahindra.com (Sachin.6.Gupta) Date: Thu, 19 Sep 2013 19:12:48 +0530 Subject: [tac_plus] session.session_id values coming different for each accounting record? Message-ID: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> Hi, Facing a strange problem when fetching the session id. I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. However session_id is getting populated differently for each accounting packet. Is this the expected behavour? Or something is wrong here? PS: I am testing in lab and only nas is connected with one user only. Please guide. Regards ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.mckinnon at gmail.com Thu Sep 19 13:54:56 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 19 Sep 2013 15:54:56 +0200 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> Message-ID: <523B0230.9020400@gmail.com> On 19/09/2013 15:42, Sachin.6.Gupta wrote: > Hi, > > Facing a strange problem when fetching the session id. > I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. > However session_id is getting populated differently for each accounting packet. > > Is this the expected behavour? Or something is wrong here? > > PS: I am testing in lab and only nas is connected with one user only. > > Please guide. I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" Session The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. Multiple sessions may be supported simultaneously and/or consecutively on a single TCP connection if both the daemon and client support this. If multiple sessions are not being multiplexed over a single tcp connection, a new connection should be opened for each TACACS+ session and closed at the end of that session. For accounting and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. The session is an operational concept that is maintained between the TACACS+ client and daemon. It does not necessarily correspond to a given user or user action. -- Alan McKinnon alan.mckinnon at gmail.com From SG00123446 at TechMahindra.com Thu Sep 19 14:03:40 2013 From: SG00123446 at TechMahindra.com (Sachin.6.Gupta) Date: Thu, 19 Sep 2013 19:33:40 +0530 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <523B0230.9020400@gmail.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> Message-ID: <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. Is there any way/key value to identify accounting packets for a single session? I mean is there a value which remains constant throughout till the user logs out? Regards -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon Sent: Thursday, September 19, 2013 7:25 PM To: tac_plus at shrubbery.net Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? On 19/09/2013 15:42, Sachin.6.Gupta wrote: > Hi, > > Facing a strange problem when fetching the session id. > I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. > However session_id is getting populated differently for each accounting packet. > > Is this the expected behavour? Or something is wrong here? > > PS: I am testing in lab and only nas is connected with one user only. > > Please guide. I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" Session The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. Multiple sessions may be supported simultaneously and/or consecutively on a single TCP connection if both the daemon and client support this. If multiple sessions are not being multiplexed over a single tcp connection, a new connection should be opened for each TACACS+ session and closed at the end of that session. For accounting and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. The session is an operational concept that is maintained between the TACACS+ client and daemon. It does not necessarily correspond to a given user or user action. -- Alan McKinnon alan.mckinnon at gmail.com _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ From SG00123446 at TechMahindra.com Thu Sep 19 14:36:38 2013 From: SG00123446 at TechMahindra.com (Sachin.6.Gupta) Date: Thu, 19 Sep 2013 20:06:38 +0530 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <523B09E1.2040903@gmail.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> <523B09E1.2040903@gmail.com> Message-ID: <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> Thanks Alan, Found this in the RFC. "This field does not change for the duration of the TACACS+ session." As per this statement, it seems that the session id should not change. Per our requirements/deployment, T+ accounting logs might get distributed on 2 separate systems. We had thought reading the above line in RFC that these logs can be further consolidated on a single server based on timestamp and further based on session id some kind of correlation can take place. Now correlating them will become a problem if the session id does not remain same. Regards -----Original Message----- From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] Sent: Thursday, September 19, 2013 7:58 PM To: Sachin.6.Gupta Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? Logically, you would think there would be such a thing; the packet type name even leads you to believe it. It is "accounting", not "command logging", so surely it should be able to track user sessions so you can account for them? (Think old dial-up systems billed by type or time). But no, I have not found such a mechanism in the protocol. The document that describes the Tacacs+ protocol is here (AFAIK it never made it to a full RFC): http://tools.ietf.org/html/draft-grant-tacacs-02 Perhaps you can see something there to use. The "data" and "reason" fields in authorization and accounting resp at first glance look like they might be useful, but I haven't thought it through how one might make use of them (or even if you could) On 19/09/2013 16:03, Sachin.6.Gupta wrote: > Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. > > Is there any way/key value to identify accounting packets for a single session? > I mean is there a value which remains constant throughout till the user logs out? > > Regards > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Thursday, September 19, 2013 7:25 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? > > On 19/09/2013 15:42, Sachin.6.Gupta wrote: >> Hi, >> >> Facing a strange problem when fetching the session id. >> I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. >> However session_id is getting populated differently for each accounting packet. >> >> Is this the expected behavour? Or something is wrong here? >> >> PS: I am testing in lab and only nas is connected with one user only. >> >> Please guide. > > I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" > > Session > The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. > The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. > Multiple sessions may be supported simultaneously and/or > consecutively on a single TCP connection if both the daemon and client > support this. If multiple sessions are not being multiplexed over a > single tcp connection, a new connection should be opened for each > TACACS+ session and closed at the end of that session. For accounting > and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. > The session is an operational concept that is maintained between > the > TACACS+ client and daemon. It does not necessarily correspond to a > TACACS+ given > user or user action. > > > > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > ====================================================================== > ======================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential and subject to the Tech Mahindra policy statement, you > may review the policy at href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi > ndra.com/Disclaimer.html externally and href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech > mahindra.com/tim/disclaimer.html internally within Tech > Mahindra.============================================================= > =============================================================== > > ====================================================================== > ======================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential and subject to the Tech Mahindra policy statement, you > may review the policy at href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi > ndra.com/Disclaimer.html externally and href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech > mahindra.com/tim/disclaimer.html internally within Tech > Mahindra.============================================================= > =============================================================== > -- Alan McKinnon alan.mckinnon at gmail.com ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ From alan.mckinnon at gmail.com Thu Sep 19 16:01:08 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 19 Sep 2013 18:01:08 +0200 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> <523B09E1.2040903@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> Message-ID: <523B1FC4.8040200@gmail.com> I can see how that confusion might arise. Do you use a syslogger for your accounting records? If so, I would recommend you write some magic into that system. Classic syslogd can't do this, but syslog-ng can - it uses a templating engine where you can define various fields in a log entry and do pre- and post-processing on them. You will have to manufacture your own identifier and insert it into the log, the one that first comes to mind is to cat source address, device address, user, terminal, and perhaps a few other fields, then hash the result and store it. It won't be 100% accurate, but it might be good enough for your end. A second option might be to use Splunk, logstash or some other intelligent log cruncher to collate records. They might have already solved the problem you face. Option 3 is maybe tacacs+ can do what you need and neither of us have seen it yet :-) On 19/09/2013 16:36, Sachin.6.Gupta wrote: > Thanks Alan, > > Found this in the RFC. > "This field does not change for the duration of the TACACS+ session." > > As per this statement, it seems that the session id should not change. > > Per our requirements/deployment, T+ accounting logs might get distributed on 2 separate systems. > We had thought reading the above line in RFC that these logs can be further consolidated on a single server based on timestamp and further based on session id some kind of correlation can take place. > > Now correlating them will become a problem if the session id does not remain same. > > Regards > > -----Original Message----- > From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] > Sent: Thursday, September 19, 2013 7:58 PM > To: Sachin.6.Gupta > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? > > Logically, you would think there would be such a thing; the packet type name even leads you to believe it. It is "accounting", not "command logging", so surely it should be able to track user sessions so you can account for them? (Think old dial-up systems billed by type or time). > > But no, I have not found such a mechanism in the protocol. > > The document that describes the Tacacs+ protocol is here (AFAIK it never made it to a full RFC): > > http://tools.ietf.org/html/draft-grant-tacacs-02 > > Perhaps you can see something there to use. The "data" and "reason" > fields in authorization and accounting resp at first glance look like they might be useful, but I haven't thought it through how one might make use of them (or even if you could) > > > > > > On 19/09/2013 16:03, Sachin.6.Gupta wrote: >> Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. >> >> Is there any way/key value to identify accounting packets for a single session? >> I mean is there a value which remains constant throughout till the user logs out? >> >> Regards >> >> -----Original Message----- >> From: tac_plus-bounces at shrubbery.net >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon >> Sent: Thursday, September 19, 2013 7:25 PM >> To: tac_plus at shrubbery.net >> Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? >> >> On 19/09/2013 15:42, Sachin.6.Gupta wrote: >>> Hi, >>> >>> Facing a strange problem when fetching the session id. >>> I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. >>> However session_id is getting populated differently for each accounting packet. >>> >>> Is this the expected behavour? Or something is wrong here? >>> >>> PS: I am testing in lab and only nas is connected with one user only. >>> >>> Please guide. >> >> I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" >> >> Session >> The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. >> The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. >> Multiple sessions may be supported simultaneously and/or >> consecutively on a single TCP connection if both the daemon and client >> support this. If multiple sessions are not being multiplexed over a >> single tcp connection, a new connection should be opened for each >> TACACS+ session and closed at the end of that session. For accounting >> and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. >> The session is an operational concept that is maintained between >> the >> TACACS+ client and daemon. It does not necessarily correspond to a >> TACACS+ given >> user or user action. >> >> >> >> >> >> -- >> Alan McKinnon >> alan.mckinnon at gmail.com >> >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo/tac_plus >> >> ====================================================================== >> ======================================================Disclaimer: >> This message and the information contained herein is proprietary and >> confidential and subject to the Tech Mahindra policy statement, you >> may review the policy at > href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi >> ndra.com/Disclaimer.html externally and > href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech >> mahindra.com/tim/disclaimer.html internally within Tech >> Mahindra.============================================================= >> =============================================================== >> >> ====================================================================== >> ======================================================Disclaimer: >> This message and the information contained herein is proprietary and >> confidential and subject to the Tech Mahindra policy statement, you >> may review the policy at > href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi >> ndra.com/Disclaimer.html externally and > href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech >> mahindra.com/tim/disclaimer.html internally within Tech >> Mahindra.============================================================= >> =============================================================== >> > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > > ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ > -- Alan McKinnon alan.mckinnon at gmail.com From alan.mckinnon at gmail.com Thu Sep 19 14:27:45 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 19 Sep 2013 16:27:45 +0200 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> Message-ID: <523B09E1.2040903@gmail.com> Logically, you would think there would be such a thing; the packet type name even leads you to believe it. It is "accounting", not "command logging", so surely it should be able to track user sessions so you can account for them? (Think old dial-up systems billed by type or time). But no, I have not found such a mechanism in the protocol. The document that describes the Tacacs+ protocol is here (AFAIK it never made it to a full RFC): http://tools.ietf.org/html/draft-grant-tacacs-02 Perhaps you can see something there to use. The "data" and "reason" fields in authorization and accounting resp at first glance look like they might be useful, but I haven't thought it through how one might make use of them (or even if you could) On 19/09/2013 16:03, Sachin.6.Gupta wrote: > Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. > > Is there any way/key value to identify accounting packets for a single session? > I mean is there a value which remains constant throughout till the user logs out? > > Regards > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > Sent: Thursday, September 19, 2013 7:25 PM > To: tac_plus at shrubbery.net > Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? > > On 19/09/2013 15:42, Sachin.6.Gupta wrote: >> Hi, >> >> Facing a strange problem when fetching the session id. >> I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. >> However session_id is getting populated differently for each accounting packet. >> >> Is this the expected behavour? Or something is wrong here? >> >> PS: I am testing in lab and only nas is connected with one user only. >> >> Please guide. > > I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" > > Session > The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. > The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. > Multiple sessions may be supported simultaneously and/or consecutively on a single TCP connection if both the daemon and client support this. If multiple sessions are not being multiplexed over a single tcp connection, a new connection should be opened for each > TACACS+ session and closed at the end of that session. For accounting > and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. > The session is an operational concept that is maintained between the > TACACS+ client and daemon. It does not necessarily correspond to a given > user or user action. > > > > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ > > ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ > -- Alan McKinnon alan.mckinnon at gmail.com From alan.mckinnon at gmail.com Thu Sep 19 16:00:59 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Thu, 19 Sep 2013 18:00:59 +0200 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> <523B09E1.2040903@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> Message-ID: <523B1FBB.2040107@gmail.com> I can see how that confusion might arise. Do you use a syslogger for your accounting records? If so, I would recommend you write some magic into that system. Classic syslogd can't do this, but syslog-ng can - it uses a templating engine where you can define various fields in a log entry and do pre- and post-processing on them. You will have to manufacture your own identifier and insert it into the log, the one that first comes to mind is to cat source address, device address, user, terminal, and perhaps a few other fields, then hash the result and store it. It won't be 100% accurate, but it might be good enough for your end. A second option might be to use Splunk, logstash or some other intelligent log cruncher to collate records. They might have already solved the problem you face. Option 3 is maybe tacacs+ can do what you need and neither of us have seen it yet :-) On 19/09/2013 16:36, Sachin.6.Gupta wrote: > Thanks Alan, > > Found this in the RFC. > "This field does not change for the duration of the TACACS+ session." > > As per this statement, it seems that the session id should not change. > > Per our requirements/deployment, T+ accounting logs might get distributed on 2 separate systems. > We had thought reading the above line in RFC that these logs can be further consolidated on a single server based on timestamp and further based on session id some kind of correlation can take place. > > Now correlating them will become a problem if the session id does not remain same. > > Regards > > -----Original Message----- > From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] > Sent: Thursday, September 19, 2013 7:58 PM > To: Sachin.6.Gupta > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? > > Logically, you would think there would be such a thing; the packet type name even leads you to believe it. It is "accounting", not "command logging", so surely it should be able to track user sessions so you can account for them? (Think old dial-up systems billed by type or time). > > But no, I have not found such a mechanism in the protocol. > > The document that describes the Tacacs+ protocol is here (AFAIK it never made it to a full RFC): > > http://tools.ietf.org/html/draft-grant-tacacs-02 > > Perhaps you can see something there to use. The "data" and "reason" > fields in authorization and accounting resp at first glance look like they might be useful, but I haven't thought it through how one might make use of them (or even if you could) > > > > > > On 19/09/2013 16:03, Sachin.6.Gupta wrote: >> Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. >> >> Is there any way/key value to identify accounting packets for a single session? >> I mean is there a value which remains constant throughout till the user logs out? >> >> Regards >> >> -----Original Message----- >> From: tac_plus-bounces at shrubbery.net >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon >> Sent: Thursday, September 19, 2013 7:25 PM >> To: tac_plus at shrubbery.net >> Subject: Re: [tac_plus] session.session_id values coming different for each accounting record? >> >> On 19/09/2013 15:42, Sachin.6.Gupta wrote: >>> Hi, >>> >>> Facing a strange problem when fetching the session id. >>> I am storing the session id in the accounting logs also. My understanding is that when tacacs+ client sends accounting packet to TACACS+ server, session_id should remain same for the host till logout happens. >>> However session_id is getting populated differently for each accounting packet. >>> >>> Is this the expected behavour? Or something is wrong here? >>> >>> PS: I am testing in lab and only nas is connected with one user only. >>> >>> Please guide. >> >> I guess you have wrongly assumed what session means here, it is not a login session from login to logout. From the Tacacs draft RFC in section "Technical Definitions" >> >> Session >> The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. >> The session concept is important because a session identifier is used as a part of the encryption, and it is used by both ends to distinguish between packets belonging to multiple sessions. >> Multiple sessions may be supported simultaneously and/or >> consecutively on a single TCP connection if both the daemon and client >> support this. If multiple sessions are not being multiplexed over a >> single tcp connection, a new connection should be opened for each >> TACACS+ session and closed at the end of that session. For accounting >> and authorization, this implies just a single pair of packets exchanged over the connection (the request and its reply). For authentication, a single session may involve an arbitrary number of packets being exchanged. >> The session is an operational concept that is maintained between >> the >> TACACS+ client and daemon. It does not necessarily correspond to a >> TACACS+ given >> user or user action. >> >> >> >> >> >> -- >> Alan McKinnon >> alan.mckinnon at gmail.com >> >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo/tac_plus >> >> ====================================================================== >> ======================================================Disclaimer: >> This message and the information contained herein is proprietary and >> confidential and subject to the Tech Mahindra policy statement, you >> may review the policy at > href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi >> ndra.com/Disclaimer.html externally and > href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech >> mahindra.com/tim/disclaimer.html internally within Tech >> Mahindra.============================================================= >> =============================================================== >> >> ====================================================================== >> ======================================================Disclaimer: >> This message and the information contained herein is proprietary and >> confidential and subject to the Tech Mahindra policy statement, you >> may review the policy at > href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi >> ndra.com/Disclaimer.html externally and > href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech >> mahindra.com/tim/disclaimer.html internally within Tech >> Mahindra.============================================================= >> =============================================================== >> > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > > ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ > -- Alan McKinnon alan.mckinnon at gmail.com From daniel.schmidt at wyo.gov Thu Sep 19 20:27:44 2013 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Thu, 19 Sep 2013 14:27:44 -0600 Subject: [tac_plus] session.session_id values coming different for each accounting record? In-Reply-To: <523B1FBB.2040107@gmail.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0E248289@SINNODMBX001.TechMahindra.com> <523B0230.9020400@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E2482CB@SINNODMBX001.TechMahindra.com> <523B09E1.2040903@gmail.com> <251C71CF3919A942A3A12FDD3CC76101DC0E248328@SINNODMBX001.TechMahindra.com> <523B1FBB.2040107@gmail.com> Message-ID: My question is: why care? When parsing tacacs logs, I care only about a few pieces of information. User, NAS, IP, and priv_15 command. Did the user login, logout, then login again before typing "reload" on his core device? Don't know - don't care. On a side note, I did post a rudimentary python cgi log parser a while back. It was nothing special, but hey, it works and would save you from having to program your own. On Thu, Sep 19, 2013 at 10:00 AM, Alan McKinnon wrote: > I can see how that confusion might arise. > > Do you use a syslogger for your accounting records? If so, I would > recommend you write some magic into that system. Classic syslogd can't > do this, but syslog-ng can - it uses a templating engine where you can > define various fields in a log entry and do pre- and post-processing on > them. You will have to manufacture your own identifier and insert it > into the log, the one that first comes to mind is to cat source address, > device address, user, terminal, and perhaps a few other fields, then > hash the result and store it. > > It won't be 100% accurate, but it might be good enough for your end. > A second option might be to use Splunk, logstash or some other > intelligent log cruncher to collate records. They might have already > solved the problem you face. > > Option 3 is maybe tacacs+ can do what you need and neither of us have > seen it yet :-) > > > On 19/09/2013 16:36, Sachin.6.Gupta wrote: > > Thanks Alan, > > > > Found this in the RFC. > > "This field does not change for the duration of the TACACS+ session." > > > > As per this statement, it seems that the session id should not change. > > > > Per our requirements/deployment, T+ accounting logs might get > distributed on 2 separate systems. > > We had thought reading the above line in RFC that these logs can be > further consolidated on a single server based on timestamp and further > based on session id some kind of correlation can take place. > > > > Now correlating them will become a problem if the session id does not > remain same. > > > > Regards > > > > -----Original Message----- > > From: Alan McKinnon [mailto:alan.mckinnon at gmail.com] > > Sent: Thursday, September 19, 2013 7:58 PM > > To: Sachin.6.Gupta > > Cc: tac_plus at shrubbery.net > > Subject: Re: [tac_plus] session.session_id values coming different for > each accounting record? > > > > Logically, you would think there would be such a thing; the packet type > name even leads you to believe it. It is "accounting", not "command > logging", so surely it should be able to track user sessions so you can > account for them? (Think old dial-up systems billed by type or time). > > > > But no, I have not found such a mechanism in the protocol. > > > > The document that describes the Tacacs+ protocol is here (AFAIK it never > made it to a full RFC): > > > > http://tools.ietf.org/html/draft-grant-tacacs-02 > > > > Perhaps you can see something there to use. The "data" and "reason" > > fields in authorization and accounting resp at first glance look like > they might be useful, but I haven't thought it through how one might make > use of them (or even if you could) > > > > > > > > > > > > On 19/09/2013 16:03, Sachin.6.Gupta wrote: > >> Oh :(. Thanks Alan for clarifying it. I completely misunderstood it. > >> > >> Is there any way/key value to identify accounting packets for a single > session? > >> I mean is there a value which remains constant throughout till the user > logs out? > >> > >> Regards > >> > >> -----Original Message----- > >> From: tac_plus-bounces at shrubbery.net > >> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon > >> Sent: Thursday, September 19, 2013 7:25 PM > >> To: tac_plus at shrubbery.net > >> Subject: Re: [tac_plus] session.session_id values coming different for > each accounting record? > >> > >> On 19/09/2013 15:42, Sachin.6.Gupta wrote: > >>> Hi, > >>> > >>> Facing a strange problem when fetching the session id. > >>> I am storing the session id in the accounting logs also. My > understanding is that when tacacs+ client sends accounting packet to > TACACS+ server, session_id should remain same for the host till logout > happens. > >>> However session_id is getting populated differently for each > accounting packet. > >>> > >>> Is this the expected behavour? Or something is wrong here? > >>> > >>> PS: I am testing in lab and only nas is connected with one user only. > >>> > >>> Please guide. > >> > >> I guess you have wrongly assumed what session means here, it is not a > login session from login to logout. From the Tacacs draft RFC in section > "Technical Definitions" > >> > >> Session > >> The concept of a session is used throughout this document. A > TACACS+ session is a single authentication sequence, a single authorization > exchange, or a single accounting exchange. > >> The session concept is important because a session identifier is > used as a part of the encryption, and it is used by both ends to > distinguish between packets belonging to multiple sessions. > >> Multiple sessions may be supported simultaneously and/or > >> consecutively on a single TCP connection if both the daemon and client > >> support this. If multiple sessions are not being multiplexed over a > >> single tcp connection, a new connection should be opened for each > >> TACACS+ session and closed at the end of that session. For accounting > >> and authorization, this implies just a single pair of packets exchanged > over the connection (the request and its reply). For authentication, a > single session may involve an arbitrary number of packets being exchanged. > >> The session is an operational concept that is maintained between > >> the > >> TACACS+ client and daemon. It does not necessarily correspond to a > >> TACACS+ given > >> user or user action. > >> > >> > >> > >> > >> > >> -- > >> Alan McKinnon > >> alan.mckinnon at gmail.com > >> > >> _______________________________________________ > >> tac_plus mailing list > >> tac_plus at shrubbery.net > >> http://www.shrubbery.net/mailman/listinfo/tac_plus > >> > >> ====================================================================== > >> ======================================================Disclaimer: > >> This message and the information contained herein is proprietary and > >> confidential and subject to the Tech Mahindra policy statement, you > >> may review the policy at >> href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi > >> ndra.com/Disclaimer.html externally and >> href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech > >> mahindra.com/tim/disclaimer.html internally within Tech > >> Mahindra.============================================================= > >> =============================================================== > >> > >> ====================================================================== > >> ======================================================Disclaimer: > >> This message and the information contained herein is proprietary and > >> confidential and subject to the Tech Mahindra policy statement, you > >> may review the policy at >> href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi > >> ndra.com/Disclaimer.html externally and >> href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech > >> mahindra.com/tim/disclaimer.html internally within Tech > >> Mahindra.============================================================= > >> =============================================================== > >> > > > > > > -- > > Alan McKinnon > > alan.mckinnon at gmail.com > > > > > > > ============================================================================================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential and subject to the Tech Mahindra policy statement, you may > review the policy at http://www.techmahindra.com/Disclaimer.html externally and > http://tim.techmahindra.com/tim/disclaimer.html internally within > Tech > Mahindra.============================================================================================================================ > > > > > -- > Alan McKinnon > alan.mckinnon at gmail.com > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Santosh at microscan.co.in Mon Sep 23 10:07:28 2013 From: Santosh at microscan.co.in (Santosh Patil) Date: Mon, 23 Sep 2013 10:07:28 +0000 Subject: [tac_plus] Configuration error Message-ID: Hi, Getting following error while starting TACACS service please suggest /etc/init.d/tac_plus start Starting Tacacs+ server: /usr/local/bin/tac_plus: error while loading shared libraries: libtacacs.so.1: cannot open shared object file: No such file or directory tac_plus. Thanks and Regards Santosh Patil Manager (IT) [cid:359564509 at 10062010-1EEC] Microscan Computers Private Limited A301/303, Everest Grande,Mahakali caves rd., Andheri (E), Mumbai - 400 093. India P - +91 (022) 66870600 E - santosh at microscan.co.in W - www.microscan.co.in M - +91 9320730605 NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Microscan Computers Pvt. Ltd. immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them. Tel - 022-66870600 Fax - 022-66870800 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1834 bytes Desc: image001.jpg URL: From alan.mckinnon at gmail.com Tue Sep 24 13:17:18 2013 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Tue, 24 Sep 2013 15:17:18 +0200 Subject: [tac_plus] Configuration error In-Reply-To: References: Message-ID: <524190DE.2070205@gmail.com> That's a regular Unix error, not specific to tac_plus. It means the tac_plus binary cannot find a shared library it needs. Two primary reasons: ldconfig was not run a needed entry was not added to /etc/ld.so.conf Google will reveal many sites explaining how to work with shared libraries and the search paths for them. On 23/09/2013 12:07, Santosh Patil wrote: > Hi, > > Getting following error while starting TACACS service please suggest > > > /etc/init.d/tac_plus start > Starting Tacacs+ server: /usr/local/bin/tac_plus: error while loading shared libraries: libtacacs.so.1: cannot open shared object file: No such file or directory > tac_plus. > > Thanks and Regards > > > Santosh Patil > Manager (IT) > > [cid:359564509 at 10062010-1EEC] > Microscan Computers Private Limited > A301/303, Everest Grande,Mahakali caves rd., > Andheri (E), Mumbai - 400 093. India > P - +91 (022) 66870600 > E - santosh at microscan.co.in > W - www.microscan.co.in > M - +91 9320730605 > > NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Microscan Computers Pvt. Ltd. immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them. Tel - 022-66870600 Fax - 022-66870800 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.jpg > Type: image/jpeg > Size: 1834 bytes > Desc: image001.jpg > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -- Alan McKinnon alan.mckinnon at gmail.com From vadud3 at gmail.com Wed Sep 25 16:14:07 2013 From: vadud3 at gmail.com (Asif Iqbal) Date: Wed, 25 Sep 2013 12:14:07 -0400 Subject: [tac_plus] Configuration error In-Reply-To: References: Message-ID: On Mon, Sep 23, 2013 at 6:07 AM, Santosh Patil wrote: > Starting Tacacs+ server: /usr/local/bin/tac_plus: error while loading > shared libraries: libtacacs.so.1: cannot open shared object file: No such > file or directory > tac_plus. > what does the `` ldd /usr/local/bin/tac_plus '' gives you? -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From SG00123446 at TechMahindra.com Mon Sep 30 07:21:40 2013 From: SG00123446 at TechMahindra.com (Sachin.6.Gupta) Date: Mon, 30 Sep 2013 12:51:40 +0530 Subject: [tac_plus] Illegal data size when TACACS+ running on 64 bit debian machine Message-ID: <251C71CF3919A942A3A12FDD3CC76101DC0FB1A459@SINNODMBX001.TechMahindra.com> Hi, I keep on getting "Illegal Data Size" when TACACS+ is running on 64 Bit Unix machines. Same package when compiled on 32 bit machine, works fine. I have configured a D-Link switch with my TACACS+ server. I am currently debugging this, but is there a compatibility issue reported for 64 bit TACACS+? Please advice. Regards ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Mon Sep 30 20:34:26 2013 From: heas at shrubbery.net (heasley) Date: Mon, 30 Sep 2013 20:34:26 +0000 Subject: [tac_plus] Illegal data size when TACACS+ running on 64 bit debian machine In-Reply-To: <251C71CF3919A942A3A12FDD3CC76101DC0FB1A459@SINNODMBX001.TechMahindra.com> References: <251C71CF3919A942A3A12FDD3CC76101DC0FB1A459@SINNODMBX001.TechMahindra.com> Message-ID: <20130930203426.GC2034@shrubbery.net> Mon, Sep 30, 2013 at 12:51:40PM +0530, Sachin.6.Gupta: > Hi, > > I keep on getting "Illegal Data Size" when TACACS+ is running on 64 Bit Unix machines. > Same package when compiled on 32 bit machine, works fine. what O/S? is a long not 32bits on your platform? > I have configured a D-Link switch with my TACACS+ server. > > I am currently debugging this, but is there a compatibility issue reported for 64 bit TACACS+? not tha ti know of. > Please advice. > > Regards > > > > > ============================================================================================================================Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/tim/disclaimer.html internally within Tech Mahindra.============================================================================================================================ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus