802.1x wired configuration profile not working

I started experiencing that very same problem after an update to 9.6 I think (it's been a while and still doesn't work). The way I had to work around it is find a JSS server that was still on the older version (~9.3) to create the 802.1x profile. Then download that profile to my desktop and then upload it into the "production" JSS server running 9.6+. That works as long as I don't make ANY changes at all to the profile. The only change I can make is to the scope - that's it. I don't have a cure yet and we were extremely lucky to have an older, forgotten server still running the slightly older version. It works as long as we don't make any changes to the 802.1x requirements. I'm still waiting for JAMF to fix this particular bug.

That's a great tip AVmcclint. Thanks for that. I'll have to check and see if we have an older version of Casper running somewhere and if that indeed does fix it you'll have saved me few months of agony with this.

I'll check this out on Monday and see if that helps with the 802.1x issues we've been having.

Cheers
MC

One caveat: Because the JSS versions are different, there are 1 or 2 settings that don't exist in the older version (at least in our case). The one that is a thorn in my side is the older JSS does not have an option for our AD Certificate to "Allow access to all applications". It does exist in the newer version, but as I said, you can't make ANY changes at all to the imported profile without it breaking again. I've had to manually go into each computer's Keychain Access and find the computer certificate/key and check the box to allow access to all apps that way. If I didn't do that, our Pulse VPN client would ask for admin credentials every time a user tried to connect over VPN. If you need a setting that isn't present in the older JSS you build the profile on, you may need to research workarounds or manual ways of accomplishing the same thing.

Right gotcha.. it's definitely worth a shot because we've been trying all sorts of things to get this working but haven't been successful at this. I'd like to give your solution a go because if we can atleast get the 802.1x settings working... that's more critical for us at the moment.. after that we'll have to get some stress testing done and trial the fix on a few users for a week or 2 before deploying it to the rest.. but first comes first.. hope that the network profile gets sorted.. the discussion forum also said that 9.72 was released... i hope that the new version would address this issue.. Thanks again mate.. much appreciate your help with this.. :)

FWIW I received word from jamf that there is a defect #D-008952. In the defect it states that PEAP domain credentials are not sent as of version 9.63 when wired is selected as the interface.

For anyone that is using Wired 802.1x authentication can you run an experiment for me. Try multiple Ethernet dongles (USB or thunderbolt). I have run into an issue that the profile will work for the first ethernet interface but any subsequent ethernet interface requires user Authentication. I have a case open with apple and they believe they have replicated it, but I would like to see if anyone has run into this out in the wild. My issue is when imaging techs will use different dongles than the end user may be using.

@Kaltsas If you get anywhere with this, I would be interested to hear what Apple says or if there is any way that I can use any active dongle when the user first boots the system post imaging. We use Thunderbolt dongles to image and employees have USB dongles at their desk so when they boot the system, they don't see the dropdown menu for the 802.1x configuration profile.

My setup below

So the way you have that profile configured I am assuming users are authenticating as themselves, not the system authenticating with its domain credentials. I say this because #D-008952 is computer credentials not sent via PEAP using JAMFs built in profiles. If they fix that I am not sure what would happen with that profile configured the way it is. PEAP with computer credentials should be set as a system mode profile while user authentication would be set as Login Window Mode. JAMF really puts a layer of abstraction into config profiles. An OS X supplicant can operate in 3 modes User Mode, System Mode, and Login Window Mode but Apple's 802.1x white paper says that System Mode and Login Window Mode can be used together. It's not clear to me what benefit this gains you since the supplicant authenticates 802.1x with the user supplied credentials and then against the directory with the user supplied credentials. I would revisit your configuration to make sure exactly how you want authentication to happen so you don't run into any surprises when/if JAMF fixes that defect.

Because JAMF has defects in the network payload for both PEAP and TLS certificates I have hand made profiles, signed them, and uploaded them as read only. This is mostly working as expected. I have gone with the extra moving parts of TLS certificates because in this configuration any user can still select the machine certificate as the identity credential on additional ethernet interfaces. With a PEAP profile additional ethernet interfaces are dead in the water.

At any rate a system mode network payload that would normally have a drop down selection at the login window won't show up at the login window on additional ethernet interfaces because of the OS X bug. Applecare Enterprise has replicated the issue and it has been sent to product engineering but we are not expecting a fix before 10.12. I have portrayed the issue to our Rep and SE and have tried to make clear to them that an expectation of enterprise would be that a system mode network profile should apply to ANY active ethernet interface, not sure how much extra traction that gets me though.