Jerry, I find some of your comments interesting. We have many things in common. We are also an Aruba wireless / ClearPass customer using PEAP-MSCHAPv2 & MAC Auth. Although we initially designed for full Cisco wired 802.1X we have been running a strange Cisco config that uses it somewhat but does not restrict unauthenticated devices.
We have been a CloudPath Wizard customer for years. Since this product has been deprecated, we are evaluating onboarding vendors. We have an engineer from a former government contractor who wants us to move to EAP-TLS. So far, we have found ClearPass Onboard licensing costs to be much higher than the other vendors. I have been having a big challenge on how to configure 802.1x (likely PEAP-MSCHAPv2 or EAP-TLS) for Computer Lab computers that can have many new users. We are currently doing User auth for MacOS but that requires an initial logon on wired to get the user profile stored locally. I have tried using MacOS Logon profile but I find if a user typoes their password that although they are prompted for a new password, the system still tries to use the old one during that time and locks the user account ☹ What are people here doing for 802.1X and MacOS Labs? We are seeing a trend for wireless Labs with dedicated APs & SSID for the machines because the cost is much less than having a network drop per machine. Our current wireless MacOS Lab was implemented last summer with a PSK as a temporary workaround. We definitely need to move away from that. Windows handles 802.1X much better, IMHO. Bruce Osborne Senior Network Engineer Network Operations - Wireless (434) 592-4229 LIBERTY UNIVERSITY Training Champions for Christ since 1971 From: Bucklaew, Jerry [mailto:j...@buffalo.edu] Sent: Thursday, August 10, 2017 3:36 PM Subject: Re: EAP-TLS Lee, I want to state first that I am not, by any means, an expert on all of the authentication standards and protocols. I was hoping someone would have a document that would help better articulate the goals and benefits. We have been a eap-peap shop for years and I have always been told that eap-tls (cert based authentication) is more secure and you should do that. I never had the time to deal with it and putting up a cert based infrastructure just seemed daunting. I finally have some time and have started to play with it. We are an Aruba shop and the clearpass Onboard system seems pretty simple to implement and get EAP-TLS working. Now to the why. It seems that the ability to separate username/password from network authentication has some benefits. If a user changes his username/password it no longer affects his network connectivity. If we want to blacklist a device it will be easy as each device will have its own cert. So we can blacklist one device and let the rest still on. We could do those things today but it is just a little harder to do with eap-peap. We can also get users out of storing their usernames and passwords, because everyone does it with eap-peap. The thought process went, if you are going to run an on-board process anyway, why not onboard with eap-tls. On the wireless side that is really all I have. I have always been told it is more secure so have always thought I should try and get there. Now, we are also moving to wired authentication on every port. We are supporting both mac auth and 802.1x (eap-peap). We did this to get the project moving and get all ports to some type of authentication. Now 802.1x on the wired side is just plain difficult. Nothing except macs are setup for it out of the box. You need admin rights on the machine to set it up (which many people on the wired side don’t have) and you almost have to run through some type of onboard process to do it in mass. You have to deal with stuff like network logons and mounting drives before authentication. We also don’t want the users storing usernames and password and everyone will because no one wants to type it in every time. I am back to the if you are going to run through an onboard process anyway, will certs make it a little easier. It gives you the username/password separation. The ability to revoke per device, and once onboarded, never have to be bothered again (until the cert expires). I am not really concerned about peap being deprecated, it will be around forever. I am not really concerned about usernames and passwords being stolen because of eap-peap, there are so many easier ways to do that. It guess it is really the username/password separation and the “thought” that it is the most secure method. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Thursday, August 10, 2017 3:00 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] EAP-TLS Jerry, Am curious your reasons for TLS, like if anything beyond "it's better". Concern for PEAP being deprecated, etc? Lee -----Original Message----- From: Bucklaew, Jerry [j...@buffalo.edu] Received: Thursday, 10 Aug 2017, 14:42 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] Subject: Re: [WIRELESS-LAN] EAP-TLS To ALL: We currently do mac auth and EAP-PEAP authentication on our wireless network. I am trying to put together a proposal to move to cert based authentication and I was wondering if anyone has a proposal or justification already written as to why you should move to cert based auth? Just trying to save myself some typing. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.