[unisog] Campus Wireless deployment models - 3 questions - feedback appreciated
randyneals at trentu.ca
Sat Feb 11 15:11:59 GMT 2006
> 1. Do you offer an "open access" wireless lan?
We do not provide open access, we require authenticated access only.
Everyone with an identity in our campus directory can authenticate to our wireless system.
We do plan to build a "sponsor a guest" system, but have not rolled that out as yet.
The concept is to allow a user in our campus directory, through a self service web form, to sponsor guest access for a specific visitor.
The visitor would still need a username/password, and that would allow us to track the guest through their sponsor.
We have student residences among the core campus buildings, so at any given time there are about 200 SSIDs floating around and several of those running with no authentication. We don't have an airspace policy, so that makes RF interference planning *very interesting*.
Most res room A/Ps appear to be LinkSys and they stay mostly on channel 11 which is the out of the box default.
> 2. If so do you required any sort of device registration and/or
> encryption? If your answer is no, how do you deal with potential legal
> risks from things like filesharing?
We recently launched wireless (last summer) and decided to deploy an 802.11i compliant system because we had a "greenfield" opportunity with no wireless legacy equipment/system to hold us back.
We were concerned about rogue A/Ps showing up faking our SSID, and setting up a fake web based login system on a rogue A/P to harvest usernames and passwords.
We are using WPA2 (Enterprise) with AES encryption. Authentication is PEAP-MS-CHAP to a radius server which is in turn synchronized to our campus LDAP (eDirectory).
Windows Client (supplicant) support is available in Windows SP2 with a WPA2 hotfix applied.
Mac Client support is in OS-X with an AirPort Extreme.
Because WPA2 is relatively new, not all existing wireless cards work. This is a small annoyance for students who have a notebook that is a couple of years old, with built in wireless, but can't access our wireless network because their notebook vendor has not provided updated wireless drivers that support WPA2 Enterprise. Add on cards solve this for older notebooks. Recent notebooks generally support WPA2. We are having good success with the windows and mac clients, and this means that we don't have to provide/license/support/patch/update add on wireless client software.
Overall, we are happy with this choice. The wireless security level is perceived to be greater than we actually need today, but this should mean that we won't need to "redesign" the system for a while. We are already seeing greater vendor support for 802.11i which is giving us greater confidence that this was a good direction to choose. In fact, this experience is causing us to contemplate deploying 802.1x on portions of our wired network. Classrooms and meeting rooms for example.
We don't track notebooks, nor do we pre-check or register notebooks on wireless. (We attempt to track devices on our wired campus network)
The authentication system logs user authentication activity, which includes MAC addesses.
WPA2 Enterprise changes enctyption keys every couple of minutes, on each A/P the client is associated, so we can track down a user fairly quickly should we need to by looking through the logs.
> 3. Do you offer varying levels of service on your wireless lan? For
> example - an "open access" wireless lan that offers only web browsing to
> non university resources, and a registration/WPA required wlan for student
> access etc?
Our wireless network is isolated from our campus network with a firewall.
Actually, the campus wireless, campus wired, and internet/research networks meet at our border router/firewall.
Because wireless was new (greenfield), we started with a deny-all firewall policy, and selectively open ports between wireless and the campus network, and between wireless and the Internet, upon request and after a security review.
We principally provide web and email access and promote our wireless as "wireless Internet access" rather than "wireless campus network access". The intent is to keep the number of ports lean because we have little control over the notebook, O/S, A/V and general security state of the wireless desktop.
We are working on a remote access VPN service to enable remote workers to access the campus network from home.
VPN will be deployed on a basis of individual demonstrated need, and only to employees. (faculty, staff, research assistants)
The goal of the remote VPN service is to enable further reduction in open ports on the campus wired-network to Internet firewall, but support special circumstances/requirements through VPN.
So, by offering VPN that will work via our campus wireless, we are essentially provided differentiated access between students and employees of the University. It is expected that almost all VPN clients will be university owned notebooks with our uniform desktop image, and managed through our desktop management system.
You didn't ask, but this is something that became apparent after we deployed wireless service...
Wireless for students is like a "virtual computer lab" where the students provide the computer, and we provide the network, the place to work, and in some places (library), we provide ac outlets and physical security rings to provide a place to attach a notebook security cable to.
Like a regular computer lab, wireless users also need to print.
We use Novell iPrint and Pcounter for conventional student lab printing, so we wanted to extend this functionality to wireless and not have two print systems for students.
So far so good.. We are working with a few students to beta test it. They can print to the hold queue, walk over to a pcounter release station, log in, and release their print job to the associated printer. This works for windows, but not for macs as we don't have an iPrint client for macs as yet.
Manager, Network & Security
1600 West Bank Drive
More information about the unisog