Security

We are running into a problem with onboarding macbooks.  We are using single SSID onboarding with ClearPass 6.1.0.  The macbooks authenticate successly using EAP-PEAP, go through the onboarding process, get the profile installed, however when it comes time for the device to reconnect (either automatically or manually with the "connect" button), the macbook reauthenticates with EAP-PEAP rather than EAP-TLS.   This causes the device to stay in the onboarding role rather than the post-onboarding role we defined.  If we then turn WiFi off/on the device connects successfully using EAP-TLS.  

We took a packet capture on the macbook (screenshot attached) that confirms the controller requests EAP-TLS but the mac supplicant responds with a legacy nak and requests EAP-PEAP instead.  This suggests that the problem lies with OS X.  iOS devices work fine, as do Windows devices.  We have tested with both OS X 10.8.3 and 10.8.4.  

Has anyone else encountered this problem?  

Two questions:

On the controller side, do you have ""Add switch IP address in the redirection URL" in the Captive Portal profile?

On the ClearPass Onboard side, do you have "

?

If you don't, remove the profile, delete the certificate from onboard;  enable those two options and try again.

Yes, we have that option enabled in the Captive Portal profile.  The RADIUS CoA from ClearPass is definately reaching the controller and taking effect.  The macbooks gets disconnected and attempts to reconnect and that is where the problem lies since they reconnect with EAP-PEAP and not EAP-TLS. 

On the ClearPass side, we have tried both with automatic reconnect and manual reconnect.  We also tried extending the time to disconnect.  No luck.

What are your advanced reconnection settings in Onboard under IOS and MAC OSX?

Also is there any issues logged in the application log during the onboarding disconnect in the CP Guest side.

At present the advanced reconnect settings are the defaults (3,10,15).  We tried increasing the disconnect and reconnect delays to 5secs and 15secs respectively but it did not appear to make a difference.  

Tarnold,

We turned on debugging for the Onboard plugin but nothing stood out in the CPG logs.  

You may need to open a TAC case on this so that we can see the whole setup, I'm a much more visual person :P

But I ran into this last week and had to do the following: 

1. 2 Service solution. Service 1 to handle onboarding, Service 2 for post onboarding. Service 1 should be 'lower' on the service list. And should contain the PAP/Local Host configuration 

Service 2 Should allow PEAP and TLS with enforcement that says IF PEAP; then Captive Portal Role; If TLS, Welcome to the network role. 

Of course there is a lot more consideration that needs to be done for other PEAP devices, but its doable. 

2. Uncheck PEAP from OnBoard>Configuration Profiles> Network Settings> Protocols > OSX,IOS > PEAP

Its only needed for post onboarding of devices that do not support TLS. It seems OSX by default will prefer PEAP over TLS don't ask why;

After that everything was happy. 

Also make sure that everytime you onboard your test device that you remove the profile and certificate from both CPPM/Guest side and the device. 

Yes, we have a ticket open with TAC for this issue.  Hoping to have an update soon.  

1) We do have separate 802.1X / Onboard Auth services defined and working.  iOS devices onboard and reconnect OK.  OS X devices always seem to reconnect with PEAP the first time after onboarding...

2) PEAP is NOT checked for iOS and OS X EAP Protocols. 

Regarding test devices, I have been deleting the device certificate under Certificate Management in CPG and removing the profile from the device.  I do notice however that this does NOT remove the device entry under Device Management in CPG.  In fact, I cannot seem to fine any way to remove those entries...

Whats your case number; I can check on the status for you.

Case# 1426946 

Thanks! 

I talked with the engineer, he is in the middle of replicating the issue; I told him if he cant replicate or runs into a road block to just escalate the case to me. 

Thanks.  This issue first manifest at a customer site.  I just tested in my own lab (ClearPass 6.1.1) and got the same result with an OS X laptop running 10.8.4.  I suspect this may be an Apple issue.  In the short term, I am thinking we could just edit the "After Provisioning" instructions to direct Mac users to turn WiFi off/on as this seems to work fine.  

The more troubling issue (on the same TAC case) is that ClearPass does not appear to be enforcing device onboarding limits (see my other thread: http://community.arubanetworks.com/t5/ClearPass-formerly-known-as/Onboard-Device-Limits-by-Group/m-p/80300 ).  This is very bad since each onboarded device = $$$.   I am really hoping this is just user error on my part.

I'm having the same issue on a few OS X 10.9.4 machines. Was this ever resolved? ClearPass version 6.3.4

There are few different issues that some of the guys are having in this thread. What is your exact issue?

The client re-connects as PEAP and not TLS even after toggling the wifi. 

Are you using the same SSID for both PEAP and TLS? 

Double check your profile settings under onboarding. I just did a test with my 6.3.4 and osx and there was no issues.

If you make any changes to your network settings in CPPM you need to resave the provisioning profile to make sure a new package is built.

TAC suggested bumping EAP-TLS with OCSP above PEAP in my authentication method list on the service. This seems to have fixed it.