SMUS Wireless Configuration

Introduction

This page will discuss the backend for the SMUS wireless configuration.

Prerequisites

Our requirements for wireless on campus are fairly complex. We decided on several prerequisites, for a variety of reasons.

802.1x

We wanted staff and students to be able to sign into the wireless system themselves without any help from the MIS department. Several implementations use a captive portal mechanism to do this, but that results in an SSID with no encryption. By using 802.1x, we can use WPA2-Enterprise encryption on the SSIDs, and staff and students can still configure the connection themselves.

Active Directory Integration

Wherever possible, we have staff and students use their active directory credentials to log into whatever they're trying to access. We wanted this system to also use the active directory credentials. The AD server had preexisting groups we wanted to take advantage of as well, and we added more groups later to further separate out our users.

Different Student and Staff IP addresses

Students on our campus are subject to bandwidth limitations and packet shaping. We do not want to apply these restrictions to staff members. Our packet shaper uses a simple IP range to track which machines to apply restrictions to, so we needed our students to be assigned a different set of IP addresses than our staff.

VLANs for mobile labs

Our mobile laptop labs also need different IP ranges. As we have a senior and middle school, we apply different web filtering to each set of computers. We achieved this using VLAN assignments in freeradius after the machines logged in, based on a regular expression check on the computer name.

Single simultaneous login for students

Our students are limited to one simultaneous wireless connection. This is to discourage password sharing (one student using another student's account will then stop the original student from being able to log in). As different grades have different access times, we didn't want grade 12 students sharing their credentials to students in lower grades. This is also potentially a bandwidth saving measure, as a single student can't have their iPod, iPhone, computer, etc. clogging up the same access point simultaneously. Again, these restrictions do not apply to staff.

Login times by grade

We apply different login hours by grade. Grade 12s can use the wireless longer into the evening than grade 11s, which can use it longer than grade 10s, etc.

Guest logins

As there are frequently parents and other guests on campus, we wanted it to be fairly simple for them to get their wireless device onto our network. These devices are sometimes not as secure as other devices, so they are separated out onto their own network, and we check their computers for up-to-date antivirus protection through a captive portal before allowing them to login. Antivirus protection is not checked on smartphones and similar devices, only full computers.

Software Used

We use a combination of Freeradius (to do radius authentication and accounting), and Samba (for active directory integration) on the backend. The wireless access points are configured using the Meraki cloud controller, although other wifi systems can also tap into the same radius configuration (we tested with Dlink access points as well). Whatever wifi system is selected must support 802.1x authentication through WPA2-Enterprise encryption, as well as radius accounting packets (to track simultaneous logins).

Simultaneous logins are tracked using a MySQL database, although it should also be possible to use Postgres as Freeradius supports it. The automated scripts we run would need to be modified slightly to support Postgres.

Bug-free support for the functions we're using arrived recently to Samba and Freeradius, and older versions definitely don't work properly. We are running Debian 6 with the stock versions of all packages. We were previously running Ubuntu 10.04 and the versions included there did not work. Freeradius 2.1.10 and Samba 3.5.6 are included with Debian 6, so those are the recommended versions.

Our VLANs are routed through a PFSense 2.0.0 virtual machine. This VM can apply firewalls to any combination of subnet connections, and has good performance for the throughput we need. Routing and firewalling can also be done through a dedicated router.

Hardware Used

Our radius server runs as a VMWare ESXi 5.0 virtual machine. It has a single virtual processor (2.53 GHz) with 256 MB of ram. This is more than sufficient to handle our incoming connections. Our MySQL database server, which handles many other databases as well, has 4 virtual processors and 3 GB of ram.

We use Meraki MR16 access points.

Clients we have successfully authenticated on this network include Windows XP, Vista, and 7; Mac OS X; Android, Blackberry, and iOS smartphones; etc. Through MAC address whitelisting, we have also put other devices onto the guest network.