Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We're deploying a wireless networking using Windows Server 2008 NAC as a RADIUS server. When Windows XP or 7 clients connect they initally fail to connect.

In order to enable the client to connect we have to add the network manually and un-check the "Validate server certificate" as shown in the screenshot below.

Does anyone know of a way to avoid having to do this? We are perfectly willing to buy a certificate from Verisign, Thwarte, etc if it will help but have tried our Comodo wildcard SSL certificate which hasn't fixed it.

These machines belong to the end users so we can't easily control settings with group policy or registry hacks.

enter image description here

share|improve this question
    
Do you mean authenticating for when a user is logged on, or computer authentication regardless of a user is logged on or not? –  Greg Askew Jul 12 '12 at 22:58
    
This is a classic bring-your-own-device network, think university halls of residence. The user will be logged in locally when they click connect. Ideally they should then provide their network credentials at connection time and be seamlessly connected. –  Jona Jul 13 '12 at 7:20
    
Sounds like user auth. The reason I ask is it's possible for computers to authenticate and connect, regardless if there is a user logged on or not. –  Greg Askew Jul 13 '12 at 14:23
    
Ahh OK. I see the problem. Please see my edit in response. Securely doing BYOD is tricky but not impossible. –  kce Jul 13 '12 at 19:37

2 Answers 2

You need to distribute your RADIUS server's certificate (if it was self-signed) or the certificate of the Certificate Authority that signed it to your clients.

Right now you are telling your clients (or supplicants in 802.1X-ese) to verify the the trust path of your RADIUS server's certificate. I don't know how you generated your public and private key-pair for your RADIUS server but generally speaking it will either be self-signed or signed by a certificate authority. In turn the signing certificate authority's public key will be distributed to clients, either through GPOs, Active Directory Certificate Services or it was included by Microsoft in the Trusted Root Certification Authority repository.

Does anyone know of a way to avoid having to do this? We are perfectly willing to buy a certificate from Verisign, Thwarte, etc if it will help but have tried our Comodo wildcard SSL certificate which hasn't fixed it.

It's not a recommended configuration to have a external root CA sign your RADIUS server's certificate.


This is from the FreeRADIUS documentation but I expect it is equal valid for the Microsoft implementation:

In general, you should use self-signed certificates for 802.1x (EAP)
authentication. When you list root CAs from other organizations in
the "CA_file", you permit them to masquerade as you, to authenticate
your users, and to issue client certificates for EAP-TLS.



These machines belong to the end users so we can't easily control settings with group policy or registry hacks.

Well there's your problem! It is easy enough to distribute certificates using GPOs. Why is this not an option in your case? Baring that, do your own star certificate (that is signed by a Root CA), you could sign your RADIUS server's certificate with?


EDIT: Unfortunately, BYOD and WPA2-Enterprise are not really designed to go together. You have three options:

  1. Configure your clients to not check the trust path of your RADIUS server's certificate (i.e., uncheck the box that says "validate server certificates").
  2. Get your RADIUS server's certificate signed by a "External" CA whose signing certificate is distributed in Trusted Root Certification Authority repository (like Verisign, Comodo, etc.).
  3. Setup some kind of captive portal that acts as the supplicant on behalf of your clients.

The disadvantages of the first two options is that it opens your 802.1X scheme up to MiTM attacks. I could conceivably build my own RADIUS server and intercept your user's AD credentials. Not an ideal setup but your department will need to do the risk analysis. If you do go this route, make sure you document for CYA purposes.

From a security standpoint the best option is setup a captive portal. Students can use their BYOD devices to connect and reach the portal, pass their user authentication credentials to the portal and the portal can then talk to the RADIUS server.

Eduroam is another popular choice for educational organizations.

share|improve this answer

I just deployed a setup very similar to this last week, to provide Internet access to a week-long campground event. This is the approach I used and some lessons learned:

First, I used multiple SSIDs to provide the primary network on WPA2-Enterprise, and an open network for user enrollment. The open network redirects to a custom captive portal (using HTTPS and a normal certificate issued by a CA) where users signed up and provided payment information. After payment is complete, users are enabled in the RADIUS database, and can then reconnect to the WPA2-Enterprise SSID to get online.

Since I had a hard deadline to get it up and running, it was only tested with Android and iOS, neither of which had any real problem. In production I learned pretty quickly that Windows didn't like it at all.

  • Windows XP needed SP3 to use the secure network at all, so I kept a local copy as a direct download on the captive portal. One user actually showed up with XP SP2 and had to be updated.
  • Windows XP, Vista, and 7 refused to connect with the username and password, but never actually complained specifically about the server certificate. I discovered that this was the cause by trial and error with the first Windows user to sign up. Actually manually setting up the network profile was pretty straightforward once the issue was identified.
  • Windows 8, iOS, and the GNOME/Ubuntu version of NetworkManager prompted about the RADIUS server certificate, but allowed users to accept the certificate and connect.
  • The KDE version of NetworkManager never attempted connection without manual configuration, and the defaults it chose were wrong. Fortunately only one user showed up with this specific configuration.
  • No one requested support for Mac OS X. Either nobody was using a Mac, or they had no issues.

To avoid all this trouble, in the next iteration (i.e. next year) I plan to offer to install the server certificate directly from the captive portal, so that users (mostly Windows users) won't have an issue logging into the secure network.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.