Security

Provisioning issues samsung for TLS. EAP: Client doesn't support configured EAP methods. Any idea?

Works good with iphone. Stop working since new update.

 

What version of Android?  Can you use PEAP?

running android 4.3.  provisioning works great with iphones so we do not want to keep making new SSID for different device.

 

In the onboard settings, you can select PEAP or TLS to provision to android devices. If you have TLS selected try PEAP to see if it works for you

Sent from my iPhone

I moved to TTLS and MSCHAPV2 for inner. work good with android.

 

GLad to hear!

What model of samsung

Are talking about not working after you updated the Samsung or cppm. There is an issue with some samsung devices that deletes the root certs after you upgrade them and you need to reprovision the device to get the certs

Running into this same issue with multiple Samsung devices on 4.3.  Not having this issues with a Nexus 7 on 4.4.  Is the only suggestion to use PEAP?  If so, I don't understand why EAP-TLS would be an option.

The Compnerd,

 

I believe PEAP was a troubleshooting step to remove the act of provisioning as the issue, rather than a resolution.  As you know, all Android manufacturers do not handle TLS the same and some are better than others.  Is there a specific Samsung Device and Android version you are having trouble with?

Samsung Galaxy S3

Samsung Galaxy S4

Samsung Note 2

 

We have a group of developers that need to onboard several varying types of android devices for testing mobile apps that they build.  Therefore, I need to find a common authentication protocol that they all are capable of using.

 

I'm reading up on EAP-TTLS w/MSCHAPv2. Maybe this is the way to go based on a previous response?

thecompnerd,

 

What happens when you provision a samsung device via TLS?  Does it fail, and when?  Different devices might have a slightly different workflow, if we just might need you to use the one for Samsung.  TTLS is an option, but I cannot say that it is the correct one for your environment.  TTLS uses a username and password just like PEAP and nobody knows the password and it is unique so it would be just as secure, except the tunnel is setup differently.  There might be little if any difference in your enviornment regardless of the choice you make.

I get a RADIUS reject w/ reason:

 

EAP: Client doesn't support configured EAP methods

 

In the access tracker details, the client authentication method is just "EAP" and there are no certificate details under computed attributes.

 

I've been having trouble distinguishing the differences between EAP-PEAP and EAP-TTLS.  As you said the tunnel is setup different.  With EAP-PEAP, I know that the RADIUS server sends its certificate to the client so the client can verify the RADIUS server, but I had assumed the cert was also used to build the tunnel.

 

I'd like to avoid having multiple CPPM policies and multiple Onboard Network Settings w/different authentication methods if I can have one policy to handle them all.

TheCompnerd,

 

And this is after successful onboarding?  When looking at the Samsung device after, is the wireless setup with EAP type TLS and the certificate is present?

 

A good example of the difference between PEAP and TTLS is here:  http://serverfault.com/questions/349319/why-would-you-use-eap-ttls-instead-of-peap

Yes, the devices onboard successfulyl.  Also, I see a certificate for the devices in ClearPass.

 

On the client if I edit the SSID settings, it has a certificate selected and authentication method is EAP-TLS

What version of CPPM are you running. I have TLS working fine at multiple sites and in my lab on a S4. I haven't test S3 here but I know the other sites have and they also are not having issues. You might need to open a TAC case to verify your settings. It's always the little things that you miss. :)

*Sometimes* TAC spins their wheels and it wastes my time. Trying to avoid that today. :)  Not trying to pigeon hole all of TAC, but that's just how it is sometimes.

TheCompnerd,

 

Without being onsite, there are not many ways that most cases can be quickly resolved.   For every right way there is to configure something, there are quite a few ways to configure it wrong, and TAC must go through all those scenarios.  On this forum, we have access to much less information than when a TAC case is opened, so we are officially guessing.  Statistically, it can be more frustrating here than a TAC case.  There is nothing wrong with opening a TAC case in parallel with an inquiry here, because at least TAC can leverage your personal information to possibly acheive a result;  on the forum here we cannot :(

 

If at any point you feel like you are not getting anywhere with a TAC case, you can request to have it elevated, and more eyes will be placed on your case.

Just an update there was an issue discovered in 4.3 firmware in samsung that does not like a cert on CPPM that is not provisioned from a public CA. See here in the release notes for 6.2.5. In testing we found that 4.4 there was not that restriction, so the chomebooks worked fine

 

20867 Symptom/Scenario: Android 4.3 and above fails to install self signed certificate for the CA certificate.

Workaround: For onboarding Android version 4.3 and above, CPPM must have a RADIUS server
certificate issued by a proper Certificate Authority and not a self signed certificate. This is a requirement
of Android’d API for Wi-Fi management. In Onboard network settings, the CA certificate that issued the
server's certificate has to be selected as the trusted root certificate to be installed on Android.

Update - Issue Resolved

 

The RADIUS server certificate for my publisher was chained incorrectly.  I didn't notice it until I started comparing the publishers certificate to subscriber certificates in CPPM.  Not realizing it, my chain looked like this: server > intermediate > (different) intermediate.  I fixed the chain by replacing the last intermediate cert with the root and uploaded it to CPPM.  I never noticed this before because it didn't cause authentication issues for any of my other devices.

 

Edit -----

 

For further clarification, I wanted to add that the incorrect chaining only seemed to affect Androids 4.3 and below.  It had no effect on Windows, iOS, or OS X devices authenticating.  Not sure why Android was soo picky when the other devices ignored it.

So Troy what is the solution for the self signed CA with Android 4.3 ? buying a server certificate for the CPPM only ? or any other workaround (updating to 4.4 depends on the manufacturer so not an option :( )

i would expect that to be the only solution then, assuming the other mentioned cause (wrong chain) is applicable to you.