Security

Hello!

I got more or less no respons on my other topic that has evolved a little, so I move on to another headline.

My scenario

 * Open-ssid (aka Guest-ssid) that allows for registration of mobile devices/iPad. Authenticates both self-registered guests and AD-users. Authentication use https. This process downloads certificates and profiles on the iPad to make them able to connect to the TLS-ssid

 * TLS-ssid used for BYOD. Need to connect to Open-ssid first and complete the mdps process before being able to connect.

This used to work, but for some reason stopped about the same time IOS 5.1.1 was released.

Question

Has anyone currently a similar scenario that works?

Is this scenario at all supposed to work?

 * If not - then can you suggest a better implementation for me?

Thanks for any help you can provide.

John,

Can you give us a run down of what happens when this doesn't work.

Off the top of my head the challenges that need to be addressed when provisioning over the Open SSID will be as follows:

• Apple's Captive Network Assistant (CNA) will come into play on the Open SSID (iOS 6.x has this enabled for all WiFi security types) and therefore you will need to implemnent a bypass of the CNA. Details on this are available from the Aruba VRD site
• Typically the provisioning process over an Open SSID will be deployment over a HTTPS connection and therefore a trusted server certificate will need to be installed on the web server of the Onboard server. This can be either from a public CA or local PKI but the later will require the user to download the trusted CA prior to kicking off the provisioning process.

Hope this helps

Cam.

Hi Cam,

well - more info is in my other post, but ok since I got your attention ;)

CNA is taken care of.

The https certificate is also taken care of.

The solution as described here worked,  and the provisioning process still works. Users just stopped being able to log on the TLS-ssid with a "Could not connect to ..."-message. Re-creating the CA certificate chain etc. did not work. This stopped around the time IOS 5.1.1 was released, but ofc that might be coincidence.

Support told me to move EAP-Termination to Amigopod and also upgrade to CP3.9. This solved it for self-registered users (as in Clearpass does the authentication), but AD users (as in external authentication proxy) still get the same issue and these are the most important ones to get working.

I created the scenario in our lab environment just settings things up according to documentation, and the same issue occurs there.

Current test scenario for mdps

• Controller AOS 6.1.3.2
• Clearpass Guest + Onboard 3.9
• Onboard is the CA
• Authentication using both clearpass internal and Proxy Radius authentication server towards AD (NPS on Windows 2008 R2 server). Note that both using AAA test server and logging into the open-ssid using the AD user works fine.
• iPad IOS 5.1.1 and 4.3.3

Other things..

• Tried instead to add Clearpass to the Windows Domain and use AD authentication instead of Radius Proxy, but still get the same issue.
• EAP-Termination on the Controller gives "Could not connect to ..." message when connecting to the TLS-ssid for all users
• EAP-Termination on Clearpass gives "Could not connect to ..." message only for AD users, while Clearpass internal users get success.
• Server certificate is created using Onboard CA, and I use the same on both EAP-Termination scenarios
• I've rebooted iPad and Clearpass server many times - as not doing this caused problems in the original installation.
• I have not tried to provision anything other than IOS devices, as this is the customers primary concern and is what used to work just a month ago

It might be worth checking the RADIUS transaction being sent to your NPS server during TLS authentication. I recall that the controller EAP termination will send an Authorize-Only RADIUS request and the ClearPass platform could be doing the same. I don't think NPS supports this service type by default and might need some configuration changes.

Why this would be affecting just your 5.1.1 devices I don't understand. We are testing Onboard with 4.x, 5.0.x, 5.1.x and now 6.x releaes of iOS to make sure we have good coverage of the commonly used versions.

Hi Cam,

well I got some good help from Gowri on this matter and located the problem.

When you configure the Amigopod to do EAP-Termination then it's automatically creating a new Authentication server called "Local Certificate Authority". But - the default value for "Authorization Method" is set to "Use the common name of the certificate to match a local user account", and that messed things up.Changing that value to "No authorization - authenticate only" instantly solved my problem.

Why this stopped working in the first place I've stopped contemplating ;)

Thanks again for you time

Hi John, 

Thanks for your update! This helped me alot getting iPads to provision correctly! Specifically changing the Auth Method to authenticate only. 

Thanks,