Failure to work on an SSID they can (barely!) see is often what brings them to
my door in the first place =)
Running cable and addition additional APs is outside of our budgetary scope on
the greek houses, so unfortunately that kind of fine tuning is rarely an
option anyway.
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 02:37 PM, Jeffrey D. Sessler wrote:
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/.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
