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:
- 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").
- 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.).
- 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.
Best Answer
I actually have this exact setup on my network. All you need to do is add each AP as a "Trusted RADIUS Client" in NPS and configure the other settings as you see fit. On the UniFi, just add the correct information (IP and secret) for it to start working.
When connecting with Windows clients at least, you'll need to configure each one to not validate the server certificate if you don't have a trusted certificate installed or association will fail.