Frank, So one of the strategies here could be to have dense WiFi in the greek houses, but run them with all of the the lower data rates disabled, with your mandatory rate set very high e.g. 24 or 36 Mbps (in Cisco terms). Essentially, unless the neighbors are sitting on the porch of the Greek house, it’s unlikely they’d be able to associate.
Jeff On 9/22/15, 8:29 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv on behalf of Frank Sweetser" <[email protected] on behalf of [email protected]> wrote: >Guest wireless is an ongoing debate here, which pretty much means that any >answer I give now is not likely to be the same answer I'd give in six months =) > >One of the primary factors why we've pushed back on any kind of fully open >guest is that we are heavily intertwined with residentials areas. This is >especially true of our greek houses, which we offer wireless service in, as >they are just repurposed residential buildings not even on the main campus. >This means that if we offer any kind of overly open guest networking, we have >to account for anyone within radio distance attempting to use it. > >(This isn't hypothetical, either - several times a year we'll get people >asking for help getting on wireless, only to find out that they're half a >block away from the nearest building with our wireless in it. I don't even >know how these people's devices pick it up at all...) > >We've been very reluctant to become a neighborhood hotspot, and simply haven't >wanted to put in the extra time and effort necessary to walk the line between >convenience for guests, and easier than Charter for our unaffiliated >neighbors. Historically our guest wireless has been strictly via >pre-provisioned accounts, and we've intentionally avoided any kind of >self-service guest creation. We've recently moved onto Aruba Clearpass for >guest management, though, which gives us a lot more tools in managing guests, >so we're (very slowly) thinking about changing things. > >On the two factor point... well, we're currently planning to start planning >for a strong central identity management system. Until that's more or less in >place, I'd be very hesitant to try to do any real scale 2FA. Definitely on my >wish list if I'm ever kind of the university for a day, though =) > > >Also, back to the original question, I just remembered that the Cloudpath >folks did a similar presentation a while back at Wireless Field Day. > >http://techfieldday.com/appearance/cloudpath-networks-presents-at-wireless-field-day-6/ > >Frank Sweetser fs at wpi.edu | For every problem, there is a solution that >Manager of Network Operations | is simple, elegant, and wrong. >Worcester Polytechnic Institute | - HL Mencken > >On 09/22/2015 11:10 AM, Jeffrey D. Sessler wrote: >> Devil's advocate here... >> >> Why not adopt a system that allows guests to be easily on-boarded? I agree >> that sharing passwords is never desired, but why not make the barrier to >> getting a guest on WiFi easier? If it's easy to get a guest on, then user's >> will be less likely to share their credentials. In other words, rather than >> making the process of using WiFi harder for regular users (and >> administratively more difficult to manage), just eliminate (or rather >> embrace) the "girlfriend" problem. >> >> As for password sharing... It's going to happen. At best, you use 2-factor >> for those applications (and user roles) that demand it e.g. HR director >> logging into payroll, and recommend it for others e.g. general users logging >> into email, and then fall back to some form of appropriate use policy for >> users that have many "girlfriends." >> >> Jeff >> >> -----Original Message----- >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >> [mailto:[email protected]] On Behalf Of Frank Sweetser >> Sent: Monday, September 21, 2015 5:25 PM >> To: [email protected] >> Subject: Re: [WIRELESS-LAN] Help on a conference presentation on EAP-TLS >> >> I can at least share one of our primary motivations - what I refer to as the >> "girlfriend" problem. >> >> We all know that despite any warnings we can come up with, there are >> circumstances where students will share their passwords with others for >> network access, whether it's a boyfriend/girlfriend, family, or just a >> weekend guest. We've had it happen in our greek houses a few times, where >> the house itself is renting out a room to a guest completely unaffiliated >> with the university. >> >> Moving to EAP-TLS obviously doesn't stop this from happening, but it means >> that when they do share out their wireless credentials, they're at least not >> sharing their password to email, LMS, and everything else along with it. >> >> Frank Sweetser fs at wpi.edu | For every problem, there is a solution >> that >> Manager of Network Operations | is simple, elegant, and wrong. >> Worcester Polytechnic Institute | - HL Mencken >> >> On 9/21/2015 7:44 PM, David R. Morton wrote: >>> Ryan, >>> >>> I too would like to hear about your lessons learned across all the >>> areas you listed in your message. >>> >>> David >>> >>> >>> >>> >>> >>> David Morton >>> Director, Mobile Communications >>> Service Owner: Wi-Fi, Mobile & HuskyTV University of Washington >>> [email protected] <mailto:[email protected]> tel >>> 206.221.7814 >>> >>>> On Sep 21, 2015, at 4:40 AM, Osborne, Bruce W (Network Services) >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Will you be able to share at least part of this presentation on this list? >>>> I am sure some of us cannot attend but are looking to implement EAP-TLS. >>>> >>>> *Bruce Osborne* >>>> /Wireless Engineer/ >>>> *IT Infrastructure & Media Solutions* >>>> *(434) 592-4229* >>>> *LIBERTY UNIVERSITY* >>>> /Training Champions for Christ since 1971/ *From:*Turner, Ryan H >>>> [mailto:[email protected]] *Sent:*Friday, September 18, 2015 >>>> 9:55 AM *Subject:*Help on a conference presentation on EAP-TLS >>>> All: >>>> I am doing a presentation on lessons learned on converting to TLS for >>>> a UNC Cause next month. We have plenty of mistakes along the way to >>>> share with the people that will be listening, but I thought it might >>>> be fun for others to ‘fess up’ to their TLS screw-ups… For example, >>>> maybe missing on a technical point that would cause grief down the >>>> road, to adopting a policy change that in hind sight wasn’t the best. >>>> We will also cover how we have pivoted our onboarding platform from >>>> Cloudpath to SecureW2 and redesigned the method of onboarding to >>>> significantly reduce helpdesk calls. >>>> No one likes to admit mistakes, but that is why I like working in >>>> education… everyone can share. >>>> However, please feel free to share DIRECTLY with me. You don’t need >>>> to copy the list. Please give me permission to share in the email, >>>> and let me know if you want it anonymous, or if you want your >>>> screw-up properly creditedJ [email protected] <mailto:[email protected]> Ryan H >>>> Turner Senior Network Engineer The University of North Carolina at >>>> Chapel Hill CB 1150 Chapel Hill, NC 27599 >>>> +1 919 445 0113 Office >>>> +1 919 274 7926 Mobile >>>> ********** Participation and subscription information for this >>>> EDUCAUSE Constituent Group discussion list can be found >>>> athttp://www.educause.edu/groups/. >>>> ********** Participation and subscription information for this >>>> EDUCAUSE Constituent Group discussion list can be found >>>> athttp://www.educause.edu/groups/. >>> >>> ********** Participation and subscription information for this >>> EDUCAUSE Constituent Group discussion list can be found at >>> http://www.educause.edu/groups/. >>> >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> > >********** >Participation and subscription information for this EDUCAUSE Constituent Group >discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
