7

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

Jona
  • 746
  • 1
  • 9
  • 17
  • 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 07: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. –  Jul 13 '12 at 19:37
  • It appears that the SubjectAltName entry of the certificate must be set to the DNS used to reach the radius server. I would take that to mean that you cannot use a direct IP address to get at your radius server, less the certificate not be able to validate. https://technet.microsoft.com/en-us/library/cc731363(v=ws.10).aspx – Brain2000 Feb 17 '16 at 16:30

3 Answers3

7

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.

0

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. I later learned that Mac OS X clients connected with no problems.

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
0

I know this post is really old, however, this is similar to my issue except that last week, any client could connect to my wireless network and this week they can not. I have a Aruba EOL 3200 with 8 access points. The windows/android/iphone clients were able to connect with 802.1x verifying against a local, Aruba based database of one user name. This week when I get in, I notice that my phone can not connect to the wireless. Then my Windows 10 laptop could not connect (both have connected before). Only clients that have not disconnect from the network were still able to access it. This only happens with the 802.1x ssid (staff) and not with the PSK ssid (for guests). I then verified that the only way for a windows computer to connect to this is to uncheck the "verify the server's identity by validating the certificate" option while manually adding the profile. Android devices are still unable to connect.

iceman3k
  • 1