Hi guys,

I just want to chime in, because we're also going down the wired dot1x route.

I'm hand crafting a configuration profile at the moment, and while everything works as intended, I'm getting the issue mentioned above where I have to manually select the certificate from the dropdown when I connect. My "PayloadCertificateUUID" is pointing to my AD cert, and "AutoJoin" is set to true. I believe this is also what is causing my LoginWindow connection issues.

As I'm hand crafting the profile, my JSS version shouldn't matter? (version 9.83 for those interested).

Any tips?

I believe you are running into a bug I have documented with Apple. The 802.1x wired profile only applies to the FIRST active ethernet port. It does not apply to any subsequent ethernet devices. So even when a profile is configured as system mode if the ethernet adapter that was used when the profile was applied is not present the profile does not apply and you won't have any 802.1x authentication at loginwindow. Since the OS keeps track of these multiple adapters somewhere I asked Apple where this data was stored so I could try and script resetting the adapters the device knows about but they were not keen on assisting in this venture. So here the case sits, at product engineering. Since October.

This is not particularly problematic on Macs that have built in ethernet. Devices using dongles, more so, it is pretty common in our environment that the deployment dongle is not the same dongle a user may use (I mean are we going to tape a dongle to the back of every macbook?).

If you are deploying the profile via casper and have not signed the profile so it is read only there is a JAMF bug where the profile supplies the MDM certificate not the cert from ADCS regardless of what you set as PayloadCertificateUUID before you upload the profile (i.e. the JSS mangles the profile unless it is read only).

If you are on slack poke me (macdude22) and I can supply instructions and a video that shows the bug (and how to replicate) in excruciating detail.

@Kaltsas I read about that bug, but I'm deploying and testing within a minute of each other using the same dongle, so I don't think that's the issue - it's all a test at the moment, we're not in production yet, but we soon will be.

Also, I came across the bug in Casper mangling the profile, which is why I'm handcrafting and manually deploying the profile. I know I can manually sign it and upload it as read only (which I've confirmed works), but I'm trying to get it working first.

The profile actually does work, just not automatically - when I install the profile and plug in, I get prompted to select a certificate. I select my AD certificate, and we're good. But that's the bit that I need to happen behind the scenes, even though I've already specified the PayloadUUID and Certificate as the authentication method.

I'm having the same behavior. We have this workflow setup and functioning for WiFi, and I am able to manually use that same certificate to authenticate over Ethernet, but has to be selected manually. It will be difficult to implement with the current JAMF / Apple bugs, as we want this to be seamless for our users, similar to how it is currently for wireless. Additionally, many users have multiple instances (#1-9) of the same machine name certificate which makes it hard to create documentation on it.

We don't have Apple Enterprise Support, has anybody gone that route and had any luck? This seems to be problematic for quite some time...

Does anyone have an answer to this? It's coming to crunch time and I need a solution.

No matter what I try, the profile is ignoring my "PayloadCertificateUUID" value and prompting to choose a certificate. This is also what is causing my system mode connection to fail.

Does anyone have a working machine auth EAP-TLS config they could share? (TLS only, certificate auth only).

I think I may have worked it out, actually. Not 100% sure what it was, but the following certainly made a difference.

"SetupModes" needs to list "System", as in:

<key>SetupModes</key>
<array>
    <string>System</string>
</array>

I did not specify LoginWindow, as I think that only matters for PEAP/TTLS/etc. I'm using machine cert only, and this works when logged out, and after a reboot.

Do not specify "SystemModeCredentialsSource", at all - this will cause it to try to use the AD machine password, which is separate from the certificate. The mere presence of this causes nothing but issues.

I left "AuthenticationMethod" as blank, as in:

<key>AuthenticationMethod</key>
    <string/>

Specifying "Certificate" or "directory" made no difference.

Last bit requires more testing, because I'd rather it otherwise, but I was trying to split the AD cert payload and EAP config payload into separate config files. Even though I was specifying the correct UUID in both and referencing it with "PayloadCertificateUUID", it was refusing to pick it up. Moving the AD cert request and the EAP config payloads into the one config seemed to have worked. I don't know how this is going to work in 12 months when the machine cert expires.

Yet to test wireless, but we're using the exact same authentication method for that, so it should work just fine.

Hopefully this info helps. The Apple documentation is annoyingly insufficient.

The client "should" notify the user of the impending certificate expiration and prompt for renewal.

https://support.apple.com/en-us/HT204446

However I have seen the profile also request multiple AD certificates so I am not sure how that is going to shake out long term.

My certificate request and EAP-TLS payloads are in one profile. I never tested having the certificate payload outside of the network profile. I wonder if there isn't some security context that doesn't let it work even if you specify the correct PayloadCertificateUUID.

Unfortunately I don't think any of this solves the System Mode profile not applying to multiple ethernet adapters on a single device (which is common in our environment). I am hoping for a stealth fix in 10.12. My case has been in a holding pattern for months.

I am glad you got your certificate woes worked out though, PKI is rough enough on a good day when everything is working as expected.

One more thing I'd like to add to all this.

It would seem that my 802.1x profile, when manually signed and uploaded to the JSS (to get around the JSS bug mangling the network payload) and deployed automatically, the autoconnection feature does not work (ie; it's ignoring my specified cert again). If I unscope my Mac, download the same config profile from the JSS and manually install it, everything works as expected. So it looks like, in order to deploy this profile, I will need to write a script to install it via the "profiles" command, instead of relying on MDM to take care of it.

This whole process has aged me a number of years, so hopefully this is the last I'll speak of it.

@Aaron may I ask you how can I manually sign the profile?
I'm struggling with this issue and I'd like to, at least, find a workaround as yours.

@jacopo.pulici

The command is basically:

security cms -S -N "[certificate_name]" -i profile_unsigned.mobileconfig -o profile_signed.mobileconfig

However, as I run my JSS on a Linux server, I had to first export the certificate and private key, and then import into the keychain on my dev Mac. If you're running your JSS on a Mac server, you could probably just run that command just fine.

If you're struggling, I would suggest configuring everything in a config profile in JSS, download it and unsign it with:

openssl smime -inform DER -verify -in profile_signed.mobileconfig -noverify -out profile_unsigned.mobileconfig

And then open it in your favourite text editor and remove any useless options. This will give you a very good base to work from.

Another thing, I had to manually change "TLSCertificateIsRequired" from "false" to "true". This option doesn't appear to be available in the JSS GUI (at least in my version, 9.81, anyway).

Thanks @Aaron !
Actually my JSS runs on Win.
Later I'll try to download the profile and check the options in it.

From the 9.92 release notes:

[D-009373] Fixed an issue where the JSS failed to correctly set the TLSCertificateIsRequired key in an OS X configuration profile with a Network payload configured with Ethernet and EAP-TLS when compared to the same profile created using Profile Manager in Server app version 4.
[D-009736] Fixed an issue where the JSS failed to correctly create an OS X configuration profile with a Network payload configured with Ethernet and EAP-TLS when compared to the same profile created using Profile Manager in Server app version 5.Fixed an issue where the JSS Setup Assistant incorrectly allowed the JSS URL to be changed for a JAMF Cloud-hosted JSS instance.

oh hot damn I hope that's true!

Anyone had the opportunity to test this?
I'm still on 9.82 and planning to update next week.

Updated to 9.92 but I still have the problem.
The wired 802.1x keeps asking to select a certificate for the authentication.
:(

I had a ticket open with both JAMF and Apple on this subject. The only way I was able to automate this for the end user completely was to add to the profile, sign it and then upload it to the JSS for distribution.

<key>SetupModes</key>
<array> <string>System</string>
</array>

I have been working with Apple Enterprise on this since last October. In the case of devices that have built in ethernet the profile configuration I am using generally works with one caveat. If the network interface is removed and re-added then authentication via System Mode profile never applies.

For devices with no Ethernet built in the behavior is very inconsistent, especially in our environment where it is not assured a 1:1 relationship of dongle-device. IF, and it is a big if. I can ensure the dongle used when the profile is installed is the only dongle ever used with the device, generally the system mode profile works and authenticates automatically, though I have seen it periodically fail and User Mode authentication request credentials. I have worked with apple on modifying some delay timers on this.

I need to be able to install a system mode profile with specified credentials (certificate, machine credentials, etc...) and be able to plug in any ethernet adapter with an assumption the device will authenticate.

Apple keeps coming back to problems with the profile but it works until it doesn't work. There is something wrong with the framework, not the profile. I don't know if it is an issue with enumerating ethernet devices as they are connected and disconnected or what but I am growing increasingly frustrated with the amount of manual massaging I have to be doing to have device authentication in our environment.

I have both Apple Enterprise cases and Radar's logged for these issues, you can contact me off list if you would like to contact your apple representatives to get attached to those.

I opened a separate case up for very similar issues and basically was told "too bad" this is the way it is designed. Glad to see someone got through!

If you have time and interest, poke me off list via slack or email. I am trying to gather more test scenarios about the issues surrounding system mode 802.1x Ethernet Payloads using device credentials.

@ Kaltsas
How did you fix it for your devices with built in ethernet, this discussion is not clear to me for a solution...
I have 133 iMacs that need this certificate popup to be fixed.

@ kaltsas
Hi Alex, we recently moved our organization from one building to another & witnessed that in new block we have to select the Device cert manually , we are on 9.96 at the moment & we are on 10.12.6 & 10.13. Nothing changed on configuration profile or on JSS side.
Hope you could draw some light on this , we are OK to select the cert as it is one time activity as it is setting the keychain.
But would really appreciate the root cause of this behaviour.

Cheers Ravi

Hi @Kaltsas , I have some issues with wired 802.1x profile built by Profile Manager, not sure if you know what is the issue?

@ravigupta230290
Try removing the cert and reinstalling it with your primary ethernet connection.

I discovered this to be an issue after installing the certificate while connected to our corporate 802.1x using thunderbolt ethernet and then switching over to display ethernet. Seems like the certificate is link to the ethernet connection used during installed. For other ethernet connections, the cert will need to be manually selected.