Mike-
We use three SSIDs. We struggled with using an additional SSID for onboarding - but for us, it has been worth it; particualrly if you disable low data rates for beacons.
*HWS-Private is our PEAP/MSCHAPv2 SSID
*HWS-Public is an Open Auth SSID with Captive portal "click to accept terms" button. Not perfect but annoying enough to keep Students going to the HWS-Private SSID instead of staying on the Authed SSID and guests from just autoconnecting all the time.
*HWS-Get-Connected is our Open Auth with Captive Portal SSID. We use DHCP fingerprints to steer clients to a Captive portal unique to their platform (as close as we can get) or fallback to a "generic" Captive portal. The user profile has no access to anything but the CP. In all plaforms , the initial captive portal pages have two buttons: "Guests/Visitors" and "Student/Facuty/Staff". Each button is a link to instructions to connect for their platform/faqs or an onboarding tool which does supplicant configurations (including setting valid Radius server name/cert chain). If we registered devices, this SSID would be the natural place to put this.
It has worked pretty well for us. I suspect if we registered devices and/or had Clearpass, we could consolidate down to two SSIDs... but we don't at the moment.
I'm going to go on a tangent here thought: As Tim points out, it still doesn't protect us from the user connecting directly to the PEAP/MSCHAPv2 SSID and setting up a weak supplicant profile, not neccesarily validating the radius server. In this case it depends entirely on the default OS behavior. In the iOS case, I've found it stores the Radius *cert* (not name) with the wifi network config after the user "accepts" the installation of the cert (and if memory serves me, the cert will show as unverified regardless of the CA). Unfortunately, this means that when the Radius cert legitimately needs to be replaced if it is due to expire (or, you know... is a little Heartbleed-y) - the user will be prompted to accept a new copy of an updated certificate (and thusly prompted again). I see two things wrong here - a) the wireless profile is not actually validating the server by it's name - it's looking for an identical certificate as was installed when the wireless profile was set up by the OS supplicant. I *think* (call me out if I am wrong) MITM should be avoidable by validating the server name through it's CA chain - regardless of the individual certificate thumbprint/serial. In my observations this is how the MS stack handles server validation; as does on iOS in the case of a properly installed profile via Mobileconfig. b) By storing the cert and forcing users to constantly "accept" a cert as it changes (even when both are legitimate); we continue to train people to just click "accept" - more or less invalidating server validation and opening up users to the same MITM risks as not enforcing server validation.