Matt:
To elaborate on Fabrice's statements jut a bit: The RADIUS portion of PF can be thought of as just the mechanism PF uses to talk to the controllers / APs / Switches. All the logic of who and what devices get what role is defined in PF and those roles should correspond with some type of established network based method of controlling access. In our instance we use VLans and internal firewalls. When a user authenticates the role they are assigned in PF triggers the RADIUS server to respond to the AP with a VLan assignment for that host, that vlan has established rules concerning where hosts on the subnet can and cannot go on the network which are enforced via our internal firewalls. There are other ways you can do it but this is how we do it and my gut feeling is it is very similar to how must people deploy PF. PF will not return an ACCESS DENY except under special circumstances, most of the time you don't want access deny anyway. Typically when you want to deny a user access to network resources, you want to isolate them. Isolation provides the ability to push the user onto a network subnet where you can better control their access and allow for self-remediation, if you want. There are corner cases where outright rejecting the user is what you want, and I am just a stranger on the Internet who knows nothing about your specific requirements ... so you can take my comments with a proverbial grain of salt, YMMV, etc. Hope that helps, please feel free to post back to the list with any problems you have. If I can help and I have time I'll respond. Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________ From: Fabrice Durand via PacketFence-users <[email protected]> Sent: Thursday, October 12, 2017 10:30 AM To: [email protected] Cc: Fabrice Durand Subject: Re: [PacketFence-users] PacketFence FreeRADIUS only configuration Hello Matt, with mac auth packetfence return by default Accept but the vlan_id/Acl/Role is different based on the status of the device. Let say if a device is unreg then you probably want to return Accept with an acl name that will deny the access to the network and when you set the device reg with a role then you probably want to Accept too by with an acl name that will allow the device on the network. On the opposite when you do 802.1x then if the username and password is correct then PacketFence will return Accept but if you use a wrong username and password the return will be Deny. Also to debug when freeradius run, go in /usr/local/pf and do raddebug -f var/run/radius.sock -t 3000 Regards Fabrice Le 2017-10-12 à 10:47, Matt Fogleman via PacketFence-users a écrit : I'm really new to both FreeRADIUS and PacketFence, what I am trying to do is just get a simple Mac auth configuration up for our wireless network. I installed PacketFence with the new RADIUS only option on RHEL7, I added our wireless controller in the Configuration > Switches section and gave it the RADIUS key, and also configured the same thing on our wireless controller. It seems to be accepting connections, but it is just accepting everything. I added the Mac address of a laptop in the "Nodes" section, and saw in Auditing that it sent back an Accept message. But then I deleted the Mac address out of "Nodes" and tried again and it sent the Accept message again. So I tried a different device that I hadn't added before, and it got accepted as well. Is there somewhere I have to configure the conditions for it to send back a Reject message? I'm also getting an error when trying to start debugging. Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 0x1000105f (1.0.1e release) (in range 1.0.1 release - 1.0.1t rele) Has anyone else encountered this? -- Matt Fogleman Network Technician Unionville-Chadds Ford School District (o) (610) 347-0970 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<https://linkprotect.cudasvc.com/url?a=https://Slashdot.org&c=E,1,ZuIlSdKDzcG9MeyeaZU0g_sTRetVx7ox44Zillzgd_QYh06SXQux6EOVD7OUQ6ne2oMulBKKIHthE_VKdDiXvKOPE4e-qSJHNIOSM4iGDs3T18cV561JX3QJ&typo=1>! http://sdm.link/slashdot<https://linkprotect.cudasvc.com/url?a=http://sdm.link/slashdot&c=E,1,LZg9XqvjBmhirgrEMOjDbHOW3DxyqvZDn9XS0Mt5VdZtZAqXzoN2JFvHu4zD-eMlSG7_JzIxqcFkpjna14uexyLCsAdzZJ6MHLuC3mY,&typo=1> _______________________________________________ PacketFence-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/packetfence-users -- Fabrice Durand [email protected]<mailto:[email protected]> :: +1.514.447.4918 (x135) :: www.inverse.ca<https://linkprotect.cudasvc.com/url?a=http://www.inverse.ca&c=E,1,uYjcnRPETfowTOn17pZlwJbrD2E2fo5JpIGoi200YDy_2nDgQIAZQx2U80UfMFQDcDONkhzydqUdWCMCLpOoqLJfq9iPH3ZTMxGWeS1dK5U,&typo=1> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu<https://linkprotect.cudasvc.com/url?a=http://www.sogo.nu&c=E,1,Gm7t-itAvsZQsxUp8W9RQOiJaqglSV_Dj0jqDiIJWt5LLeIwWrQ-H9o63PhiPS2TJgf5OwKYLXSpsa1Uvddwby2kC-ffgwy5DjcqdYqAlOH6LyTeZqY,&typo=1>) and PacketFence (http://packetfence.org<https://linkprotect.cudasvc.com/url?a=http://packetfence.org&c=E,1,pe1X9i4Y8D9gUO2QsxvdXkhQ0P2nVnDm-njBcQdr0gJcsKML5MYeCC3RRCfo-Mxku3gHyo1-89TAYX-xhnfl8Gj_gaXoYvXIrJ_MweZpOuDC&typo=1>) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
