...

My question is about the correlation beetwen the tables in subject, how can i correlate records without using timestamp but maybe a unique session id?

Use the unique session ID.

Ok, but that field is not present in radpostauth too...and i mean ...correlate between tables

...

I think this would be helpful when listing online users, for example when there is no acctstoptime value in radacct and maybe that user in not online anymore,

How do you know?

doing the tests with jradius i've noticed that if you send an auth + start request without a stop you can create this situation, would be the case when the nas reboot or power down in the middle of the auth phase, and so you have this kind of entry in DB.

Do you want to link postauth records with accounting records using a shared unique ID?

Yes reject auth are not stored but replies are, if configured to log them, would be helpful to modify the postauth query to insert the "unique session ID" in a new radpostauth field? I didn't made test in the real till now, and based on my tests i cant see two records in radacct with the same "unique session ID" so i cannot link them. Finally.. i also can check fro time to time the packets or byte fields to see if the sessios is still alive...but this metod would not be better than matching with replies in radpostauth , ...i believe. -- View this message in context: http://freeradius.1045715.n5.nabble.com/racct-and-radpostauth-tp4782906p4785... Sent from the FreeRadius - User mailing list archive at Nabble.com.

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

Acct-Session-ID isn't inserted into the postauth table, because it's generally not available in the Access-Request.

It is theoretically possible to pre-assign an Acct-Session-ID, and its supported by the standards, but no NAS vendors do it because it requires additional effort and adds needless complexity to the code.

Juniper ERXes (JUNOSe) and MXes (JUNOS) send Acct-Session-ID in the Access-Request. Bjørn

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

Ok I revise my statement - Almost no vendors send Acct-Session-ID in the Access-Request :).

But really its very very rare for vendors to do this. I've never personally seen a product in the wild that does, and i've worked with a fair few.

Might be a configuration issue. I just stumbled across this: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfath... <quote> The *radius-server attribute 44 include-in-access-req* command sends RADIUS attribute 44 (Acct-Seccion-ID) in access-request packets. </quote> So it seems IOS based Cisco access servers can do this as well, but it's not the default. Bjørn

andreapepa wrote:

Ok, but that field is not present in radpostauth too...and i mean ...correlate between tables

As Arran said, you can't. This is RADIUS. It's not perfect.

...

How do you know?

doing the tests with jradius i've noticed that if you send an auth + start request without a stop you can create this situation, would be the case when the nas reboot or power down in the middle of the auth phase, and so you have this kind of entry in DB.

I understand that. What I meant was how does the RADIUS server know when a particular user is not online? The answer is "It doesn't".

Yes reject auth are not stored but replies are, if configured to log them, would be helpful to modify the postauth query to insert the "unique session ID" in a new radpostauth field?

This is RADIUS. It can't be done in any reliable way.

Finally.. i also can check fro time to time the packets or byte fields to see if the sessios is still alive...but this metod would not be better than matching with replies in radpostauth , ...i believe.

Ask the NAS is the session is still alive. This is RADIUS. The RADIUS server has no idea what the user session is doing. Alan DeKok.

Arran Cudbard-Bell wrote:

On 9 Sep 2011, at 10:51, Alan DeKok wrote:

...

As Arran said, you can't. This is RADIUS. It's not perfect.

You know being ignored is like my third favourite pass time, right behind spanking cats, and plotting world domination...

It's possible... sometimes. In general, it's not. Alan DeKok.

Thanks Fajar, i'll try to implement this way, i dont want to query the nas by snmp, i have so many nas ( and of various vendor) and i'm not responsible of their configurations and so many concurrent connections that i prefer not to rely on this. Arran, i'm sorry if you felt alone sometimes ;-)....but as i said to Fajar i've no control over the NAS devices so i prefer do all the possible on the FR server. I was not talking about accounting-request but replies stored in radpostauth where by default the postauth query store records with username password op value end date. Maybe, and i'm not an expert of postgresql, can be possible to link these two tables with another ID ? cant see a field to use now, maybe is it possible to add a new field?? I said that because in my tests an access-rejected request is still recorded in radacct table with a start time and a NULL stoptime, but nothing can link this record to the record in radpostauth, time is different too, and that record in radacct can be misrepresented as an online user even from the simultaneous user check. Thanks all for you answer -- View this message in context: http://freeradius.1045715.n5.nabble.com/racct-and-radpostauth-tp4782906p4785... Sent from the FreeRadius - User mailing list archive at Nabble.com.

andreapepa wrote:

...

I said that because  in my tests an access-rejected request is still recorded in radacct table with a start time and a NULL stoptime,

That is odd. What does the debug log says? I'm specifically interested in whether the record in radacct was resulted by (1) NAS sending accounting start even when auth failed, OR (2) some configuration change caused radacct to add an entry even when no acct request accepted If #1, I'm not sure there's anything you can do on FR side, and NAS shouldn't do that. If #2, then fix your config, cause it's not supposed to do that. -- Fajar

On Fri, Sep 9, 2011 at 8:32 PM, andreapepa <andrea.pepa@trentinonetwork.it> wrote:

http://freeradius.1045715.n5.nabble.com/file/n4786389/freeradlogdebug freeradlogdebug

that is the log.

Then your NAS (in this case, the simulator) is clearly broken (or perhaps just misconfigured). It says "rad_recv: Accounting-Request packet from host 172.25.18.35 port 64225, id=246, length=153 Acct-Status-Type = Start " even though the access request was clearly rejected earlier with "Sending Access-Reject of id 40 to 172.25.18.35 port 64225 Reply-Message := "\r\nYou are already logged in - access denied\r\n\n" Now this is a slightly different case compared to what Bjørn mentioned. If Acct-Status-Type=Stop then it would've still made sense somehow, and it will not interfere with simultaneous use checking. HOWEVER, if a NAS sends 'Acct-Status-Type = Start' for a previously rejected authentication request, and without ANY 'Acct-Status-Type = Stop', then it doesn't make any sense, and it WILL interfere with simultaneous query check. No session was ever actually started so it shouldn't even send 'Acct-Status-Type = Start'. So you got two different things: (1) NAS sending 'Acct-Status-Type = Start' for a previously rejected authentication request This is clearly wrong. Fix the NAS. The good thing is since you say this nas is just a simulator, it's entirely possible that it's simply misconfigured, and no "real" NAS would do such a thing. (2) Checking which users are actually logged in There are some ways to do this: a) checkrad (as Alan mentioned), which basically uses several methods (SNMP, telnet, etc.) to ask the NAS directly b) analyze entries on radacct table #2.a is accurate, but might not be desirable in some situation #2.b is more generic and easy, but not 100% accurate, requires interim updates to be configured, and it needs packet arrive time to be recorded. I record it in Acct-Stop-Time column, but you can easly add another column (e.g. Packet-Timestamp) for that purpose. -- Fajar

andreapepa wrote:

a nas send an auth req user accepted and logged user log off but stop packet doesnt arrive to the server, for a lot of reasons. user retry to log in ...maybe from another nas, we also have nas that doesnt communicate the power on/off state

user is rejected due to check on simultaneous login

but looking in radacct we can find two sessions for the same user without stoptime.

That's what the "checkrad" program is for. See doc/Simultaneous-Use. This is documented, and it works. Alan DeKok.

Arran, i'm sorry if you felt alone sometimes ;-)

I'm not the one missing out on radstars :p

....but as i said to Fajar i've no control over the NAS devices so i prefer do all the possible on the FR server.

Yes... and you can. The contents of the Class attribute is set in the Access-Accept, it's not configured on the NAS. You just need to verify it works with the NAS...

I was not talking about accounting-request but replies stored in radpostauth where by default the postauth query store records with username password op value end date. Maybe, and i'm not an expert of postgresql, can be possible to link these two tables with another ID ?

Yes

cant see a field to use now, maybe is it possible to add a new field??

Correct

I said that because in my tests an access-rejected request is still recorded in radacct table with a start time and a NULL stoptime, but nothing can link this record to the record in radpostauth

That's really weird, could you post your debug logs so we can figure out why? -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.

Bjørn Mork wrote:

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

...

As Alan says your NAS won't generate Accounting-Requests if the RADIUS server rejects the user (unless its very broken).

Why would that be broken?

A session that doesn't start requires no accounting. When companies do business accounting, they list only income/expenses. They don't list sales prospects who fail to buy anything. They don't list vendors who never send them invoices. Accounting is for things that happen. Rejects are sessions that never happened.

Yes, I do see that you can trigger RADIUS accounting traffic without authenticating, but the additional load (both for NAS and RADIUS server) is probably negligible compared to the failed authentication anyway.

Accounting generally is a lot more resource intensive than PAP or CHAP authentication. If you want to log rejects, you can do that. You can even customize the "post-auth" section to write into the accounting database. But it's a configuration which will *not* be in the default configuration. Alan DeKok.

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

RFC 2866:

When a client is configured to use RADIUS Accounting, at the start of service delivery it will generate an Accounting Start packet describing the type of service being delivered and the user it is being delivered to, and will send that to the RADIUS Accounting server, which will send back an acknowledgement that the packet has been received. At the end of service delivery the client will generate an Accounting Stop packet describing the type of service that was delivered and optionally statistics such as elapsed time, input and output octets, or input and output packets. It will send that to the RADIUS Accounting server, which will send back an acknowledgement that the packet has been received.

The NAS never provides a service so it should not be sending any accounting packets. Just because people demanded it and the vendor caved, it doesn't mean its correct or compliant.

No, of course not. But it may be useful in some settings. And I really cannot see anything in the above RFC quote which forbids sending radius accounting packets without providing a service. It just states when packets should be sent, and says nothing about when the shouldn't be sent. Of course, you may choose to read RFC 2866 as "anything not explicitly allowed, is forbidden", but I don't think you'll ever make a vendor read the RFCs like that.. Bjørn

Bjørn Mork wrote:

No, of course not. But it may be useful in some settings.

That's why FR is configurable. People do all kinds of crazy things with it. But those things don't make it into the default config.

And I really cannot see anything in the above RFC quote which forbids sending radius accounting packets without providing a service. It just states when packets should be sent, and says nothing about when the shouldn't be sent.

The RFCs are silent on a *lot* of issues. A narrow interpretation of the RFCs would mean that nothing was permitted. A wide interpretation would mean that nearly everything is permitted. A sane approach is to take the middle road. In this case, what 99.9% of deployments have been doing for 15 years: Rejects don't generate accounting sessions.

Of course, you may choose to read RFC 2866 as "anything not explicitly allowed, is forbidden", but I don't think you'll ever make a vendor read the RFCs like that..

Vendors don't read the RFCs. Really. Alan DeKok.