RE: [WIRELESS-LAN] google play ACL

2015-05-30 Thread Curtis K. Larsen 
We have the same problem using Cloudpath and Cisco WLC's with a PacketFence 
Guest Captive Portal.  I am looking at a different approach though because like 
Ryan said - it will be a constant battle updating the ever-changing ACL's.  
This is a battle we will lose.
 
I'm trying to see if I can have PacketFence change the Pre-auth ACL to the 
Post-auth ACL just before the page where the user is presented with the play 
store download.  Essentially, the idea is that once they realize they can't get 
out - they start using the onboarding process, and then at the last page when 
they click "continue" it takes them to the app download, but also the 
"continue" button initiates the change from Pre-auth to Post-auth ACL allowing 
them to get to everything.

So at that point yes a user could get out, but my bet is that they are not 
interested in trying to get out - they are just trying to complete the 
onboarding process now.  If it works on the first try they'll stick with it - 
if not, they'll go for the guest network anyway before ever submitting a ticket 
and letting us know we have to add yet another URL to the Pre-auth ACL .  Also, 
since we already recorded their username, voucher or phone number in the 
onboarding process, if they do get out at least they are not anonymous.  We 
know a few things about them and can contact them.  Plus they'd have to go 
through the same annoying process every 24 hours if they really wanted to abuse 
the system.

In short, I'd rather have a process that works every time for users that follow 
it than have one that fails often so users choose not to follow it.


Curtis Larsen
University of Utah IT/CIS
Sr. Network Engineer


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Bruce Curtis 
[bruce.cur...@ndsu.edu]
Sent: Saturday, May 30, 2015 6:28 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] google play ACL

  We have the same problem.  I plan to give up on trying to keep track of the 
various things that need to be allowed.

  As part of the process to have a cert generated and downloaded our users have 
to log into a web page.  I plan to only allow access to the Internet after they 
have logged in to the web page.  To discourage using this method to access the 
Internet rather than configuring WPA2 on their device we will have a short 
timeout so that they would have to enter their ID and password every X minutes. 
 In addition the device we are using to redirect to our web page makes it 
fairly easy to block access to Facebook and Twitter etc.

On May 29, 2015, at 9:25 AM, Jacob Bennefield  
wrote:

> We have been working with Ruckus and Cloudpath on this issue as well.  These 
> are the web addresses we allow to make google play and a few other things 
> accessible.  You basically have to open up everything to google but google.com
>
> 2  ocsp.digicert.comEditClone
> 3  crl3.digicert.com   EditClone
> 4  crl4.digicert.com   EditClone
> 5  *.play.google.com   EditClone
> 6  *.ssl.gstatic.com   EditClone
> 7  *.android.clients.google.com EditClone
> 8  *.googleusercontent.com   EditClone
> 9  *.ggpht.com  EditClone
> 10   *.geotrust.com EditClone
> 11   *.appengine.google.com EditClone
> 12   *.settings.crashlytics.comEditClone
> 13   *.googleapis.comEditClone
> 14   *.cloud.google.comEditClone
> 15   *.gvt1.com EditClone
> 16   *.android.com  EditClone
> 17   passwordreset.lamar.eduEditClone
> 18   *.amazon.com  EditClone
>
>
>
> Jacob Bennefield, BBA
> Manager of Network Services
> Lamar University
> jacob.bennefi...@lamar.edu
> Phone: 409-880-7997
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
> Sent: Friday, May 29, 2015 9:01 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] google play ACL
>
> Hello all,
>
> I’ve asked this question in the past, got some answers, attempted to 
> implement some solutions, and have ultimately been disappointed with the 
> results…
>
> Our problem:  We have a limited access onboarding SSID.  Currently, users 
> must download the cloudpath agent directly from OUR server, requiring them to 
> configure their devices to allow non google market place applications.  I am 
> attempting to streamline the onboarding process by allowing access to

Re: [WIRELESS-LAN] google play ACL

2015-05-30 Thread Bruce Curtis 
  We have the same problem.  I plan to give up on trying to keep track of the 
various things that need to be allowed.

  As part of the process to have a cert generated and downloaded our users have 
to log into a web page.  I plan to only allow access to the Internet after they 
have logged in to the web page.  To discourage using this method to access the 
Internet rather than configuring WPA2 on their device we will have a short 
timeout so that they would have to enter their ID and password every X minutes. 
 In addition the device we are using to redirect to our web page makes it 
fairly easy to block access to Facebook and Twitter etc.

On May 29, 2015, at 9:25 AM, Jacob Bennefield  
wrote:

> We have been working with Ruckus and Cloudpath on this issue as well.  These 
> are the web addresses we allow to make google play and a few other things 
> accessible.  You basically have to open up everything to google but google.com
>  
> 2  ocsp.digicert.comEditClone
> 3  crl3.digicert.com   EditClone
> 4  crl4.digicert.com   EditClone
> 5  *.play.google.com   EditClone
> 6  *.ssl.gstatic.com   EditClone
> 7  *.android.clients.google.com EditClone
> 8  *.googleusercontent.com   EditClone
> 9  *.ggpht.com  EditClone
> 10   *.geotrust.com EditClone
> 11   *.appengine.google.com EditClone
> 12   *.settings.crashlytics.comEditClone
> 13   *.googleapis.comEditClone
> 14   *.cloud.google.comEditClone
> 15   *.gvt1.com EditClone
> 16   *.android.com  EditClone
> 17   passwordreset.lamar.eduEditClone
> 18   *.amazon.com  EditClone
>  
>  
>  
> Jacob Bennefield, BBA
> Manager of Network Services
> Lamar University
> jacob.bennefi...@lamar.edu
> Phone: 409-880-7997
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
> Sent: Friday, May 29, 2015 9:01 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] google play ACL
>  
> Hello all,
>  
> I’ve asked this question in the past, got some answers, attempted to 
> implement some solutions, and have ultimately been disappointed with the 
> results…
>  
> Our problem:  We have a limited access onboarding SSID.  Currently, users 
> must download the cloudpath agent directly from OUR server, requiring them to 
> configure their devices to allow non google market place applications.  I am 
> attempting to streamline the onboarding process by allowing access to google 
> play directly to download the onboarding application, but am failing 
> miserably…  I have put up the white flag and opened up most of google, but 
> now I am finding that through a combination of cache servers, and Samsung 
> devices that appear to query for their own app store first, my results work 
> only half the time.
>  
> Has anyone else figured out a way to solve this madness?  We are not going to 
> open up the SSID to everything, because people would just use it and not the 
> proper wireless.
>  
>  
> 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/.
> 
> 
> CONFIDENTIALITY: Any information contained in this e-mail 
> (including attachments) is the property of The State of Texas and 
> unauthorized disclosure or use is prohibited. Sending, receiving or 
> forwarding of confidential, proprietary and privileged information is 
> prohibited under Lamar Policy. If you received this e-mail in error, 
> please notify the sender and delete this e-mail from your system.
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/groups/.

---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: google play ACL

2015-05-30 Thread Osborne, Bruce W (Network Services) 
You do not need all of amazon.com. Kindle tablets need access to the Amazon App 
Store and they access it differently than other Android devices.

We restrict by DNS & ip ranges. I thought I remembered some YouTube access 
needed for Google Play Store too for graphics & videos.

I will need to post our setup later, after I gather the data.​

Bruce Osborne
Wireless Engineer
IT Infrastructure & Media Solutions

(434) 592-4229

LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Coehoorn, Joel [mailto:jcoeho...@york.edu]
Sent: Friday, May 29, 2015 2:40 PM
Subject: Re: google play ACL

Wow. All of Amazon, too? I'm sitting on the outside of this process looking in, 
hoping to do something like this before the end of the summer, and that ACL is 
depressing.



[Image removed by sender.]


Joel Coehoorn
Director of Information Technology
402.363.5603
jcoeho...@york.edu



The mission of York College is to transform lives through Christ-centered 
education and to equip students for lifelong service to God, family, and society

On Fri, May 29, 2015 at 1:37 PM, Turner, Ryan H 
mailto:rhtur...@email.unc.edu>> wrote:
Thank you, Jacob.  Looks like I may have to go this route as well.

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

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
 On Behalf Of Jacob Bennefield
Sent: Friday, May 29, 2015 10:26 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] google play ACL

We have been working with Ruckus and Cloudpath on this issue as well.  These 
are the web addresses we allow to make google play and a few other things 
accessible.  You basically have to open up everything to google but 
google.com

2  ocsp.digicert.com  
  EditClone
3  crl3.digicert.com  
 EditClone
4  crl4.digicert.com  
 EditClone
5  *.play.google.com
   EditClone
6  *.ssl.gstatic.com
   EditClone
7  
*.android.clients.google.com EditClone
8  
*.googleusercontent.com   EditClone
9  *.ggpht.com  EditClone
10   *.geotrust.com EditClone
11   
*.appengine.google.com EditClone
12   
*.settings.crashlytics.comEditClone
13   *.googleapis.com
EditClone
14   *.cloud.google.com
EditClone
15   *.gvt1.com EditClone
16   *.android.com  EditClone
17   
passwordreset.lamar.eduEditClone
18   *.amazon.com  EditClone



Jacob Bennefield, BBA
Manager of Network Services
Lamar University
jacob.bennefi...@lamar.edu
Phone: 409-880-7997

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
Sent: Friday, May 29, 2015 9:01 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] google play ACL

Hello all,

I’ve asked this question in the past, got some answers, attempted to implement 
some solutions, and have ultimately been disappointed with the results…

Our problem:  We have a limited access onboarding SSID.  Currently, users must 
download the cloudpath agent directly from OUR server, requiring them to 
configure their devices to allow non google market place applications.  I am 
attempting to streamline the onboarding process by allowing access to google 
play directly to download the onboarding application, but am failing miserably… 
 I have put up the white flag and opened up most of google, but now I am 
finding that through a combination of cache servers, and Samsung devices that 
appear to query for their own app store first, my results work only half the 
time.

Has anyone else figured out a way to solve this madness?  We are not going to 
open up the SSID to everything, because people would just use it and not the 
proper wireless.


Rya