<div dir="ltr">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. <div>
<br></div><div>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. </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 10:00 AM, Alan McKinnon <span dir="ltr"><<a href="mailto:alan.mckinnon@gmail.com" target="_blank">alan.mckinnon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb">I can see how that confusion might arise.<br>
<br>
Do you use a syslogger for your accounting records? If so, I would<br>
recommend you write some magic into that system. Classic syslogd can't<br>
do this, but syslog-ng can - it uses a templating engine where you can<br>
define various fields in a log entry and do pre- and post-processing on<br>
them. You will have to manufacture your own identifier and insert it<br>
into the log, the one that first comes to mind is to cat source address,<br>
device address, user, terminal, and perhaps a few other fields, then<br>
hash the result and store it.<br>
<br>
It won't be 100% accurate, but it might be good enough for your end.<br>
A second option might be to use Splunk, logstash or some other<br>
intelligent log cruncher to collate records. They might have already<br>
solved the problem you face.<br>
<br>
Option 3 is maybe tacacs+ can do what you need and neither of us have<br>
seen it yet :-)<br>
<br>
<br>
On 19/09/2013 16:36, Sachin.6.Gupta wrote:<br>
</div><div class="HOEnZb"><div class="h5">> Thanks Alan,<br>
><br>
> Found this in the RFC.<br>
> "This field does not change for the duration of the TACACS+ session."<br>
><br>
> As per this statement, it seems that the session id should not change.<br>
><br>
> Per our requirements/deployment, T+ accounting logs might get distributed on 2 separate systems.<br>
> 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.<br>
><br>
> Now correlating them will become a problem if the session id does not remain same.<br>
><br>
> Regards<br>
><br>
> -----Original Message-----<br>
> From: Alan McKinnon [mailto:<a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a>]<br>
> Sent: Thursday, September 19, 2013 7:58 PM<br>
> To: Sachin.6.Gupta<br>
> Cc: <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
> Subject: Re: [tac_plus] session.session_id values coming different for each accounting record?<br>
><br>
> 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).<br>
><br>
> But no, I have not found such a mechanism in the protocol.<br>
><br>
> The document that describes the Tacacs+ protocol is here (AFAIK it never made it to a full RFC):<br>
><br>
> <a href="http://tools.ietf.org/html/draft-grant-tacacs-02" target="_blank">http://tools.ietf.org/html/draft-grant-tacacs-02</a><br>
><br>
> Perhaps you can see something there to use. The "data" and "reason"<br>
> 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)<br>
><br>
><br>
><br>
><br>
><br>
> On 19/09/2013 16:03, Sachin.6.Gupta wrote:<br>
>> Oh :(. Thanks Alan for clarifying it. I completely misunderstood it.<br>
>><br>
>> Is there any way/key value to identify accounting packets for a single session?<br>
>> I mean is there a value which remains constant throughout till the user logs out?<br>
>><br>
>> Regards<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:tac_plus-bounces@shrubbery.net">tac_plus-bounces@shrubbery.net</a><br>
>> [mailto:<a href="mailto:tac_plus-bounces@shrubbery.net">tac_plus-bounces@shrubbery.net</a>] On Behalf Of Alan McKinnon<br>
>> Sent: Thursday, September 19, 2013 7:25 PM<br>
>> To: <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
>> Subject: Re: [tac_plus] session.session_id values coming different for each accounting record?<br>
>><br>
>> On 19/09/2013 15:42, Sachin.6.Gupta wrote:<br>
>>> Hi,<br>
>>><br>
>>> Facing a strange problem when fetching the session id.<br>
>>> 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.<br>
>>> However session_id is getting populated differently for each accounting packet.<br>
>>><br>
>>> Is this the expected behavour? Or something is wrong here?<br>
>>><br>
>>> PS: I am testing in lab and only nas is connected with one user only.<br>
>>><br>
>>> Please guide.<br>
>><br>
>> 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"<br>
>><br>
>> Session<br>
>> 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.<br>
>> 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.<br>
>> Multiple sessions may be supported simultaneously and/or<br>
>> consecutively on a single TCP connection if both the daemon and client<br>
>> support this. If multiple sessions are not being multiplexed over a<br>
>> single tcp connection, a new connection should be opened for each<br>
>> TACACS+ session and closed at the end of that session. For accounting<br>
>> 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.<br>
>> The session is an operational concept that is maintained between<br>
>> the<br>
>> TACACS+ client and daemon. It does not necessarily correspond to a<br>
>> TACACS+ given<br>
>> user or user action.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Alan McKinnon<br>
>> <a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a><br>
>><br>
>> _______________________________________________<br>
>> tac_plus mailing list<br>
>> <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
>> <a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
>><br>
>> ======================================================================<br>
>> ======================================================Disclaimer:<br>
>> This message and the information contained herein is proprietary and<br>
>> confidential and subject to the Tech Mahindra policy statement, you<br>
>> may review the policy at <a<br>
>> href="<a href="http://www.techmahindra.com/Disclaimer.html" target="_blank">http://www.techmahindra.com/Disclaimer.html</a>"><a href="http://www.techmahi" target="_blank">http://www.techmahi</a><br>
>> <a href="http://ndra.com/Disclaimer.html" target="_blank">ndra.com/Disclaimer.html</a></a> externally and <a<br>
>> href="<a href="http://tim.techmahindra.com/tim/disclaimer.html" target="_blank">http://tim.techmahindra.com/tim/disclaimer.html</a>"><a href="http://tim.tech" target="_blank">http://tim.tech</a><br>
>> <a href="http://mahindra.com/tim/disclaimer.html" target="_blank">mahindra.com/tim/disclaimer.html</a></a> internally within Tech<br>
>> Mahindra.=============================================================<br>
>> ===============================================================<br>
>><br>
>> ======================================================================<br>
>> ======================================================Disclaimer:<br>
>> This message and the information contained herein is proprietary and<br>
>> confidential and subject to the Tech Mahindra policy statement, you<br>
>> may review the policy at <a<br>
>> href="<a href="http://www.techmahindra.com/Disclaimer.html" target="_blank">http://www.techmahindra.com/Disclaimer.html</a>"><a href="http://www.techmahi" target="_blank">http://www.techmahi</a><br>
>> <a href="http://ndra.com/Disclaimer.html" target="_blank">ndra.com/Disclaimer.html</a></a> externally and <a<br>
>> href="<a href="http://tim.techmahindra.com/tim/disclaimer.html" target="_blank">http://tim.techmahindra.com/tim/disclaimer.html</a>"><a href="http://tim.tech" target="_blank">http://tim.tech</a><br>
>> <a href="http://mahindra.com/tim/disclaimer.html" target="_blank">mahindra.com/tim/disclaimer.html</a></a> internally within Tech<br>
>> Mahindra.=============================================================<br>
>> ===============================================================<br>
>><br>
><br>
><br>
> --<br>
> Alan McKinnon<br>
> <a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a><br>
><br>
><br>
> ============================================================================================================================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 <a href="<a href="http://www.techmahindra.com/Disclaimer.html" target="_blank">http://www.techmahindra.com/Disclaimer.html</a>"><a href="http://www.techmahindra.com/Disclaimer.html" target="_blank">http://www.techmahindra.com/Disclaimer.html</a></a> externally and <a href="<a href="http://tim.techmahindra.com/tim/disclaimer.html" target="_blank">http://tim.techmahindra.com/tim/disclaimer.html</a>"><a href="http://tim.techmahindra.com/tim/disclaimer.html" target="_blank">http://tim.techmahindra.com/tim/disclaimer.html</a></a> internally within Tech Mahindra.============================================================================================================================<br>
><br>
<br>
<br>
--<br>
Alan McKinnon<br>
<a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a><br>
<br>
_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
</div></div></blockquote></div><br></div>
<pre>
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.