[RADIATOR] Perl expressions

[Heikki Vatiainen]

On 10/23/2013 08:14 PM, Michael Hulko wrote:

> Thanks for the clarification... I was able to do as suggested.  However,
>  I am finding that evaluating check items in Handlers using Vendor VSAs
>  are a hit or miss.

There should not be any difference in Vendor and IANA (non-Vendor)
attributes. Both are looked up and treated the same when e.g, choosing
the Handler.

> I have in my config...
> 
> <Handler Client-Identifier = ONCAMPUS, Aruba-Port-Identifier =
> <controller-address>:0/11>  ----->  This works fine !
> 
> <Handler TunnelledByPeap=1, Client-Identifier=ONCAMPUS, Realm=uwo.ca>
>  --------> This works fine !
> 
> <Handler TunnelledByPeap=1, Client-Identifier=ONCAMPUS, Realm=uwo.ca,
> Aruba-Essid-Name=<ssid of choice> ------->  FAILS !!!

The reason here is likely that nothing adds Aruba-Essid-Name in the
inner request. If you watch Trace 4 log, you can see what goes in the
request describing the tunnelled request. Some basic attributes go, but
VSAs by default do not.

This one-liner in the outer AuthBy should help:

PreHandlerHook sub {my $p = ${$_[0]}; $p->add_attr('Aruba-Essid-Name',
$p->{outerRequest}->get_attr('Aruba-Essid-Name'));}

The trace 4 log should now show that the tunnelled request has
Aruba-Essid-Name.

Apparently Aruba-Port-Identifier was in the Handler that picks up the
request from the NAS, not inner request?

> My dictionary file has all the Aruba VSA's defined..
> 
> other testing shows that it works with Some VSA's but not all...

Maybe the ones that did not work are handlers for inner requests?

Thanks,
Heikki


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.