We've used the wizard for years, and we're in pilot mode with the ES, and 
EAP-TLS right now.  We use the ES for onboarding with PacketFence/FreeRADIUS 
doing the back-end authentications/NAC quarantine.  We support both PEAP and 
EAP-TLS at the moment.

So far the experience has been positive.  We've seen a couple of issues with a 
corrupt cert store on Android -fixed by re-onbaording.  It would be nice if 
Google would implement profiles for Android more like iOS or even Chrome OS 
have.  The guest options with SMS are really nice/flexible too.  We also use 
the guest sponsoring capability in case a guest does not have cell coverage to 
self-onboard.  The ability to offer a self-onboard choice to long term 
vendors/contractors for WPA2-Enterprise is handy as well.

I'd like to see Cloudpath add some permission level views to the admin console 
(like read-only for helpdesk).  As far as I can tell it's all or nothing right 
now.

Thanks,

Curtis Larsen
University of Utah
Network Engineer III

________________________________________
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Frank Sweetser [f...@wpi.edu]
Sent: Thursday, March 12, 2015 6:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cloudpath ES4

We've always been some form of certificates (well, before that we were
WEP...).  We wanted to avoid PEAP to make sure that we didn't encourage users
(students in particular) to leave their username and passwords lying around on
devices.

Cloudpath did a pretty good job in articulating why they believe EAP-TLS
produces a better overall user experience when compared with PEAP:

http://techfieldday.com/appearance/cloudpath-networks-presents-at-wireless-field-day-6/

The one black spot on EAP-TLS I will warn you of is android devices.  The
android certificate store is opaque, and fragile.

The opaque part is that from the perspective of a user, and most applications,
it's a one way black box.  You dump certificates in, but there does not appear
to be any way to enumerate the user certificates installed, only the CA list.
  Recent versions of the XpressConnect app will display a list of certificates
that it believes it has installed, but I don't know of any good way to verify
or look for what other certificates are present.

The fragile part is even more exciting.  Android itself requires a "secure"
screen lock before it will store certificates, and not all screen lock types
meet this criteria.  If you play around with your screen lock settings after
loading certificates, we've seen cases where the store is locked and/or
corrupted, sometimes to the point where the phone has to be factory defaulted
to fix.

Overall, though, using certificates on the vast majority of devices with good
solid support for them has worked out very well for us.

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 3/11/2015 7:16 PM, Jason Cook wrote:
> HI Frank,
>
> Great, thanks for detailed feedback.. Sounds worth a trial at the very least.
>
> That covers most of our questions for the moment, did you migrate from a 
> PEAP/MsCHAP environment when moving to cloudpath?  If so was it a better 
> experience for users?
>
> Regards
>
> Jason
>
> --
> Jason Cook
> The University of Adelaide, AUSTRALIA 5005
> Ph    : +61 8 8313 4800
>
> -----Original Message-----
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Frank Sweetser
> Sent: Wednesday, 11 March 2015 2:08 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Cloudpath ES4
>
> Hi Jason,
>
>     we've been on ES3 for a while now, and are planning on moving to ES4 in 
> production this week.  First, your questions:
>
>    - We've been exclusively on EAP-TLS fore wireless since before we moved to 
> Cloudpath, and it's worked on very well.  The multiple certificate templates 
> and workflows give you quite a bit of flexibility in who gets what (different 
> CAs for student vs staff, different expiration period, etc).  The server acts 
> as an OCSP responder, so you can easily revoke any specific certificates, 
> allowing you to knock a single device offline rather than all devices owned 
> by a given user.  In addition, it can also use the OCSP checks to track 
> certificate usage, and send out notices to users who are actively using 
> certificates coming up on expiration in the near future.
>
> If you have other registration systems, you can also trigger a server side 
> HTTP callout on certificate issuance.  We have this as a tie in to our IPAM 
> system, automating that portion of it completely and allowing our users to 
> skip several steps.
>
>    - We haven't gone live on Cloudpath based guests, but have mocked it up in 
> the lab, and it should work.  While I don't believe they have a whole lot of 
> explicit guest functionality, the workflows are flexible enough that you can 
> still accomplish a lot.  If you can have temporary guest credentials set up 
> in your upstream authentication source with appropriate group memberships, 
> you can easily flag them in Cloudpath for special treatment - for example, 
> you can have long term guests set up with 90 day certificates for 
> authentication.
>
>    - Their features on this look pretty good, but we haven't used them at all.
>
>    - Ditto - we're currently using freeradius with a custom tie in to our 
> IPAM system, but are seriously looking at Clearpass to replace it in the near 
> future.
>
> Two other caveats I'll mention for free:
>
>    - The ES system includes a complete from-scratch rewrite of the wizard, so 
> it won't be the same one you're used to.  The initial releases didn't have 
> all of the same functionality as the cloud hosted one, so while they've 
> promised full feature parity, I'd double check carefully that all of the 
> features you need are already implemented.
>
>    - The clustering functionality looks pretty cool, but read it carefully 
> and test, as it's still a newish feature with a lot of caveats.  Also, last 
> time I checked in order to take full advantage of it you'll need to front it 
> with a load balancer, as I don't believe it had any built in service failover.
>
> That said, we've been very happy with ES3, and ES4 has done well in our 
> testing.  We're especially looking forward to it, as we currently have a 
> SHA-1 certificate rolled out, and ES4 now includes a method of converting 
> your CA to
> SHA-2 in-place without invalidating any of your currently issued identity or 
> server certificates.  We expect this to become a critical feature for us when 
> Microsoft follows through on their threats to stop honoring any SHA-1 CAs, 
> currently scheduled at the end of this year.
>
> Feel free to let me know if you have any other questions.
>
> 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 3/10/2015 11:20 PM, Jason Cook wrote:
>> HI,
>>
>> We've been using XpressConnect Wizard for a number of years quite
>> happily but haven't ever made the moved to ES. Just wondering what the
>> experience is for others with using  ES.
>>
>> In particularly
>>
>> ·if you have moved to EAP-TLS over PEAP-MS-CHAP (or running both)
>>
>> ocert management work ok?
>>
>> oAre user password changes as trivial as it seems they should be
>>
>> ·using sponsored approval for guest access
>>
>> ·PSK/MAC access lists for non dot1x devices.
>>
>> ·Used the internal radius server
>>
>> Regards
>>
>>
>> Jason
>>
>> --
>>
>> Jason Cook
>>
>> Technology Services
>>
>> The University of Adelaide, AUSTRALIA 5005
>>
>> Ph    : +61 8 8313 4800
>>
>> e-mail: jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au
>> <mailto:jason.c...@adelaide.edu.au%3cmailto:jason.c...@adelaide.edu.au
>>>>
>>
>> CRICOS Provider Number 00123M
>>
>> -----------------------------------------------------------
>>
>> This email message is intended only for the addressee(s) and contains
>> information which may be confidential and/or copyright.  If you are
>> not the intended recipient please do not read, save, forward,
>> disclose, or copy the contents of this email. If this email has been
>> sent to you in error, please notify the sender by reply email and
>> delete this email and any copies or links to this email completely and
>> immediately from your system.  No representation is made that this
>> email is free of viruses.  Virus scanning is recommended and is the 
>> responsibility of the recipient.
>>
>> ********** 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/.

Reply via email to