802.1x WPA2 enterprise / Big Sur

[FrigidInIowa]

I'm having an issue with Big Sur machines that do not want to use the same WiFi profiles to connect to 802.1x / PEAP SSIDs in our enterprise environment. These are domain-joined machines that have used AD certificates for authentication. Of course, this was working fine through Catalina. We deploy a root CA and Wifi settings configuration profile through Jamf Pro 10.26.1

Has anyone run into this yet? Currently working on a test machine running 11.1.

[FrigidInIowa]

I'm wondering if it's due to the root CA cert being SHA-1. I've seen this KB from Apple: https://support.apple.com/en-us/HT210176. It seems odd that if the same requirement was true for Catalina that those machines continued connecting, but Big Sur does not. If anyone's run into this I'd appreciate the insight. Otherwise, we'll look at getting the root CA up to a sha-2

[#3]

We have same issue 802.1x not working on Big Sur

[andrew_nicholas]

This may be similar to the issue seen here. We use Microsoft NPS for RADIUS and while I've opened tickets with both MS and Jamf neither has been able to help. I filed an Apple bug report and have just gotten an Apple Enterprise Support Case started to hopefully get to the bottom of the issue. I would encourage opening cases with your WiFi solution vendor/Apple/Jamf if at all possible so that there is traction on the issue as each time I've spoken to someone they say they've not heard of any issues (likely because people are largely WFH).

[FrigidInIowa]

I'm using Wireshark on my test Mac (11.1) and am seeing where my Microsoft NPS server responds with a certificate, with the Mac immediately closing the connection. I'm sifting through the logs to find out why that might be and will update with any findings.

[ginakung]

I am also having this issue. Have you tested deleting the device inventory from Jamf and deleting the machine record from AD?

[FrigidInIowa]

We have definitely tried removing the record in JAMF. We've also tried rebinding to AD, but I'm not certain if we deleted the computer object or not.

I am in the process of commissioning a new root CA server (the current unit is a 2008R2 under extended support) and will also be getting a SHA-2 cert deployed.

[dstranathan]

Same issue here.

-AD-bound Macs running macOS 11.1 Big Sur.
-WPA2 Enterprise (TLS)
-Jamf Pro 10.26.0
-Internal Windows CA (2012R2) with a custom template.
-AD Root Cert is SHA-256. Upgraded from SHA-1 a year ago.
-Worked on Mojave and Catalina.
-Profile lands on target Mac usually, but even when it lands, 802.1x machine doesn't work.*
-Manually re-binding doesn't fix it.
-Pulling the 802.1x profile and re-pushing it from JSS doesn't fix it.
-My CA acknowledges that the Big Sur Mac has been issued a cert.

*Sometimes I see an error in Jamf "The ‘Active Directory Certificate’ payload could not be installed. The certificate request failed." but the Cert Server says that the request was successful.

I also am seeing intermittent AD bind issues that I am trying to resolve. On occasion, the target Mac will lose its ability to search LDAP users/groups in AD. Then eventually it starts working again. Obviously this may all be related. I'm going to post another discussion regarding the AD issues separately from this discussion.

[CommandShiftK]

I'm having this issue also

[ccnetworkadmin]

I've been successful in updating to a SHA-256 cert on a Windows 2016 rootCA. The good news is that I'm at least getting to NPS now, but the connection is being declined by NPS.

I'm stuck for the moment because I had deleted this test unit from Jamf and now have a non-removable Profile. I've got a Jamf support ticket open for help to get this machine's MDM profile removed and get it re-enrolled, then I'll play with configuration profiles to see if I can get it authenticating to 802.1x.

[emily_walker]

Anyone have a solution yet?

[dstranathan]

I'm working with my network/security team and a Cisco-certified consultant on 802.1x (macOS Big Sur & WPA2 Enterprise & TLS & Cisco ISE & ADCS).

Maybe the forthcoming macOS 11.2 update will yield some results (I haven't had time to dig into the beta).

Update: Tested macOS 11.2 - 802.1x still fails in my environment.

[FrigidInIowa]

I may have solved my issue. I added my SHA256 enterprise root CA cert to the same profile I'm deploying the Wifi profile with, then under the Trust 'tab' of the Network profile, I ticked the root CA as trusted. We're still testing this out, but I thought I'd share the update in case it helps.

[dstranathan]

@Messick Can you please clarify?

"I ticked the root CA as trusted" - Do you mean you ticked the "Allow Trust Exceptions" box?

Edit - See what you are referring to. Nevermind.

[vmalapati_mu]

Any luck guys? Has anyone who has faced this issue was able to fix? If yes, do suggest here. Looks like there are too many waiting for a fix..!!!

[alexjdale]

With Big Sur, you are supposed to include the root and intermediate certs in the same profile as the network config and check them as trusted.

However, in our situation, I found that entering a wildcard Certificate Common Name was enough to do the trick (like *.domain.com). Big Sur is now very picky about the chain of trust and simply having the chain certs trusted on the keychain is not enough anymore.

[vmalapati_mu]

As per suggestions by Apple, here are the things that need to validate for macOS Big Sur. Computers with macOS 11 or later require greater security for 802.1X implementations to function properly. 802.1X connections will fail if the following conditions are not met:

The identity certificate for Mac computers must trust where the certificate originated (e.g., the root CA, intermediate CA, or the subordinate CA). It is recommended that you use Jamf Pro to deploy the root, intermediate, and subordinate certificates in the same configuration profile that contains the network payload and the identity certificate.

For TLS workflows, the identity certificate must be selected from the the Identity Certificate pop-up menu in the Network payload of the configuration profile.

I used network payload and certs payload as well and added wildcard entry for Common Cert name as *.domain.com. No luck. Not sure what is missing here. Even though we have used Jamf to deploy all these in a single profile, the issue wasn't fixed.
Jamf is the one who is causing issues with the trust settings. The payload wasn't properly designed amd the Trust isn't happening t the certs( Root CA, Issueing). Payload is not that helpful Jamf you need to fix this ASAP.

[dstranathan]

@vmalapati_mu Thanks for the info. Have you notified Jamf Support?

[sdagley]

@vmalapati_mu What are your certificates using for Signature Algorithm?

[vmalapati_mu]

@sdagley -- It's SHA-2. Jamf payload is not able to trust intermediate trust when it push through profile. Even though if we turst intermediate trust, issue still persists. @dstranathan -- Working with Jamf on this, however they are looking for more information from Apple to understand difference between OS's.