On 6/13/2012 3:25 PM, Barry Quiel wrote: > On 6/6/2012 5:44 AM, Francois Gaudreault wrote: >> While I think this further, that's exactly what I told you at first >> place. >> >> Returning -1 will make RADIUS auth fail, so the device won't associate. >> >> On 12-06-06 8:41 AM, Francois Gaudreault wrote: >>> Hi, >>> >>>> The one thing that your suggestion doesn't prevent is the device >>>> association with the access point. It will move the device into the >>>> ether but not until after the device has gone through authentication ( >>>> mac auth in this case ) on the open ssid, on the access point. I just >>>> don't even want the device to associate. I can do it with an >>>> association ACL on the access point, but I would like to manage it all >>>> in one place. If I could tie a violation to the radius auth so that >>>> when you see "handling radius autz request: from switch_ip" it would >>>> send a auth reject message instead of an accept message, there by >>>> preventing the device from associating. Obviously this would only >>>> work >>>> with violations based on VENDORMAC. >>> If you want to prevent association, we can overload our >>> getRegistrationVlan to deny it (ie returning -1 instead of a VLAN id). >>> The RADIUS authz will be rejected, and the user won't be able to >>> associate. >>> >>> Thanks! >>> > There are two different suggestions here. Although related the > results are different. In the first case I tried setting the > violation trap location customVlan5 and defined customVlan5 as -1. > The problem is the violation is not processed in the registration > vlan. The device is still able to associate. Which take me to your > second suggestion of overloading getRegistrationVlan. I can > definitely do that. How do I get access to the violations? Is there > a function I can call, something like isViolating that will check the > MAC, for example, against all the active violations? I can then take > the return from that and decide on a vlan to return from > getRegistrationVlan. So I take some of that back. It does process violations on unregistered devices in the registration vlan. Packetfence however does not like a -1 for a vlan id:
Jun 13 16:12:11 pf::WebAPI(20479) WARN: VLAN customVlan5 is not properly configured in switches.conf, not a vlan number (pf::SNMP::getVlanByName) Jun 13 16:12:11 pf::WebAPI(20479) WARN: There was a problem identifying vlan for violation. Will act as if there was no violation. (pf::vlan::fetchVlanForNode) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
