(RADIATOR) Tying Authentication information to Accounting information.

[Terry Simons]

Hi,

I'm still trying to wade through the "Broken Accounting" problem that  
most APs seem to have.

I'm wondering if Radiator knows that a given accounting record is tied  
to a given authentication record...

Maybe an example can demonstrate what I mean:

Let's say we have 2 users on an 802.1x network who both authenticate to  
the same AP at approximately the same time.  The AP has broken  
accounting, so those records aren't very useful to me, but there are  
bits that I need from both the authentication and the accounting  
portions of the session.

To muddy the waters a little bit, both users are using something like  
TTLS or PEAP, where it is perfectly legal to have an outer identity of  
"anonymous" or "anonymous at domain.com".

I want to know that accounting record "A" goes with authentication "A"  
and not authentication "B" but I can't tie them together with the  
information from the accounting/authentication because there isn't a  
single identifier common between the two.

It doesn't seem likely that this is possible because I don't see how  
Radiator would know this anymore than I can determine it by looking at  
the information myself, but I figure that it doesn't hurt to ask.

My specific problem is that some APs (but not all of them) don't report  
the NAS-Port attribute in both the authentication AND the accounting.   
This can lead to problems when trying to determine if user X was  
logging into 802.11a, 802.11b, or 802.11g networks if we base strictly  
off of the NAS-Port (I don't see any other way to do this).  Since  
broken APs typically don't account the Calling-Station-Id, I can't use  
that... and using the username isn't viable, since it's possible to  
have "anonymous" in the outer identity field.

This actually isn't a problem for the APs I'm most concerned about  
(Proxim/Agere/Avaya/HP AP-2000) because the Accounting-Session-Id is  
actually the same value as the Calling-Station-Id that is reported in  
the Authentication.... but I am wary of using this particular kludge  
simply because it might not work like this in the future.

I also wanted to ask why I'm getting errors in my PreProcessingHook  
call:

Sun Feb 15 01:14:58 2004: ERR: Error in PreProcessingHook(): Can't call  
method "getAttrByNum" on an undefined value at (eval 32) line 67.

Is it not possible to use calls to dig into the accounting information  
like this:?

my $callingstationid =  
$dbh->quote(${$p}->{outerRequest}->getAttrByNum($Radius::Radius:: 
CALLING_STATION_ID));

This works just fine in the PostAuthHook.

Is this because the CALLING_STATION_ID parameter doesn't actually exist  
in my accounting record, or is it for some other reason?

Thanks!

- Terry

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.