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

Thu Sep 19 20:27:44 UTC 2013

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 <alan.mckinnon at gmail.com>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 <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
>
> _______________________________________________
> 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: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20130919/78820b6f/attachment.html>