Anyone experiencing problems connecting to 802.1x after Catalina upgrade

[hedenstam]

I have test users who are not able to to connect to the company network (802.1x) after upgrading to Catalina.
If they do a fresh installation and get the same 802.1x profile, connection to network works fine.
Anyone else experiencing any similar problems?

[schiemsk]

Which type of profile do you have ?

My 802.1x user auth WiFi profiles works fine after Catalina upgrade.
Both EAP-PEAP / WPA2 Entreprise.

I've not yet tested our computer cert-based auth profile (no user auth prompt).
TLS, First Active Ethernet.

[hedenstam]

We have WPA2 Enterprise, EAP-TLS, Computer certificate

[schiemsk]

I've just upgraded a MacBook from 10.14.6 with 802.1x computer cert profile.
It's still working well after the update upgrade.

[ChrisLawrenz]

No problems with upgraded Systems and bank new installed systems.

[patgmac]

No problem here with EAP-TLS cert delivered via Jamf's AD CS connector. Are you using the AD Payload?

[powderspecial60]

We have been using the Jamf ADCS connector, it sends a system/computer based cert and configures both the hardwire interface and the wifi. The hardwire seems to work flawlessly, the user can unplug/replug the network and it auto connects. They can also even use the disconnect button from the network preferences and will connect right back up with no issues once connect is pressed. Now to the wifi, it works, but has been kinda a pain. So far it seems as if the wifi is just turned on and off, no issues. If the user un-checks the automatically connect box and disconnects it behaves as expected. However, when the user tries to connect back to wifi, it prompts for credentials to access the cert every time. It seems as if the always allow box is not available on the login prompt as well, so a prompt every time is happening. I am wondering if I should switch the cert to a user based cert, but don't exactly understand why the behavior is not the same on the hardwire side.

[jupackazoin]

Can you guys confirm that after updating to Catalina your users are logging into the wifi with their user account post login? I am using the same profile we had for High Sierra (skipped Mojave) and on High Sierra the user logs into the wifi after the login window automatically (machine auth was used at the login window) but on Catalina the device stays machine authed after login instead of swapping over to user auth post login automatically. Wifi still works but unfortunately our internet filter goes we don't know you cause you are skynet instead of a human.

[kaurloto]

@powderspecial600

However, when the user tries to connect back to wifi, it prompts for credentials to access the cert every time. It seems as if the always allow box is not available on the login prompt as well, so a prompt every time is happening.

This. Happens to me as well on our Catalina upgrades.

It's as if the network configuration loses access to the required certificate stored in the System Keychain post-upgrade, so on every SSID reconnect they have to enter admin credentials to get read access to the cert again. Unfortunately it doesn't look like there is an option to "Always Allow" on authentication, so it prompts on every reconnect.

Reapplying the Wifi config profile fixes this but that's not really a viable solution to reinstall the profile on all our macs. We are using a SCEP payload as the identity cert in our wifi profile so keeping it at the computer level is a must.

[joshsw]

In my instance if we connect to another network then try to connect to our preferred Wifi it prompts for credentials instead of just using the cert. If we disconnect from the other network first (or turn wifi off and back on) it connects just fine to our preferred Wifi and uses the cert - no prompt. I have a ticket open with Apple for this. This happens on any Catalina machine, upgrade or fresh installs. I'll be sure to update if anything useful comes from it.

[kaurloto]

@joshsw If you remove and reapply the config profile does it eliminate the keychain prompt for you? Let me know how your support case goes with Apple, hopefully I can piggy-back off their suggested solution. I have Catalina excluded on our SUS to buy us more time but this will be a big problem down the road if unaddressed.

[snovak]

We do AD machine account authentication; it failed to connect to wifi after the upgrade, but when I hard-wried it back it must've updated its AD password and it connected back to the wifi.

[johankjellman]

Have the same issue here.. :(

[joshsw]

Apple is looking into it internally but I haven't heard back yet, probably time to ping them. Removing the profile and re-applying it does not resolve the issue. It seems to be some sort of error in Apple's configuration where if you switch between wifi networks it tries PEAP first for some reason. At least that's how they explained it to me.

[powderspecial60]

@kaurloto I figured it out on Friday after I finally had some time to put into researching this issue. It appears that for some reason the allow all apps access was checked in the config profile we use for the network certificate payload. Once we upgraded to Catalina this started to cause authentication prompts. I believe the permissions were too wide open on the private key similar to when you chmod 777 certain things in /etc I assume. I removed that option and it started working as it does on Mojave.

[Mykolas]

Hi guys,

I had this issue from beta Catalina release we had some changes in our SCEP and certificates configuration profile. And somehow magically after the change on 10.15.1 network started connecting automatically and it worked for about 3 weeks nothing was changed and today it started having same issue again. Meaning that user needs to select certificate manually to get corporate network access.

Allow all apps access was disabled form the get go.

[powderspecial60]

It seems like for me the profile works most of the time. Occasionally we have users where it forgets the certificate settings and requires them to select the cert again. I know if the user goes in and hits forget network this will happen, but it seems like it happens randomly as well too.

[blheureux]

We are seeing this occur with 802.1X machine authentication fairly consistently upon upgrading to 10.15.2. The AP logs show that the machine is attempting to use the first part of the AD domain's FQDN instead of the domain's NetBIOS name in "domainusername" authentication. As soon as we plug the machine into Ethernet once after the upgrade, future Wi-Fi 802.1X authentications work fine, even without Ethernet connected. We have a ticket open with Apple on this as well.

[jleomcdo]

I know this is an older thread, but I ran into this issue recently.  I found that any time we install an Apple security or OS update, then the Mac will fail to auth to 802.1x with System Mode (computername).  Once we connected to hard wire, or vpn, then the 802.1x would work fine.

We use Cisco ISE for our wireless back end.  We found out that the mac was passing the "username" with the wrong prefix.  it was trying to use the first part of the FQDN.  Like you mentioned.

Our network team found a feature that allows you to create a rule to re-write the string so it matches what ISE expects it to look like. When the Mac sends FQDN\hostname, we are now re-writing it to DOMAINname\hostname.  This has resolved the issue.

Our Apple support rep still has our case open and is with Engineering for now.  He said that if more people with the same issue were to open cases with Apple, that would raise the priority of getting this fixed.  If you want open a support case, you can reference my case number.  101436764941 is the Apple Support case number.

[bluestunes]

Did you find a solution from the Apple side of things for this issue?

[jleomcdo]

I still have a case open with Apple, but no update.  We continue to use the work around from Cisco.  By "creating a rule to re-write the string so it matches what ISE expects it to look like."

I'd suggest open a support case with Apple.  The more people that report, the higher on the list this issue will be with Apple Engineering.

[bluestunes]

A colleague has/had a ticket open with Apple. We are trying this on Aruba's ClearPass: https://community.arubanetworks.com/browse/articles/blogviewer?blogkey=ba41c75d-4346-44ab-9bfa-10ede...

[patrickbaeken]

We have WPA2 Enterprise, EAP-TLS, Computer certificate. Certificate is installed on the users laptops by the helpdesk.
I enabled "Always Trust" on the certificate but was still seeing the prompt every time wifi was disconnected.
Solution was to edit the private key and set "Allow all applications to use this item".
Have not seen a prompt since then.

[NealIV]

We're having this issue as well with on the Catalina Macs. Anyone get a fix for this yet?

[rqomsiya]

How long is your cert validity date set for?

[HeyWhosTheMacGu]

We're now having this issue with Big Sur UPGRADES. The SCEP cert config profile works without issue on the wired network but when connecting to the corporate WiFi, macOS prompts to choose the protocol (ours is TLS) and certificate. However, the exact same SCEP machine certificate configuration profile doesn't have the issue on new Big Sur machines. The issue only happens with Big Sur upgrades. We can't roll out our upgrade until we figure this out. Even if our users selected TLS and the correct certificate, they don't have administrative rights to make changes to the keychain. If anyone can help, we'd be very appreciative.

[bmacedo]

@blheureux

We are seeing this occur with 802.1X machine authentication fairly consistently upon upgrading to 10.15.2. The AP logs show that the machine is attempting to use the first part of the AD domain's FQDN instead of the domain's NetBIOS name in "domainusername" authentication. As soon as we plug the machine into Ethernet once after the upgrade, future Wi-Fi 802.1X authentications work fine, even without Ethernet connected. We have a ticket open with Apple on this as well.

Any chance you found a solution or got an answer from Jamf/Apple on this? I'm experiencing the exact same issue. Worked with one of our great Networking guys and we found this in the logs on the AP. Just like you, we've been manually connecting to Ethernet as a workaround, but are looking for the real fix.