Hello Jake,
I think that we've run into the same (or similar) behaviour in our
installation of PF. From a WAP (Cisco 1252) we have some SSIDs which
validate directly against freeRadius as well as an 'open' SSID which
PF needs to handle (registration, as usual, etc.). The PF
rlm_perl_packetfence module was kicking out logins to the EAP SSIDs
*after* freeRadius had validated them. That is, freeRadius would say
'ok' to them, after which rlm_perl_packetfence would look at them and
return 'not ok'.
I put together a *kludge* which seemingly works in having
rlm_perl_packetfence ignore the EAP logins. I am heavily qualifying
this post as I don't know whether this 'fix' is at all general or will
work outside of our installation. Any feedback, critique, illumination
from the gurus-in-residence from Inverse would be greatly appreciated.
Are there any obvious problems with this that I am missing ?
Is there a better way of doing this ?
Is there some way of getting the SSID or the relevant VLAN for the
authentication transaction directly from the WAP ? (Or possibly
having a new SSIDs config item relevant to rlm_perl_packetfence ?
Hint, hint ...)
So I'll post it to you (and the list) with rather extreme cautions,
disclaimers and reservations : be careful. All feedback is solicited -
please.
----------------------------------------------------------
In the 'sub authorize' section of rlm_perl_packetfence, near the top
of the sub, enter the following few Perl lines :
## enter the following code just above the existing
## '#format MAC lines'
## kludge here to prevent this module's rejection of an EAP request
## from the WAP which doesn't concern PF - pass through and ignore
## (with RLM_MODULE_OK) ssids which don't concern PacketFence
## the 'open' ssid which concerns PF can be identified by the
## 'User-Name' and 'User-Password' $RAD_REQUEST values containing
## the WAP's mac address, passed also in 'Calling-Station-Id'
##
## some mac reformatting is necessary
##
my $tst_mac = $RAD_REQUEST{'Calling-Station-Id'};
## unaccountably, the WAP mac comes through in
## 'Calling-Station-Id' formatted as 'nnnn,nnnn,nnnn'
## while in the 'User-Name' & 'User-Password' fields
## it appears as 'nnnnnnnnnnnn' -
## for comparison, the commas are removed
my $tst_mac = substr($tst_mac,0,4) . substr($tst_mac,5,4) .
substr($tst_mac,10,4);
if ($RAD_REQUEST{'User-Name'} ne $tst_mac &&
$RAD_REQUEST{'User-Password'} ne $tst_mac) {
## if the 'User-Name' & 'User-Password' have been supplied
## by the user it's a genuine WPA2/EAP request return OK here
##
syslog("info", "authorize() - this WAP2/EAP request has nothing to do
with PF");
syslog("info", "authorize() - User-Name & User-Password were supplied");
syslog("info", "authorize() - User-Name=$RAD_REQUEST{'User-Name'}
User-Password=$RAD_REQUEST{'User-password'}
Calling-Station-Id=$RAD_REQUEST{'Calling-Station-Id'}");
return RLM_MODULE_OK;
}
## if it's to be treated by PacketFence, the transaction falls
## through here and continues normally below ...
----------------------------------------------------------
Hope it works for you, feedback about any/all implications I might
have missed are welcome.
Best wishes,
Chris
On Fri 5.Nov'10 at 20:05:07 +0000, Sallee, Stephen (Jake) wrote:
> I have run across something in the PacketFence module for FreeRADIUS and
> would like to see if anyone can reproduce the behaviour.
>
> When using the PF Perl module for FreeRADIUS in vlan switching mode the user
> is able to authenticate with any FR supported protocol for registration, at
> this point PF only listens to the requests and FR is the one actually doing
> the authentication.
>
> However after the client successfully registers and the VLan switch takes
> place the PF module will reject all requests other than EAP/PEAP type
> requests.
>
> I have a linux laptop set up for TTLS that will not authenticate a registered
> user, however a guest user that has not yet registered will be able to
> register fine. The instant I change the auth method to PEAP it works fine.
>
> In the log I see a message about a registered user on an insecure SSID, and
> the module returns VLan -1.
>
> Jake Sallee
> Godfather of Bandwidth
> Network Engineer
> University of Mary Hardin-Baylor
>
> 900 College St.
> Belton, Texas
> 76513
>
> Fone: 254-295-4658
> Phax: 254-295-4221
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Packetfence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
