(RADIATOR) Tying Authentication information to Accounting information.

[Hugh Irvine]

Hello Terry -

You should start by looking at the example in  
"goodies/eap_anon_hook.pl".

regards

Hugh


On 15 Feb 2004, at 19:22, Terry Simons wrote:

> 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.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

===
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.