Hi Sean, > I am using an HP MSM760 wireless controller with about 35 Access Points > in a public school. I am hoping to use PacketFence to allow three > classes of users: Staff, Student, and Guest, which should each be placed > in a different VLAN based on their authentication with Radius, which > connects to our Active Directory. Encryption on the WLAN isn’t a high > priority right now, so MAC-based authentication is just fine for me. Ok we have multiple options here. The "easiest" one is to create 3 LDAP-based authentication module, and depending of which one the user selects at the registration time, we can categorize the node in the proper category. Another option would be to dynamically determine the category by checking the DN of a user when registering.
The "coolest" options is (and this is a new trend) to categorize the user, and not the node. Let me explain. So every time a user connects to RADIUS, we re-evaluate the category posture of the node, and change it depending of who logged in. In other word, the category is tied to a user, and not a node. > > Tailing the log files in /usr/log/pf/logs, below is the output that I > see when I attempt to join an unregistered machine to the test network. > From what I can tell, it authenticates, Attempts to dump me in to the > registration VLAN, and then quits saying that the action isn’t supported > on my hardware. Am I just SOL? HP’s documentation appears to indicate > that User-assigned VLANs are supported. > > ==> packetfence.log <== > > Jun 29 12:19:30 pf::WebAPI(7921) INFO: handling radius autz request: > from switch_ip => 172.20.254.254, connection_type => > Wireless-802.11-NoEAP mac => XX:XX:XX:XX:XX:XX, port => 1, username => > xxxxxxxxxxxx (pf::radius::authorize) > > Jun 29 12:19:30 pf::WebAPI(7921) INFO: MAC: XX:XX:XX:XX:XX:XX is of > status unreg; belongs into registration VLAN (pf::vlan::getRegistrationVlan) > > Jun 29 12:19:31 pf::WebAPI(7921) WARN: Role-based Network Access Control > is not supported on network device type pf::SNMP::HP::Controller_MSM710. > (pf::SNMP::supportsRoleBasedEnforcement) > > Jun 29 12:19:33 pfdhcplistener(7900) INFO: DHCPOFFER from 172.20.1.15 > (D1:D1:D1:D1:D1:D1) to host XX:XX:XX:XX:XX:XX (172.20.200.13) > (main::parse_dhcp_offer) > > Jun 29 12:19:33 pfdhcplistener(7900) INFO: DHCPOFFER from 172.20.1.14 > (D2:D2:D2:D2:D2:D2) to host XX:XX:XX:XX:XX:XX (172.20.100.110) > (main::parse_dhcp_offer) > > Jun 29 12:19:33 pfdhcplistener(7900) INFO: DHCPREQUEST from > XX:XX:XX:XX:XX:XX (172.20.200.13) (main::parse_dhcp_request) > > Jun 29 12:19:33 pfdhcplistener(7900) INFO: XX:XX:XX:XX:XX:XX requested > an IP. DHCP Fingerprint: OS::100 (Microsoft Windows XP). Modified node > with last_dhcp = 2012-06-29 12:19:33,computername = > BobsComputer,dhcp_fingerprint = 1,15,3,6,44,46,47,31,33,249,43 > (main::listen_dhcp) > > Jun 29 12:19:33 pfdhcplistener(7900) INFO: DHCPACK from 172.20.1.15 > (D1:D1:D1:D1:D1:D1) to host XX:XX:XX:XX:XX:XX (172.20.200.13) for 691200 > seconds (main::parse_dhcp_ack) > Those output looks fine to me. PF assigns the VLAN, and we see DHCP traffic for the node. The warning you see is just for the RBAC, which is not supported with the HP controllers. You should hit the portal when you open a browser on the client. Thanks! -- Francois Gaudreault, ing. jr [email protected] :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ 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
