[tac_plus] session.session_id values coming different for each accounting record?

Thu Sep 19 16:01:08 UTC 2013

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 <a 
>> href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi
>> ndra.com/Disclaimer.html</a> externally and <a 
>> href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech
>> mahindra.com/tim/disclaimer.html</a> 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 <a 
>> href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahi
>> ndra.com/Disclaimer.html</a> externally and <a 
>> href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.tech
>> mahindra.com/tim/disclaimer.html</a> 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 <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.techmahindra.com/tim/disclaimer.html</a> internally within Tech Mahindra.============================================================================================================================
> 

-- 
Alan McKinnon
alan.mckinnon at gmail.com