802.1x automatically validate certificate in windows clients

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.

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.

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.