802.1x Wired Authentication

[#1]

I am trying to setup 802.1x wired authentication prior to a user logging in. The issue with configuration profiles in the JSS is that it does not send the request or credentials to the IDE server. I've also tried to utilize profile manager to create a signed configuration profile to no avail. Any ideas?

[JNeumann]

What version of the JSS and OS X are you running?

There have been known defects with the configuration profiles being generated by the JSS and then there were the early releases of OS X 10.10 where the supplicant just didn't seem to respond to the EAP messaging from network devices.

Your message suggests you're using "Use as a Login Window configuration"?

[grahamfw]

Are you able to get the config profile delivered or is this on a DEP-enabled machine before any user logs in ever?

[#4]

Sorry for the delayed response, I was on travel.

JSS 9.82
OS X 10.11.5

I have used with and without "Use as a Login Window configuration" and have tried a combination of settings.

We have not setup DEP as of yet, but the config profile is being delivered. The credentials just are not being sent back to the authentication server.

[grahamfw]

We ran into the same issue. There is a defect that is resolved in 9.91 or 9.92 whereby the JSS does not create a valid 802.1x wired configuration profile. Wireless is fine. If you use Profile Manager to create the Configuration Profile, that may be a good starting point.

Try this:

• On a machine not yet connected, install the manually downloaded 802.1x config profile
• Run the command explained here

  sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.eapolclient LogFlags -int -1

• Look in the log file for the certificates under the TLSServerCertificateChain key. You'll need to manually trust these as part of the Network payload. Save the certificates from that key to a .cer file (e.g. certificate1.cer, certificate2.cer, etc) and make sure to save them as plaintext. This is what the text needs to look like in the files:

  -----BEGIN CERTIFICATE-----
  MIIFYDCCBEigAwIBAgIRAL3rd
  (copy and paste this directly from the log file
  with the "begin" header and "end" footer)
  -----END CERTIFICATE-----

• Once in a plain text file, use Java's keytool to get the name of the certificate:

  keytool -printcert -v -file pathtocertificate.cer

• Look for the line "Owner: CN=THIS NAME HERE, DC=domain, DC=component, DC=com
• You want the whatever the CN of the certificate is. That's what you'll need to enter in the Network Payload in the Trusted Server Certificate Names, usually in addition to trusting the certificates separately in the Certificates payload.

Do this for each certificate that shows up in the TLSServerCertificateChain on that log file and that should get you what you need. Keep in mind that under Trusted Server Certificate Names, you can use wildcards (at least in 9.92) - i.e. *.yourdomain.com. You will need to play with this a lot (at least I did) but I think you'll get it based on this info.

Hope this helps!

[perrycj]

@esembly Wired ethernet configuration profile creation (from scratch) is still broken as of 9.92. See this thread:

https://jamfnation.jamfsoftware.com/discussion.html?id=11234

There are 1 and possibly another, product defects JAMF is going to file in relation to wired ethernet 802.1x creation. Your best bet is to create your profiles in profile manager, sign them and then add to the JSS and they will work as expected.

[grahamfw]

Interesting. I've created my profile in the JSS in the latest version, and I have both of those values when I inspect the xml. According to the history for the config profile, it was created from scratch.

Profile Manager is definitely a good way to go if there is any doubt that a profile is working.

[perrycj]

@grahamfw What type of connection are you using? And do your profiles that you've created from scratch in the JSS auto-connect without user interaction? That is interesting if they do work and you're creating them from scratch.

[grahamfw]

@perrycj This is 802.1x ethernet config. They should have been created from scratch (otherwise history would have shown the "copy" config name). We're using AD certificates, so they connect without user interaction for the most part.