(RADIATOR) Accessing radiator internals from a postauthhook?
Terry Simons
galimore at mac.com
Thu Jan 19 23:49:48 CST 2006
Hey Jeff,
I wrote this script quite a long time ago, and never sent it to the
list... I'm sure it will be of use to some people.
It sounds like you might be trying to do something similar...
hopefully this information will help.
Hugh, please feel free to add this to the goodies directory, if you
wish.
To quote the documentation:
# calling_station_hook_requests.pl
#
# This hook does three things:
#
# 1) Insert the Calling-Station-ID into the inner request
# 2) Insert the Called-Station-ID into the inner request
# 3) Insert the "outer" EAP identity into the inner request as "Outer-
EAP-Id"
#
# This provides the ability to AuthLog inner authentication requests
with
# the MAC address of the user authenticating with EAP types such as PEAP
# or TTLS where an anonymous outer identity might be allowed.
#
# Using this script, it is possible to get useable authentication
logs, even
# from NAS devices that do not support accounting, or do not support it
# correctly. (Such as the D-Link DWL-900AP+, Linksys WRT54G/WAP54G,
HP 420).
#
# This script also has implications for tracking down users that are
misusing
# the outer identity, since both the outer and inner id are availble
in the log
# message. :)
#
# Additionally, by using clever Identifiers in your handler, you can
log the EAP
# type in use. This could be handy for testing, or shops that need
multiple EAP
# types.
The script is at the bottom of this E-mail, but here are bits from my
configuration that might help explain a few things.
First, here are some example log lines:
Fri Dec 17 11:20:57 2006,terry,terry,66.92.12.6,icebox,Success,
00-0B-0E-0A-ED-40:dot11i-mixed,00-11-24-2A-97-53,org.reverse.domain.ttls
Fri Dec 17 11:24:20 2006,bogus,bogus,66.92.12.6,icebox,Failure,
00-0B-0E-0A-ED-40:wpa-mixed,00-11-24-2A-97-53,org.reverse.domain.ttls
Fri Dec 17 11:25:32 2006,terry,anonymous,66.92.12.6,icebox,Success,
00-0B-0E-0A-ED-40:dot11i-mixed,00-11-24-2A-97-53,org.reverse.domain.ttls
And here are the relevant config bits:
<Handler TunnelledByTTLS=1>
Identifier org.reverse.domain.ttls
AuthLog AuthLogFile
AuthLog AuthLogSQL
AuthBy BY_FILE
PostAuthHook file:"/usr/local/var/uofu/scripts/
calling_station_hook_requests.pl"
</Handler>
And for PEAP:
<Handler TunnelledByPEAP=1>
Identifier org.reverse.domain.peap
AuthLog AuthLogFile
AuthLog AuthLogSQL
<AuthBy FILE>
Filename %D/users
# This tells the PEAP client what types of inner EAP requests
# we will honour
EAPType MSCHAP-V2
</AuthBy>
PostAuthHook file:"/usr/local/var/uofu/scripts/
calling_station_hook_requests.pl"
</Handler>
And here's my AuthBy BY_FILE clause, in case people are curious about
that:
<AuthBy FILE>
Identifier BY_FILE
Filename %D/users
EAPType TTLS PEAP MSCHAP-V2 LEAP TLS
EAPTLS_MaxFragmentSize 1000
EAPTLS_CAFile /etc/radiator/certificates/root.pem
EAPTLS_CertificateType PEM
EAPTLS_CertificateFile /etc/radiator/certificates/cert-
srv.pem
EAPTLS_PrivateKeyFile /etc/radiator/certificates/cert-
srv.pem
EAPTLS_PrivateKeyPassword whatever
EAPTLS_SessionResumption 0
EAPAnonymous %0
# Needed for Mac OS X user support
EAPTLS_PEAPVersion 0
AutoMPPEKeys
</AuthBy>
Here is an example AuthLog SQL clause:
<AuthLog SQL>
Identifier AuthLogSQL
DBSource dbi:CSV:f_dir=/usr/local/var/uofu/db/
DBUsername NOT_NEEDED #CSV DB
DBAuth NOT_NEEDED #CSV DB
LogSuccess 1
SuccessQuery insert into ORG_REVERSE_DOMAIN_DOT1X (\
PRETTY_DATE,\
USERNAME,\
OUTER_EAP_ID,\
NAS_IP_ADDRESS,\
HOSTNAME,\
AUTH_STATUS,\
CALLED_STATION_ID,\
CALLING_STATION_ID,\
IDENTIFIER\
) values (\
'%l',\
'%u',\
'%{Outer-EAP-Id}',\
'%N',\
'%h',\
'Success',\
'%{Called-Station-Id}',\
'%{Calling-Station-Id}',\
'%{Handler:Identifier}'\
)
LogFailure 1
FailureQuery insert into ORG_REVERSE_DOMAIN_DOT1X (\
PRETTY_DATE,\
USERNAME,\
OUTER_EAP_ID,\
NAS_IP_ADDRESS,\
HOSTNAME,\
AUTH_STATUS,\
CALLED_STATION_ID,\
CALLING_STATION_ID,\
IDENTIFIER,\
) values (\
'%l',\
'%u',\
'%{Outer-EAP-Id}',\
'%N',\
'%h',\
'Failure',\
'%{Called-Station-Id}',\
'%{Calling-Station-Id}',\
'%{Handler:Identifier}'\
)
</AuthLog>
And here is an example AuthLog FILE clause:
<AuthLog FILE>
Identifier AuthLogFile
Filename %L/authlog/org.reverse.domain.authlog.log
LogSuccess 1
LogFailure 1
SuccessFormat %l,%u,%{Outer-EAP-Id},%N,%h,Success,%
{Called-Station-Id},%{Calling-Station-Id},%{Handler:Identifier}
FailureFormat %l,%u,%{Outer-EAP-Id},%N,%h,Failure,%
{Called-Station-Id},%{Calling-Station-Id},%{Handler:Identifier}
</AuthLog>
Here's the hook script itself:
# calling_station_hook_requests.pl
#
# This hook does three things:
#
# 1) Insert the Calling-Station-ID into the inner request
# 2) Insert the Called-Station-ID into the inner request
# 3) Insert the "outer" EAP identity into the inner request as "Outer-
EAP-Id"
#
# This provides the ability to AuthLog inner authentication requests
with
# the MAC address of the user authenticating with EAP types such as PEAP
# or TTLS where an anonymous outer identity might be allowed.
#
# Using this script, it is possible to get useable authentication
logs, even
# from NAS devices that do not support accounting, or do not support it
# correctly. (Such as the D-Link DWL-900AP+, Linksys WRT54G/WAP54G,
HP 420).
#
# This script also has implications for tracking down users that are
misusing
# the outer identity, since both the outer and inner id are availble
in the log
# message. :)
#
# Additionally, by using clever Identifiers in your handler, you can
log the EAP
# type in use. This could be handy for testing, or shops that need
multiple EAP
# types.
#
# Author: Terry Simons (Terry.Simons at gmail.com)
# See goodies/eap_ttls.cfg for example configuration.
#
sub
{
my ($p, $rp, $handled, $reason) = @_;
# If there is a 3rd arg then we are being called as PostAuthHook
if (defined $handled)
{
if (${$p}->code() eq 'Access-Request' && ${$p}->{outerRequest})
{
# RFC 3580 specifies a particular format for Calling-
Station-Id and
# Called-Station-Id formats. We ought to go ahead and
convert to be RFC compliant
${$p}->addAttrByNum($Radius::Radius::CALLING_STATION_ID,
${$p}->{outerRequest}->getAttrByNum
($Radius::Radius::CALLING_STATION_ID));
${$p}->addAttrByNum($Radius::Radius::CALLED_STATION_ID, $
{$p}->{outerRequest}->getAttrByNum($Radius::Radius::CALLED_STATION_ID));
${$p}->add_attr('Outer-EAP-Id', ${$p}->{outerRequest}-
>get_attr('User-Name'));
}
}
}
On Jan 19, 2006, at 3:48 PM, Hugh Irvine wrote:
>
> Hello Jeff -
>
> I generally find the simplest thing to do is add Identifiers to my
> Client clauses (this can also be done with ClientListSQL).
>
>
> <Client 1.1.1.1>
> Identifier BROKEN
> .....
> </Client>
>
> <Client 2.2.2.2>
> Identifier BROKEN
> .....
> </Client>
>
> <Client 3.3.3.3>
> Identifier NOT-BROKEN
> .....
> </Client>
>
> .....
>
>
> Then your hook code can check the Identifier and do whatever:
>
>
> # PostAuthHook
>
> sub
> {
> my $p = ${$_[0]};
> my $rp = ${$_[1]};
> my $handled = $_[2];
> my $reason = $_[3];
>
> my $clientIdentifier = $p->{Client}->{Identifier};
>
> return unless $clientIdentifier eq 'BROKEN';
>
> # do whatever
>
> .......
>
> return;
> }
>
>
> There are numerous examples in "goodies/hooks.txt".
>
> And no there is no "description of the request object", per se, but
> you will see everything contained in the requests in a trace 4 debug.
>
> Hope that helps.
>
> regards
>
> Hugh
>
>
> On 20 Jan 2006, at 06:41, Jeff Wolfe wrote:
>
>>
>>
>> I'm trying to work around a deficiency in the implementation of
>> RADIUS on some of our network hardware. In particular, several
>> vendors' switches do 802.1x just fine, but do not produce any
>> useful information in RADIUS accounting messages.
>>
>> To work around this problem, I would like to have a postauthhook
>> log certain information from an .1x access-request operation, but
>> only for certain NASes. Since <ClientListSQL> already imports
>> enough information for my code to discriminate between NASes, I
>> would like to access that information instead of going out and
>> hitting the SQL db for each authentication operation.
>>
>> So the logic would go:
>>
>> Postauthhook:
>>
>> Look up NAS
>>
>> if br0ken
>> do additional logging
>> else
>> ignore.
>>
>>
>> Unfortunately, the current TTLS eap_anon_hook isn't enough.. These
>> particular NASes either don't do RADIUS accounting, or only log
>> useful information like the EAP outer identity and start time, so
>> there's nothing unique to tie the info in the access request with
>> the accounting packets.
>>
>> Actually, is there a description of the request object anywhere,
>> too? :)
>> Once I get this stuff sorted out, I need to pull the relevant bits
>> out of the request packet.
>>
>> I've been over the manual once, but nothing jumped out at me.
>>
>> Thanks.
>>
>> -JEff
>>
>> --
>> 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 read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/
> archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> 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.
--
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.
More information about the radiator
mailing list