Assuming PEAPv0 is used, this is expected behavior when you're using a
private PKI (Microsoft CA for example) as the client won't trust the
private CA unless you've used a method to get the private PKI root
certificate to the client.
In enterprise environments you've got group policy to do this for you
(by default no less).
In education if you don't have clients on the domain I can't see why you
wouldn't purchase a server-side certificate from a public PKI CA. Your
clients *should* trust this CA already and shouldn't be prompted. You
would want to verify that the bulk of the clients types you support do
in fact contain the root CA certificate of whichever CA you purchase
from; some CA's are pretty crap in this regard.
On 17/04/13 9:13 AM, Jason Cook wrote:
Vote 2 for cloudpath, we have found the software to be extremely
helpful in configuring, updating and troubleshooting clients.
As already stated this is expected behaviour. Like most IT Security
"pains" the best approach is good communication & documentation to set
user expectations and educate why it is important. One day it will
feel normal like locking the doors of your house to protect assets.
--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph : +61 8 8313 4800
*From:*The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]] *On Behalf Of *Williams,
Mr. Michael
*Sent:* Wednesday, 17 April 2013 4:11 AM
*To:* [email protected]
*Subject:* Re: [WIRELESS-LAN] Verifying or Validating Server
Certificate when using WPA/WPA2 and 8021x WLAN
Thanks Lee. I am going to take a look at Cloudpath.
mike
*/Michael M. Williams/*
Network Systems Analyst
Information Technology Services
Tarleton State University
201st St. Felix Str.
Box T-0220
Stephenville, TX 76402
Tel: (254) 968-1850
Fax: (254) 968-9393
[email protected] <mailto:[email protected]>
/Information Technology Services staff will never ask for your
password in an email. Don't ever email your password to anyone or
share confidential information in emails./
//
/Confidentiality Notice: This electronic message, including any
attachments, is for the sole use of the intended recipients(s) and may
contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message./
*From:*The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:[email protected]] *On Behalf Of *Lee H Badman
*Sent:* Tuesday, April 16, 2013 8:38 AM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [WIRELESS-LAN] Verifying or Validating Server
Certificate when using WPA/WPA2 and 8021x WLAN
We found Cloudpath ExpressConnect to be wonderful at setting things
like approved certs for the client- if you can get them to use it.
We have a great mechanism with a "Help" SSID that allows for initial
self-config, then self-remediation if you ever find your client not
behaving. Works so sweet... except that new OS X and Win 7 machines
also want to self-configure and onboard clients with just credentials
needed (like for MS-CHAP v2/PEAP) and so our help tool gets unused.
Expressconnect also lets you do things like disable IPv6, clear out
"extra" profiles that accumulate, and other nice tweaks along with
elegent cert handling.
*Lee H. Badman*
Network Architect/Wireless TME
ITS, Syracuse University
315.443.3003
------------------------------------------------------------------------
*From:*The EDUCAUSE Wireless Issues Constituent Group Listserv
[[email protected]] on behalf of Tim Cappalli
[[email protected]]
*Sent:* Tuesday, April 16, 2013 9:12 AM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [WIRELESS-LAN] Verifying or Validating Server
Certificate when using WPA/WPA2 and 8021x WLAN
This is definitely normal behavior. The only way to get around this
would be to configure the client to not verify the server certificate
which is a security risk and is not best practice.
The idea is that if someone threw up a rogue AP with the same SSID and
your users associated to it, they would receive a different
certificate prompt which should throw a red flag (unforuntely it
doesn't to college kids, they just click yes).
tim
Tim Cappalli*, *Network Engineer
LTS | Brandeis University
x67149 | (617) 701-7149
[email protected] <mailto:[email protected]>
On Mon, Apr 15, 2013 at 11:34 AM, Williams, Mr. Michael
<[email protected] <mailto:[email protected]>> wrote:
Our wireless network consists of a two Cisco wireless controller, 240
APs and we use Cisco ACS 5.2 as our RADIUS server. One of our
wireless networks is configured to use WPA/WPA2 with 802.1x and PEAP
w/ MSCHAP v2. After updating the server certificate on the ACS, our
wireless users were asked to verify or validate the server certificate
before gaining access to the wireless network. This requirement
generates numerous helpdesk tickets and many more questions as to why
the users must do this, when they don't have to do it on any other
wireless network. I have asked Cisco for assistance but they
informed me that what we are seeing is the normal behavior for the
wireless supplicants and that the user must manually verify the
authentication server certificate when a wireless profile is created
for the first time or after the server certificate is changed on the ACS.
I know we are not the only one seeing this requirements, numerous
other University have publish wireless tutorials asking their user to
verify the certificate as part of the initial setup of the wireless
profile. I know we can eliminate this requirement in Windows machines
by just unchecking the validate certificate option, but this is not an
option on iOS machines. We use the 3^rd party certificate by Incommon
and have install both intermediate and root certificate on the ACS.
Has anyone found a solution to this problem? Or is this just the
default behavior of the supplicant that we are seeing?
Thank you for your assistance.
mike
*/Michael M. Williams/*
Network Systems Analyst
Information Technology Services
Tarleton State University
201st St. Felix Str.
Box T-0220
Stephenville, TX 76402
/Information Technology Services staff will never ask for your
password in an email. Don't ever email your password to anyone or
share confidential information in emails./
//
/Confidentiality Notice: This electronic message, including any
attachments, is for the sole use of the intended recipients(s) and may
contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message./
********** 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/.
