802.1x profiles

[chisox1]

Hello all! Working with JAMF support on this but figured I would post to see if anyone else is seeing this issue. For quite awhile now we have been deploying machine certificates through our load script. All of our machines require network connectivity on first login (bound to AD) so this did great for us. With the recent JSS upgrade it seems like our profile is still installing normally as it should, but when the machine attempts to connect to our SSID, it seems like it doesn't know what certificate to use. Our config profile contains the network setting for our WI-FI network and the AD certificate information. All proper keychain settings are all were they are supposed to go (comparing to machines that currently are working).

If I go into network under wifi press connect under 802.1x it prompts me for what cert to use, I choose our proper machine cert and it actually connects successfully, however we need this to work at login so the profile should be automatically setting this.

Just another fun day in the office! :)

[alexjdale]

In my experience, clicking the Connect button for 802.1x will always cause it to ask for credentials/certificate, even if you already have them specified in the payload and keychain. It's absolutely terrible behavior. You pretty much have to create a profile that connects automatically.

[chisox1]

That was our expected behavior for it to connect automatically. It has been working up until the upgrade to the latest JSS.

[alexjdale]

Rather than use the connect button, what happens when you toggle wifi off and then back on?

[chisox1]

It looks like it attempts to connect but fails, almost as if it doesnt know what cert to use to authenticate.

[alexjdale]

I would check the system log for the failed connection. There may be an error you can resolve (something like an untrusted issuing CA cert).

[pblake]

I was having this issue with 9.5 and 9.61. I was told it was fixed in 9.6.2.

[chisox1]

Thats hilarious... We were having nothing but luck with it on 9.6.1 9.62 is what broke it for us.

[AVmcclint]

Add us to the "Me too" list. We're running 9.62 and I discovered that any computers imaged under 9.62 have this problem. 802.1x connections for Ethernet do not work but our 802.1x connections for WiFi do work. All Macs imaged under 9.3 or earlier still work fine across the board and our Network engineers assure us they have made no changes to the infrastructure. One difference is that if we manually select which certificate to use, it still does not accept it. This is a showstopper for us. I've got 30 new Macs that I need to deploy but if they can't get on the network, they are useless.

[CasperSally]

hope you guys are upgrading in a test environment before production so you're not dead in the water. Pretty much every upgrade we find something not working for us in the test environment...

[chisox1]

Ugh sadly not... We went straight to prod because of some of the fixes. Didnt realize it wasnt working until 4 days after the upgrade on the latest imaged machine. Our current work around is just to have the user log on through a ethernet dongle and manually connect to the 802.1x network. Its not a good work around but its allowing us to at least function.

[AVmcclint]

Clarification for our situation: we have both WiFi and Ethernet configured in our Profile using the same 802.1x settings and the same AD certificate. The WiFi connection works just fine. The Ethernet connection keeps asking to pick a cert but it rejects the cert that we know is correct every time. Even tried the wrong cert with expected results.
Info on what i've done in an attempt to fix this:
- I cloned the existing Profile and added it to a test Mac. No change in behavior.
- I took screenshots of the existing Profile and manually built a new Profile with the same settings that have always worked before. Added it to another test Mac. Still no change in behavior.
- I've watched the System.log on the client machines as we attempt to connect to the LAN and the only thing it says about this problem is "en0 EAP-TLS: authentication failed with status 1" - I've been told by the head of our networking team that no changes have been made to the 802.1x infrastructure.
- Up until today I have made ZERO changes to the Profile that had been working fine up until one of the recent JSS updates. For the record, we are running JSS 9.62.

[bentoms]

Add me as a me, err not!?

In other words, we're not seeing issues with our 802.1x wireless profile deploying or being used since updating to 9.62.

It just works as it did before.

[MARL]

JAMF needs to perform better QA. I agree every upgrade there is always something new and many of those issues you cannot see if related to load in your test environment. 9.61 had a fv key escrow and an issue updating the computer denormalized tables so searches for systems that did not were not encrypted as per the report, if you went to the computer record it would show encrypted. 9.62 fixe this. But JAMF is on par with Apple in that stability for us comes usually in a .2 release :(

[CBrown]

Has this been resolved in 9.63?

[CasperSally]

If people are still having issues, might be worth packaging up the mobile config file with the 802.1x pieces in it, installing it as a package during imaging, and then manually install the mobile config as part of an at reboot script during imaging (using apple's profiles command).

Edit: After install, you can remove the file as part of the at reboot script

[chisox1]

What I had to end up doing is making a brand new profile with the same settings. I thought "cloning" the profile would essentially be the same thing, but the new profile worked instantly. JAMF support thought this was due to a "corrupt" profile, but I am not quite sure how that happens.

[blackwoodT]

Hi All,

I am also experiencing a similar issue. The way our network is setup is as followings:

- Separate Profile on all wireless computers that connects the Login Window to our hidden management network.
- 802.1X Profile allows users to connect using AD credentials and transfers them to the correct wireless network and VLAN (Staff/Student).

I have got all this working again after some initial issues. The problem we have now is if the computer goes to sleep, is shut or wifi is toggled on and off the computer does not reconnect to wifi just looks like it is trying to connect.

The only solution I have found is to log off the machine and back on again. This is obviously not a great work around. We have teachers returning to school in a week and students in 2 weeks, has anyone come up with a work around?

EDIT: We are running 9.62, was planning to upgrade to 9.63.

Thanks,

Will

[charles_hitch]

So you need to make sure that the PayloadCertificateUUID in com.apple.wifi.managed payload matches the PayloadUUID from the com.apple.ADCertificate.managed. I build our configuration profiles manually so I am not sure how you would verify this in the JSS UI, but that was the key for us to make sure that the system knew what cert to use.

[azbikowski]

I see this for Ethernet connections, but our Wi-Fi configuration works.

[RobertHammen]

Seeing the same thing - an 802.1x profile for WiFi and Ethernet and AD Certificate, created in 9.62 (JSS now updated to 9.63), works for WiFi, but the Ethernet configuration coming from the profile fails unless you specify a custom config, and choose the machine cert (and, in our case, enter host/ in the username field, leaving password blank). Once configured it works, but my suspicion is that the JSS is not properly generating the wired 802.1x profile...

[azbikowski]

Just ran into this on a machine recently upgraded to Yosemite. 802.1x Wi-Fi profile works no problem.

Connect to Ethernet and the Mac throws up "Select Configuration" and the drop down choices are Default Configuration, and the Ethernet and Wi-Fi configurations from managed profiles.

Ethernet profile doesn't work, but if you select the Wi-Fi profile Mac OS will then prompt you to select the certificate. You can then select the machine certificate, leave the username field blank, and click connect. The Mac then connects to Ethernet using the Wi-Fi 802.1x profile.

This seems to be a recurring bug in JAMF. I've had similar issues appear in a point release, go away with another, only to come back in a later point release. It would be really nice if this bug could be fixed and not added back to the source code in a later release. ;)

[bentoms]

We had to make a change to our 802.1x wireless profile for 10.10, but others have too outside of the JSS.

Back with 10.8, I had for change the NPS settings for the clients to connect.. (But using the same profile).. Link below, perhaps there are other things at play?

https://macmule.com/2014/05/19/error-10-8-clients-not-connecting-to-eap-tls-wireless-with-w2k8-nps/

[jacopo_pulici]

Hi, I'm having the same issue.
I had a profile with two payloads: AD certificate and 802.1x settings for wifi.
It worked.
Now I have to add also the 802.1x authentication on the Ethernet interface and when I connect the cable for the first I have to manually select the wifi payload and machine certificate in order to successfully connect.
Any advice to automate this?
Thanks

Jack

[Kaltsas]

I don't think you can craft a profile that will pull a certificate from another profile to use as identity credential. The certificate request payload and 802.1x payload selecting that certificate as a credential have to be in the same profile.

You might be able to add an AD certificate payload to your 802.1x wired profile such that the client will get 2 certificates but I am not sure. You may be relegated to manually selecting the identity credential on the interface that doesn't have the certificate payload.

There is also a bug in the jamf wired profile that the AD certificate is not passed as the identity credential. You'll have to create the profile in profile manager, sign it, and upload it as read only to the JSS.

[nkalister]

Jack, you'll need to update your profile with a payload for wired ethernet in addition to wifi. It'll need to be in the same profile as the cert payload like Kaltsas said.
Also, watch out for issues with installing the profile with that payload. I'm not sure if apple has fixed the bug, but in Mavericks and Yosemite, if the Mac didn't have a built-in ethernet port or a wired ethernet adapter actually plugged in the profile would fail to install if it contained a wired ethernet 802.1x payload.
I've always generated these profiles using Profile Manager on OS X Server, and as long as I avoid the missing ethernet port situation, I've never had any problems with it.

The other option would be to use the security command in a script to create the identity preference for wired ethernet in the keychain manually. You'd need to know the hash or common name of the certificate to use for auth to do that.

[Aaron]

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?

[Kaltsas]

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.

[Aaron]

@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.

[TBathe]

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...

[Aaron]

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).

[Aaron]

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.

[Kaltsas]

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.

[Aaron]

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.

[jacopo_pulici]

@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.

[Aaron]

@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).

[jacopo_pulici]

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

[jacopo_pulici]

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.

[AVmcclint]

oh hot damn I hope that's true!

[jacopo_pulici]

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