Since we are on the topic of guest access and EAP-TLS I would like to inform eduroam connectors in the US that they can test a guest service available at www.eduroam.us <http://www.eduroam.us/> (it is a pilot program… feedback welcome) It is called ANYROAM and allows schools connected to eduroam to let their visitors be configured with an EAP-TLS certificate good for one year and to join the eduroam network at locations accepting ANYROAM credentials. It doesn’t violate the trust of eduroam since each school (SP, Service Provider) decides independently if they want to allow identities of the form *@anyroam.net <mailto:form*@anyroam.net> to access their network (there is a radio button under “enable ANYROAM” when you access Admin Login at www.eduroam.us)
We have an automatic installer that will configure devices with an EAP-TLS cert (We still have a little problem with Android devices but it should be fixed soon) WARNING: the profile is designed for devices/users without eduroam access and it takes over existing configurations…you will have to delete the ANYROAM profile after your testing is completed and reconfigure your device to access eduroam again. Best, Philippe p.s. If you want to test this service from another eduroam federation/country, let us know …we can can find a solution Philippe Hanset www.eduroam.us > On Sep 22, 2015, at 5:29 PM, Frank Sweetser <[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/.
